Поскольку мы определили messages как тип maybe , мы разрешаем ему быть null или undefined . Но это не даёт нам права проводить операции с ним (вроде.length или.map) без осуществления проверки на null , потому что если значение messages на самом деле null или undefined , то выскочит ошибка типа при попытке проведения операции с ним.

Так что вернёмся и обновим нашу функцию для просмотра примерно таким образом:

Const MyComponent = ({ messages, isFetching }: AppState) => { if (isFetching) { return } else if (messages === null || messages === undefined) { return

Преимущество № 7: Уменьшение количества юнит-тестов

Например, вернёмся к нашей функции calculateAreas с динамическими типами и обработкой ошибок.

Const calculateAreas = (radii) => { // Handle undefined or null input if (!radii) { throw new Error("Argument is missing"); } // Handle non-array inputs if (!Array.isArray(radii)) { throw new Error("Argument must be an array"); } var areas = ; for (var i = 0; i < radii.length; i++) { if (typeof radii[i] !== "number") { throw new Error("Array must contain valid numbers only"); } else { areas[i] = 3.14 * (radii[i] * radii[i]); } } return areas; };
Если бы мы были прилежными программистами, то могли бы подумать о тестировании недействительных передаваемых параметров для проверки, что они корректно обрабатываются нашей программой:

It("should not work - case 1", () => { expect(() => calculateAreas()).to.throw(Error); }); it("should not work - case 2", () => { expect(() => calculateAreas(undefined).to.throw(Error); }); it("should not work - case 2", () => { expect(() => calculateAreas("hello")).to.throw(Error); });
… и так далее. Но очень вероятно, что мы забудем протестировать какие-то граничные случаи, - и наш заказчик будет тем, кто обнаружит проблему. :(

Поскольку тесты основаны исключительно на ситуациях, какие мы придумали протестировать, то они экзистенциальные, а на практике их легко обойти.

С другой стороны, когда нам требуется установить типы:

Const calculateAreas = (radii: Array): Array => { var areas = ; for (var i = 0; i < radii.length; i++) { areas[i] = 3.14 * (radii[i] * radii[i]); } return areas; };
… мы не только получаем гарантию, что наша цель соответствует реальности, но такие тесты попросту надёжнее. В отличие от тестов на эмпирической основе, типы универсальны и их труднее обойти.

Если взглянуть в целом, то картина такова: тесты хороши для проверки логики, а типы - для проверки типов данных. Когда они сочетаются, то сумма частей даёт ещё больший эффект.

Преимущество № 8: Инструмент моделирования предметной области

Предположим, что в приложении пользователю предлагается один или больше платёжных методов для совершения покупок на платформе. Пользователю разрешено выбрать из трёх платёжных методов (Paypal, кредитная карта, банковский счёт).

Итак, сначала применим псевдонимы типов для трёх платёжных методов:

Type Paypal = { id: number, type: "Paypal" }; type CreditCard = { id: number, type: "CreditCard" }; type Bank = { id: number, type: "Bank" };
Теперь можно установить тип PaymentMethod как непересекающееся множество с тремя случаями:

Type PaymentMethod = Paypal | CreditCard | Bank;
Теперь составим модель состояния нашего приложения. Чтобы не усложнять, предположим, что данные приложения состоят только из платёжных методов, доступных пользователю.

Type Model = { paymentMethods: Array };
Это приемлемо? Ну, мы знаем, что для получения платёжных методов пользователя нужно сделать запрос к API и, в зависимости от результата и этапа процесса, приложение может принимать разные состояния. В реальности, возможно четыре состояния:

1) Мы не получили платёжные методы.
2) Мы в процессе получения платёжных методов.
3) Мы успешно получили платёжные методы.
4) Мы попытались получить платёжные методы, но возникла ошибка.

Но наш простой тип Model с paymentMethods не покрывает все эти случаи. Вместо этого он предполагает, что paymentMethods всегда существует.

Хм-м-м. Существует ли способ составить модель, чтобы состояние приложения принимало одно из этих четырёх значений, и только их? Давайте посмотрим:

Type AppState = { type: "NotFetched" } | { type: "Fetching" } | { type: "Failure", error: E } | { type: "Success", paymentMethods: Array };
Мы использовали тип непересекающегося множества для установки AppState в одно из четырёх состояний, описанных выше. Заметьте, как я использую свойство type для определения, в каком из четырёх состояний находится приложение. Именно это свойство type и является тем, что создаёт непересекающееся множество. Используя его мы можем осуществить анализ и определить, когда у нас есть платёжные методы, а когда нет.

Вы также заметите, что я передаю параметризованный тип E и D в состояние приложения. Тип D будет представлять собой платёжный метод пользователя (PaymentMethod , определённый выше). Мы не установили тип E , который будет нашим типом для ошибки, так что сделаем это сейчас:

Type HttpError = { id: string, message: string };
Теперь можно смоделировать предметную область приложения:

Type Model = AppState;
В целом, подпись для состояния приложения теперь AppState , где E имеет форму HttpError , а D - это PaymentMethod . И у AppState есть четыре (и только эти четыре) возможных состояния: NotFetched , Fetching , Failure и Success .

Такие модели предметной области мне кажутся полезными для размышлений и разработки пользовательских интерфейсов в соответствии с определёнными бизнес-правилами. Бизнес-правила говорят нам, что приложение может быть только в одном из этих состояний, и это позволяет нам явно представить AppState и гарантировать, что оно будет только в одном из этих заранее установленных состояний. И когда мы разрабатываем по этой модели (например, создаём компонент для просмотра), становится абсолютно очевидно, что нужно обработать все четыре возможных состояния.

Более того, код документирует сам себя - достаточно посмотреть на непересекающиеся множества, и немедленно становится понятно, как структурирован AppState.

Недостатки использования статических типов

Важно понять и признать эти недостатки, чтобы мы могли принять информированное решение, когда имеет смысл использовать статические типы, а когда они просто не стоят того.

Вот некоторые из этих соображений:

Недостаток № 1: Статические типы требуют предварительного изучения

Когда я только выучила Elm (функциональный язык со статической типизацией), типы часто мешали. Я постоянно сталкивалась с ошибками компилятора из-за своих определений типов.

Изучение эффективного использования типов - это была половина успеха в изучении самого языка. В итоге, из-за статических типов кривая обучения Elm круче, чем у JavaScript.

Это особенно важно для начинающих, у которых максимально велика когнитивная нагрузка от изучения синтаксиса. Добавление синтаксиса в этот набор может сокрушить новичка.

Недостаток № 2: Можно увязнуть в многословии

Например, вместо этого:

Async function amountExceedsPurchaseLimit(amount, getPurchaseLimit){ var limit = await getPurchaseLimit(); return limit > amount; }
Нам приходится писать:

Async function amountExceedsPurchaseLimit(amount: number, getPurchaseLimit: () => Promise): Promise { var limit = await getPurchaseLimit(); return limit > amount; }
А вместо этого:

Var user = { id: 123456, name: "Preethi", city: "San Francisco", };
Приходится писать такое:

Type User = { id: number, name: string, city: string, }; var user: User = { id: 123456, name: "Preethi", city: "San Francisco", };
Очевидно, что добавляются лишние строки кода. Но есть парочка аргументов против того, чтобы считать это недостатком.

Во-первых, как мы упомянули раньше, статические типы уничтожают целую категорию тестов. Некоторые разработчики могут посчитать это совершенно разумным компромиссом.

Во-вторых, как мы видели раньше, статические типы иногда могут устранить необходимость обработки сложных ошибок, и это, в свою очередь, значительно уменьшает загромождённость кода.

Сложно сказать, является ли многословность реальным аргументом против типов, но стóит держать его в уме.

Недостаток № 3: Требуется время для достижения мастерства в использовании типов

Например, один из подходов такой: закодировать критическиую бизнес-логику статическими типами, но оставить краткосрочные или неважные фрагменты логики динамическими, чтобы избежать излишней сложности.

Понять разницу бывает трудно, особенно если менее опытному разработчику приходится принимать решения на лету.

Недостаток № 4: Статические типы могут задержать быструю разработку

Здесь аргумент в том, что из-за проверки статических типов программист может слишком часто терять концентрацию - а вы знаете, концентрация является ключевым фактором для написания хорошей программы.

Дело не только в этом. Контролёры статических типов тоже не всегда идеальны. Иногда возникает ситуация, когда вы знаете что делать, а проверка типов вмешивается и мешает.

Уверена, что я упустила какие-то ещё недостатки, но это самые важные для меня.

Нужно использовать статические типы в JavaScript или нет?

Первыми языками программирования, которые я изучила, были JavaScript и Python, оба языка с динамической типизацией.

Но освоение статических типов добавило новое измерение в то, как я думаю о программировании. Например, хотя я считала постоянные сообщения об ошибках компилятора в Elm подавляющими в первое время, потом определение типов и «угождение компилятору» стало второй натурой и на самом деле улучшило мои навыки программирования. Вдобавок, нет ничего более освобождающего, чем умный робот, который говорит мне, что я делаю что-то не так и как это исправить.

Да, есть неизбежные компромиссы статических типов, такие как излишняя многословность и необходимость тратить время на их изучение. Но типы добавляют безопасность и корректность в программы, что устраняет значимость этих «недостатков» для меня лично.

Динамические типы кажутся более быстрыми и простыми, но они могут подвести, когда вы реально запускаете программу в деле. В то же время можете поговорить с любым Java-разработчиком, который имеет дело с более сложными параметризованными типам - и он скажет, как сильно их ненавидит.

В конечном счёте, здесь нет универсального решения. Лично я предпочитают использовать статические типы при следующих условиях:

1. Программа критически важна для вашего бизнеса.
2. Программа, вероятно, подвергнется рефакторингу, в соответствии с новыми потребностями.
3. Программа сложна и имеет много подвижных частей.
4. Программу поддерживает большая группа разработчиков, которым нужно быстро и точно понять код.

1. Код недолговечный и не является критически важным.
2. Вы делаете прототип и стараетесь продвигаться как можно быстрее.
3. Программа маленькая и/или простая.
4. Вы единственный разработчик.

Заключение

Возможность переключаться между динамическими и статическими типами - это мощный инструмент для JavaScript-сообщества, и захватывающий:)

Собрали список вопросов, ответы на которые должен знать не только каждый JavaScript разработчик, но и, пожалуй, любой программист.

Назовите две наиболее важные для JavaScript-разработчика парадигмы программирования?

JavaScript – мультипарадигмальный язык, поддерживающий императивное/процедурное программирования наряду с ООП и функциональным программированием. JS поддерживает ООП с прототипным наследованием.

Желательно упомянуть:

1. Прототипное наследование (также: прототипы, объектные ссылки)

2. Функциональное программирование (также: замыкания, функции первого класса, лямбды)

Следует избегать:

Не иметь представления о парадигмах, не упомянуть прототипное ООП или функциональное программирование.

Что такое функциональное программирование?

Функциональное программирование подразумевает вычисление математических функций, избегая общих состояний и изменяемых данных. Lisp (специфицирован в 1958 году) является одним из первых функциональных языков программирования и сильно вдохновлен лямбда-исчислениями. Lisp и подобные ему языки широко применяются и по сей день.

Функциональное программирование – одна из основополагающих концепций JavaScript (один из двух столпов JS). Некоторые функциональные утилиты были добавлены в JavaScript в ES5.

Хорошо упомянуть:

1. Чистые функции / чистота функций

2. Избежание побочных эффектов

3. Простой состав функций

4. Примеры функциональных языков: Lisp, ML, Haskell, Erlang, Clojure, Elm, F Sharp, OCaml и т.д.

5. Особенности, которые поддерживает функциональное программирование: функции первого класса, функции высших порядков, функции как аргументы/значения

Следует избегать:

1. Отсутствие упоминаний чистых функций / избежание побочных эффектов

2. Не привести примеры функциональных языков

3. Не привести примеры функциональных фич JavaScript

В чем заключается разница между классовым и прототипным наследованием?

Классовое наследование: экземпляры наследуются от классов, создаются подклассовые отношения (иерархическая систематизация классов). Экземпляры реализуются через конструктор функции, через дескриптор new. Экземпляр класса может не содержать дескриптор class начиная с ES6.

Прототипное наследование: экземпляры наследуются напрямую от других объектов, реализуются через фабрики или Object.create() и экземпляры могут быть составлены из множества различных объектов для упрощения выборочного наследования. Прототипное наследование более простое и гибкое, нежели классовое.

Хорошо упомянуть:

1. Классы: тесные связи, иерархия

2. Прототипы: конкатенативное наследование, делегирование, функциональное наследование, композиция

Следует избегать:

Не указать на преимущества прототипного наследования перед классовым

Каковы плюсы и минусы функционального и объектно-ориентированного программирования?

Плюсы ООП: простая для понимания концепция объектов и методов вызова. ООП стремится использовать императивный стиль, нежели декларативный, который читается как прямой набор машинных инструкций.

Минусы ООП: как правило, присутствует зависимость от общих состояний. Объекты и их поведение связаны одной сущностью, к которой случайно может быть получен доступ любым количеством функций в неопределенном порядке, что может привести к непредсказуемому поведению, например, состоянию гонки.

Плюсы ФП: используется функциональная парадигма, позволяющая избежать общих состояний и нежелательных эффектов, исключаются ошибки, возможные из-за конкурирования функций. Благодаря таким фичам, как неявное программирование, функции, как правило, радикально упрощаются и легко перестраиваются для более легкого, по сравнению с ООП, повторного использования кода.

Вычисления, использующие чистые функции легко масштабируются на несколько процессоров или распределенных вычислительных кластеров без опасения возникновения борьбы за ресурсы.

Минусы ФП: чрезмерная эксплуатация функциональных подходов, вроде неявного программирования, может привести к снижению читабельности кода, так как конечный код получается более абстрактным, кратким и менее конкретным.

Чаще люди больше знакомы с ООП и императивным подходом, так что некоторые общие идиомы функционального программирования могут вызывать трудности у новичков.

Функциональное программирование имеет более крутую кривую обучения, нежели ООП, имеющего большую популярность и более понятного для изучения. Концепции ФП часто описываются идиомами и обозначениями из лямбда-исчислений, алгебры и теории категорий, требующих знаний основ в этих областях для понимания.

Хорошо упомянуть:

1. Проблемы общих состояний, нежелательного поведения

2. Возможности ФП по радикальному упрощению кода программ

3. Разность в сложности изучения

4. Побочные эффекты и их влияние на надежность программ

5. Сложность изменения и общая хрупкость базы ОО кода в сравнении с таковой в функциональном стиле

Следует избегать:

Не упомянуть недостатки одного из подходов – каждый, кто сталкивался с одним из них, знает и о паре-другой недостатков

Когда классовое наследование – подходящий выбор?

Вопрос с подвохом. Правильный ответ – никогда. Композиция – более простой и гибкий подход, чем наследование классов.

Хорошо упомянуть

«…композиция объектов лучше, чем наследование классов»

Следует избегать:

Упоминание Rect Components. React.js использует дескриптор class, но не позволяет избежать подводных камней классового наследования. Вопреки популярным ответам, не нужно использовать class, чтобы пользоваться React. Такой ответ покажет не понимание как классов в JavaScript, так и Реакта.

Когда лучше использовать прототипное наследование?

Существует более, чем один тип прототипного наследования:

1. Делегирование (цепочка прототипов)

2. Конкатенация (миксины, Object.assign())

3. Функциональное наследование (не путать с функциональным программированием. Функция используется для создания замыкания для private/инкапсуляции)

Хороший ответ:

1. В ситуациях, когда модули или функциональное программирование не обеспечивают очевидного решения

2. Когда нужно собрать объект из нескольких источников

3. В любом случае, когда нужно применить наследование

Следует избегать:

1. Не знать, когда применяются прототипы

2. Не знать о миксинах или Object.assign()

Что значит «композиция объектов лучше, чем наследование классов»?

Это цитата из книги “Design Patterns: Elements of Reusable Object-Oriented Software”. Повторное использование кода должно достигаться за счет сборки малых единиц функциональности в новый объект, а не наследованием классов и созданием иерархий.

Хорошо упомянуть:

1. Избежание наследования и тесных связей

2. Избежание вытекающей из классического наследования проблемы «банан/мартышка» (нужен был банан – получили мартышку, держащую банан посреди джунглей)

Следует избегать:

Не назвать какую-то из упомянутых выше проблем. Не объяснить разницу между композицией и наследованием или не суметь рассказать об преимуществах композиции.

Что такое двусторонняя связь данных и однонаправленный поток данных и в чем разница между ними?

Двусторонняя связь данных подразумевает, что поля интерфейса связаны с моделью данных динамически, то есть при изменении полей интерфейса меняется модель, и наоборот.

Однонаправленный поток данных означает, что только модель – источник истины. Изменения в интерфейсе запускают сообщения, которые сигнализируют пользователю о намерении модели (или «store» в терминах React). Смысл в том, что данные всегда идут в одном направлении, что облегчает понимание.

Односторонние потоки данных детерминированы, тогда как двусторонняя привязка может вызывать нежелательные эффекты, которые труднее отследить и понять.

Хорошо упомянуть:

1. React – новый канонический пример однонаправленного потока данных, так что упоминание Реакта будет хорошей идеей. Cycle.js — еще одна популярная реализация однонаправленного потока данных.

2. Angular – популярный фреймворк, использующий двустороннюю привязку.

Следует избегать:

Непонимание этих концепций, неспособность объяснить разницу между ними.

Каковы плюсы и минусы монолитной архитектуры и микросервисов?

Монолитная архитектура означает, что ваше приложение написано как единый связный блок кода, чьи компоненты спроектированы для совместной работы и использования общих ресурсов.

Подход микросервисов подразумевает, что приложение состоит из множества небольших независимых приложений, способных работать с собственными ресурсами и потенциально на большом количестве отдельных машин.

Преимущества монолитной архитектуры: основным преимуществом монолитной архитектуры является то, что большинство приложений, как правило, имеют множество общих проблем, таких как логирование, ограничение скорости и необходимость функций безопасности – в едином приложении для каждого компонента их проще решать.

Минусы монолитного приложения: так как все компоненты тесно связаны друг с другом, по мере развития приложения, становится труднее его понимать, появляется много неочевидных зависимостей и побочных эффектов.

Плюсы микросервисов: микросервисы обычно лучше организованы, так как каждый компонент выполняет свою задачу и работает независимо от каждого другого компонента. Приложение на основе обособленных компонентов также проще переконфигурировать и изменять.

Минусы микросервисов: при создании нового микросервиса может появится много внезапных проблем, которые не ожидались при проектировании. Для монолитного приложения можно использовать промежуточное программное обеспечение для решения различных сквозных проблем без особых трудозатрат.

При микросервисной архитектуре либо потребуются накладные расходы на отдельные модули для каждой сквозной проблемы, либо нужно инкапсулировать их на другом уровне обслуживания, через который проходит весь трафик.

В конце концов, даже монолитные архитектуры имеют тенденцию направлять трафик через внешний уровень обслуживания, но с монолитной архитектурой можно отложить затраты на эту работу до тех пор, пока проект не станет более зрелым.

Микросервисы же часто развертываются в собственных виртуальных машинах или контейнерах, что приводит к быстрому увеличению числа конфликтов по виртуальным ресурсам.

Хорошо упомянуть:

1. Несмотря на начальную дороговизну, микросервисы выигрывают в долгосрочной перспективе за счет лучшего масштабирования

2. Практические различия микросервисов и монолитных приложений

Следует избегать:

1. Незнание различий архитектур

2. Незнание недостатков микросервисов

3. Недооценивать преимущества масштабирования микросервисов

Что такое асинхронное программирование и почему оно важно в JS?

Синхронное программирование означает, что за исключением условий и вызовов функций, код исполняется последовательно от верха к низу, задерживаясь на длинных задачах, таких как сетевые запросы и чтение/запись с диска.

Асинхронное программирование подразумевает, что когда требуется операция блокировки, запрос отправляется, и код продолжает работать без блокировки до ожидания результата. Когда ответ готов, запускается прерывание, это приводит к запуску обработчика событий и поток управления продолжается. Таким образом, один программный поток может обрабатывать множество параллельных операций.

Пользовательские интерфейсы по своей природе асинхронны, большую часть времени они проводят, ожидая пользовательского ввода, чтобы прервать цикл и запустить обработчик.

Node.js по умолчанию асинхронен, по сути, сервер проводит все время в цикле, ожидая сетевой запрос.

В JavaScript это важно, так как естественно для интерфейсов и положительно сказывается на производительности сервера.

Хорошо упомянуть:

1. Значение блокировок, влияние на производительность

2. Понимание обработчиков и почему они важны для интерфейсов

Следует избегать:

1. Непонимание терминов синхронности и асинхронности

2. Неспособность определить последствия для производительности

Язык PHP применяется для разработки веб-приложений очень активно, и сегодня на нем работают три из пяти сайтов. Однако обязательно стоит обратить внимание и на возможные альтернативы. Одной из них является Node.js.

Преимущества Node.js

Количество поклонников этой программной платформы стремительно увеличивается, ведь во многих ситуациях она имеет неоспоримые преимущества перед PHP. Javascript, на котором пишется серверный код на Node.js — это мощный и гибкий язык. Он имеет свои особенности и даже странности, однако после того, как вы поймете его концепцию, работа на нем наверняка вас затянет. Javascript допускает программирование в разных стилях и предоставляет разработчику большие возможности.

Node.js дополнительно расширяет его функционал. Если раньше Javascript использовался исключительно для разработки браузерных приложений, то теперь на нем можно писать также приложения мобильные и десктопные. PHP тоже можно применять для разработки десктопных приложений и консольных утилит, но делается это достаточно редко.

По умолчанию Node.js укомплектована удобным и функциональным менеджером пакетов — npm. Он делает управление модулями и зависимостями простым и комфортным. А благодаря встроенным библиотекам для обработки запросов и ответов с Нодой вы не будете зависеть от сторонних серверов. Также эта платформа в некоторых ситуациях обеспечивает лучшую производительность.

И, наконец, Node.js имеет большое количество положительных отзывов от разработчиков. Немногие из тех, кто пишут на PHP, увлечены этим языком, но с Javascript ситуация совсем иная.

Недостатки

Однако надо иметь в виду, что Node не лишена недостатков:

• она сложнее в изучении, и начать работать с использованием этой технологии будет не так легко, особенно в том случае, если вы новичок в веб-программировании, в то время как создать сайт на PHP гораздо проще;
• технология Node относительно молода, поэтому информации по ней гораздо меньше, чем по PHP;
• для PHP подойдет любой хостинг, а вот подходящую площадку для Node придется еще поискать;

Таким образом, однозначного ответа на вопрос о том, что лучше — PHP или Node.js — нет. Однако нужно иметь в виду, что последняя стремительно набирает популярность. Сегодня ее используют Microsoft, PayPal, LinkedIn, Yahoo и множество других крупных компаний.

Многие еще с девяностых годов привыкли использовать PHP и не спешат его на что-то менять. Однако прогресс не стоит на месте, и технологии веб-разработки в последние годы развиваются стремительно. В том случае, если вы будете игнорировать новые веяния, рано или поздно вы заметите, что разрабатываемые вами продукты просто недостаточно актуальны и востребованы.

От автора: переход с React на Vue, два года спустя. Выбор новых фреймворков и библиотек — захватывающий, но также стрессовый процесс. Даже после определенного исследования вы никогда не знаете, какие скелеты обнаружите в шкафу.

Мой медовый месяц длится долго. Примерно через 2 года почти ежедневного использования Vue я, наконец, могу написать об этом, имея определенную точку зрения. Рассмотрим свойственные Vue js преимущества, не забудем и про недостатки. ОСТОРОЖНО: Личное мнение.

Хороший

Реактивность

Привязывание данных — это отличная вещь в мире интерфейсов. Вместо микроменеджмента DOM, как мы это делали с jQuery, теперь мы фокусируемся на данных. Vue обрабатывает их аккуратно с помощью двухсторонней реактивной системы привязки данных.

Чтобы достичь этой реактивности, Vue добавляет несколько геттеров и сеттеров к каждой переменной в состоянии, чтобы она могла отслеживать изменения и автоматически обновлять DOM (кхе-кхе, this.setState()). Этот подход не является совершенным, как мы увидим позже.

Батареи прилагаются

С Vue нам нет необходимости прибегать к неофициальным пакетам, таким как MobX или React Router, для критических частей приложения. Vue предоставляет Vue Router и Vuex, Redux-подобный реактивный инструмент для управления состояниями. Это отличные библиотеки сами по себе, но тот факт, что они были специально разработаны для Vue, делает их еще лучше.

Скорость

Vue очень быстр. Возможно, он не самый быстрый, но его производительности с запасом хватает для подавляющего большинства веб-проектов. Когда вам в последний раз нужен был рендеринг и обновление тысяч элементов DOM в секунду?

HTML-шаблоны

Это одна из тем, вызывающих разногласия среди разработчиков JavaScript. Независимо от ваших предпочтений, HTML-шаблоны были проверены в течении десятилетий использования во многих языках и являются основным выбором для написания динамической разметки во Vue.

Но эй, Vue поддерживает также и JSX.

Другие приятные вещи:

Отдельные файловые компоненты с HTML, CSS и JavaScript.

Легкий. Около 20 КБ (минимизированный + gzip).

Хорошо расширяемый (миксины, плагины и т. д.).

Отличная документация (за некоторыми исключениями, указанными ниже).

Может быть принят постепенно, даже используется как замена jQuery.

Просто начать использовать.

Неоднозначный

Шаблон компонентов

Переход от React к Vue выглядит как глоток свежего воздуха. Больше не существует привязки (this) или setState(). Ура! Но через некоторое время вы начнете подвергать сомнению правильность синтаксиса компонентов Vue. Компоненты Vue создаются с помощью объектов, и вот пример определения функции компонента:

export default { methods: { increment () { this.count++; } } }

Вы будете добавлять аналогичный шаблон для вычисляемых свойств, состояния компонентов, наблюдателей и т. д. Практически все во Vue имеет собственный специальный синтаксис с большим количеством шаблонов. А вот то же самое для Марко , но это значительно чище:

class { increment() { this.state.count++; } }

Сейчас я говорю не об использовании или не использовании классов, а о том, что Vue использует произвольные структуры объектов вместо языковых функций.

Я не буду обвинять вас, если вы чувствуете, что это немного грязно, когда создаете эти раздражающие объекты. Vue также предлагает синтаксис, основанный на классах, но об этом позже.

Чат-сообщество

Сообщество Vue зависает на Discord, чате, предназначенном для сообществ геймеров. Если вы попали в сложную ситуацию, чат, вероятно, будет вашим лучшим решением, поскольку официальные форумы — это пустынные земли, и вы ведь не хотите задавать вопрос на Github.

Чаты грязные, но главная проблема заключается в том, что содержимое чата не может быть проиндексировано поисковыми системами. Те же вопросы (и связанные с ним обсуждения) обречены повторяться снова и снова, и снова.

Эта тенденция использования чатов для вопросов связана с проектами с открытым исходным кодом, и я думаю, что это необходимо урегулировать. Они не дают возможности коллективного обучения.

Не такой волшебный

Пока вы не сходите с проторенного пути, все будет хорошо, но через некоторое время вы, вероятно, найдете много маленьких если и но, связанных с Vue. Некоторые примеры:

Реактивная система отслеживает изменения только при определенных условиях. Не ожидайте, что вы можете вводить все, что пожелаете. Довольно часто вам может понадобиться максимально упростить данные, чтобы избежать головной боли. Конечно, все это объясняется мелким шрифтом в документации.

Переходная система не работает для списков. Вам на самом деле нужно использовать , который работает несколько иначе и вводит в DOM новые элементы. Кроме того, можно было бы ожидать, что для этого должно быть отличное решение, но вам придется реализовать его самостоятельно.

Если вам требуется нереактивное состояние в экземпляре компонента, вы попадаете на неизведанные территории.

И т.п. Не поймите меня неправильно, это не такая уж и беда, но кажется, что каждый раз, когда вы начинаете разбираться в какой-то проблеме, появляется еще одна неприятная вещь.

Злой

Нечеткие архитектурные шаблоны

Вот пример: что лучше — обрабатывать запросы API в компонентах или во Vuex? В документации приведены примеры того, как обрабатывать API-логику во Vuex. Есть даже красивая и красочная диаграмма:

Означает ли это, что логика аутентификации также входит во Vuex? Будет ли менеджер состояний начинать перехватывать всю логику приложения?

Это не очевидные вещи. Большинство людей просто начнут вставлять логику без состояний в действия Vuex или, что еще хуже, непосредственно в компоненты, потому что на домашней странице Vue есть видео:

Отвечая на первоначальный вопрос: логика API не должна писаться ни во Vuex, ни в компонентах. Существует даже хороший пример того, как это делается в официальных примерах кода .

Заключение

Все больше людей переходят на Vue, и я сомневаюсь, что эта тенденция скоро прекратится. Он все еще далеко не настолько принят, как React (по крайней мере, за пределами Китая), и постоянно борется за второе место с Angular.

В прошлом я утверждал, что Vue — это прагматичная библиотека, в отличие от React, которая кажется более идеалистической («Мы чистый JavaScript!»). Я все еще думаю, что это хорошая метафора. С другой стороны, теперь я чувствую, что прагматизм-для-всего от Vue нуждается в гораздо большей доводке, элегантности и простоте на уровне пользователя.

За 2 года мой опыт работы с Vue был положительным. Я все еще уверен, что это было хорошим решением перевести мою команду с React на Vue. Не потому, что Vue лучше, а потому, что он лучше подходит для нас.

Vue, конечно же, выполняет задачи, для которых он предназначен, и преуспевает в тех областях, где другие терпят неудачу, но сегодня я не думаю, что Vue объективно лучше или хуже других возможных вариантов. Вот и все.