От AngularJS до Flux - The React Way

Question

Как разработчик с хорошим практическим опытом AngularJS, как мне настроить мою ментальную модель написания веб-приложений в Flux с помощью React?

Я не ищу Flux + Реагировать против углового ответа (уже много что онлайн), но я бы хотел бы знать, каково больших различия в двух «менталитетах»: заранее, я был введен в Угловой путь; сравнительно, что такое The React Way?

Как я оставляю Угловую вселенную и переход к Flux, каковы ключевых вещи мне нужно начать обращать внимание на?

Различия сначала, а теперь сходства: AngularJS очень упрям ​​и имеет очень большие нет-нет, например - не помещайте код UI/DOM в контроллеры. Каковы большие нет-нет и мнения Реакт?

Последнее, но не менее, Facebook относится к Flux как альтернативы MVC, но, как я смотрю на него - Реагировать это вид двигателя, магазины модели контейнеры были сосредоточены на одном домене, а также диспетчеру и действия сформировать контроллер. Так разве это не MVC с другим именем?

Answer 1

Я позволю другим сделать сравнение/контраст с угловым, но вот несколько ответов на два из ваших вопросов.

Так разве это не MVC с другим именем?

Наличие в потоке разделения проблем между слоем данных/логики и уровнем представления не делает его MVC. Многие другие модели имеют аналогичный раскол, в первую очередь CQRS, возможно, ближайший кузен Flux. В Flux нет контроллера в смысле MVC. Действия и диспетчер не соответствуют контроллеру. Представления Controller близки, но на самом деле они довольно ограничены в плане, подобном контроллеру. Ключевым отличием является то, что контроллеры MVC содержат логику приложения и действуют на моделях. Flux хранит, напротив, все логики приложения и не имеют сеттеров.

Как я покидаю Угловую вселенную и переход к Флюсу, в чем основные вещи, на которые мне нужно обратить внимание?

Ключевые значения Flux:

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

Основные понятия в Flux:

• однонаправленный поток данных: Действие → Диспетчер → Магазины → Просмотров
  • Каждый изменение состояния и все новые данные начинается с вызываемым действий ,
  • Этот четырехступенчатый поток данных является основной ментальной моделью для программиста Flux.
• Отправка вызывает преобразование состояния приложения в приложении.
  • Это момент времени, создавая моментальный снимок смены. Об этом легко рассуждать.
  • Мы не можем отправить во время отправки и сохранить эту простоту. Таким образом, любое изменение результата должно быть вызвано первоначальным действием.
• Flux-магазины - это модели домена, а не модели ORM. Они содержат всю логику и управляют всем состоянием для определенного логического домена внутри приложения. Они могут содержать коллекции, особые значения или их комбинацию.
• Flux предполагает, что полученные данные - где одно хранилище зависит от изменений в другом магазине - это вероятность в сложных приложениях, где модели или магазины управляют нормализованными данными. Чтобы справиться с этим, диспетчер Flux должен предоставить механизм декларативного управления этой зависимостью в магазине. В Диспетчере Facebook это делается с помощью метода waitFor(). Это позволяет одному магазину ждать ответа другого магазина на действие, прежде чем двигаться вперед с его собственным ответом.

Первичные части флюса применения:

• Действие: литерал объект, содержащий новые данные и определенный тип, позволяет Stores различать, является ли это отношение к их области.
• Dispatcher: реестр обратных вызовов, который посредством обратных вызовов распределяет полезную нагрузку (действие) регистраторам (Магазинам). У него нет собственного интеллекта. Вся разведка находится в Магазинах.
• Магазины: модель домена, которая регистрируется в диспетчере и испускает событие «изменения» всякий раз, когда происходит изменение его состояния.
• Контроллер-виды: просматривать компоненты рядом с корнем дерева компонентов. Они прислушиваются к событиям «изменения» в магазинах и реагируют на это событие, получая новые данные через открытые методы геттера магазина и передавая их своим детям. Единственное отличие между представлениями Controller и Views - это функция прослушивания.
• Просмотры: дети без гражданства компонентов контроллера, получающие и проходящие по данным, подобно чистым функциям. Представления и контрольные представления чаще всего реализуются с помощью React, поскольку он обеспечивает возможность повторной рендеринга с очень небольшой потерей производительности.
• Utils: библиотеки чистых функций, которые могут быть легко доступны для разных модулей.

Обзор, глубина: http://facebook.github.io/flux/docs/overview.html

Учебник: http://facebook.github.io/flux/docs/todo-list.html

Примеры: https://github.com/facebook/flux/tree/master/examples

Действия и грузоотправитель: http://facebook.github.io/react/blog/2014/07/30/flux-actions-and-the-dispatcher.html

Тестирование: http://facebook.github.io/react/blog/2014/09/24/testing-flux-applications.html

Больше в дикой природе: http://facebook.github.io/react/blog/2014/10/17/community-roundup-23.html