Изучение шаблонов архитектурного проектирования

Обработка данных внутри клиентского приложения - немного сложная и сложная задача. Сегодня мы рассмотрим один метод обработки сложных данных, предложенный Facebook, под названием Flux Architecture на их конференции F8.

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

Что такое Flux?

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

Flux - это шаблон наблюдателя

Зачем нам нужен Flux?

Предположим, у нас есть два объекта с именами p и q. Когда p изменяется, мы хотим, чтобы q изменилось вместе с ним. Есть два способа сделать это:

1. Декларативно: p обновляет, затем вызывает метод для q.

Изначально это просто, но опыт показывает, что в конечном итоге проблема возникает из-за того, что мы тесно связали p с q. Если мы хотим добавить r, нам нужно обновить p.

А теперь представьте, что в DOM меняются сотни вещей. Каждый раз, когда мы добавляем компонент, нам нужно найти все, что может его обновить и изменить. Представьте, что r нужно реагировать на изменения p и q. Все знает обо всем остальном.

2. Шаблон наблюдателя: P запускает событие. Q слушает (Flux).

В шаблоне наблюдателя, когда p обновляется, он запускает событие. q подписывается на это событие. Когда событие запускается, вызывается метод q.

Изначально это делает наш p немного более сложным (хотя мы можем исправить это с помощью библиотеки или прототипа).

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

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

Люди Facebook часто говорят об одностороннем потоке данных, когда говорят о Flux. Это просто означает, что событие запускается для одного элемента и прослушивается другим. Данные передаются от p к q через событие, а не от p к q и обратно к p снова, как было бы, если бы p вызвал метод на q и получил возвращаемое значение.

Библиотеки Flux похожи на очки: вы будете знать, когда они вам понадобятся - Дэн Абрамов

Модель-представление-контроллер - MVC

Один из наиболее распространенных шаблонов проектирования называется шаблоном проектирования MVC, что означает модель, представление, контроллер. Этот шаблон объединяет ваш код в три сегмента:

  1. Модель: хранит данные и управляет ими.

Компонент Model соответствует всей логике, связанной с данными, с которой работает пользователь.

2. Просмотр: графический интерфейс пользователя.

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

3. Контроллер: мозги приложения.

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

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

Шаблон потока

В MVC отношения между компонентами усложняются. Масштабировать приложение становится сложно. Данные в приложении Flux передаются в одном направлении. Facebook решил эту проблему, создав Flux Architecture to React - шаблон проектирования, который позволяет данным перемещаться только в одном направлении при работе в в сочетании с React, чтобы обновлять веб-страницу только при изменении состояния компонента.

Есть четыре различных роли для работы с данными в методологии потоков:

  1. Действие

Действие - это то, что запускает последовательность событий, которые в конечном итоге приведут к повторной визуализации пользовательского интерфейса в React. У действия есть свойство типа и новые данные:

Свойство type описывает действие, а полезная нагрузка - это новые передаваемые данные. Эта полезная нагрузка может быть любого типа (объект, строка и т. Д.) В зависимости от создателя действия, для которого она будет использоваться. В этом случае они, вероятно, будут объектами, поскольку мы, вероятно, будем иметь дело с идентификатором пользователя и именем пользователя или адресом электронной почты.

При вызове этих создателей действий отвечает диспетчер.

2. Диспетчер

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

3. Магазин

Магазин занимается состоянием нашего приложения. В Flux мы можем иметь несколько хранилищ, по одному для каждого компонента, если захотим. Состояние - это объект, содержащий пары ключ: значение, которые помогают отрисовывать этот конкретный компонент и / или его дочерние элементы.

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

4. Просмотр

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

Полная реализация архитектуры Flux

Давайте посмотрим на полную реализацию архитектуры Flux. Здесь, если я добавлю поддержку AMD, CommonJS и глобального использования, мы получим 66 строк кода, 1,7 КБ простого или 795 байт после минификации JavaScript.

Циклы

Односторонний поток данных не исключает циклов.

Популярные реализации Flux

Теперь, когда у вас есть общее представление об архитектуре Flux, давайте взглянем на несколько известных реализаций Flux.

Redux. Согласно GitHub, Redux - это контейнер с предсказуемым состоянием для приложений JavaScript. Многие концепции аналогичны функциональному программированию, и все данные хранятся в одном хранилище.

Независимо от размера приложения Redux всегда представляет собой единый объект, в отличие от Flux, который хранит отдельные хранилища для разных типов данных. Если с данными нужно произвести какие-то манипуляции, это не повлияет на состояние. Таким образом, состояние неизменяемо.

Все обновления и манипуляции производятся на дереве состояний. Но это не замедляет работу приложения, поскольку данные могут совместно использоваться несколькими версиями дерева состояний. Обновления состояния приложения выполняются с помощью действий, которые сами по себе являются простыми объектами, но содержат свойство, отображающее тип выполняемого действия. Также будут включены данные, описывающие действие.

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

  • Reflux - это одна из самых популярных реализаций Flux. Но между ними есть некоторые принципиальные различия. Reflux не использует Диспетчер; вместо этого каждое действие является диспетчером. Поскольку сами Действия являются функциями, создателей действий нет. И самое лучшее в Reflux - это то, что он более лаконичен и оптимизирован, с меньшим количеством требований к повторяющемуся коду.
  • Fluxxor - Fluxxor использует ряд инструментов и архитектуру Flux для построения слоев данных JS. Чтобы пользоваться всеми функциональными возможностями Fluxxor, вам нужно заставить его работать с React в качестве слоя представления.
  • Flummox - Flummox состоит из трех компонентов, а именно: Actions, Stores и Flux. В Flummox вы создаете несколько действий, а затем создаете Магазин, который реагирует на эти действия. На следующем этапе вы объединяете их в Flux и используете в View. Каждый из компонентов Flummox представлен классом, и вы расширяетесь от этого базового класса.
  • Alt - созданная на основе Flux, Alt представляет собой библиотеку, которая упрощает управление состоянием в приложениях JavaScript. Вы можете установить Alt, если вы устанавливаете менеджеры пакетов, такие как nom или bower. Alt дает вам преимущество Flux, но с улучшенным синтаксисом .

MVC против Flux

Плюсы:

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

Действия можно сохранить, а затем воспроизвести.

Минусы:

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

Если вам нужна дополнительная информация о флюсе, обратитесь к документации по флюсу, приведенной ниже.

Документация по Flux - https://facebook.github.io/flux/docs/overview

Заключение

После прочтения этой статьи я надеюсь, что если вы раньше не получали Flux Architecture от Facebook, то теперь вы можете сказать, что получаете. Только когда я что-то с ним сделал, я понял, насколько он полезен для React.js.

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

Если вы хотите использовать архитектуру Flux, но не хотите использовать React, ознакомьтесь с Delorean, фреймворком Flux, который вы можете использовать с Ractive.js или Flight. Еще одна заслуживающая внимания библиотека - Fluxxor, которая использует другой подход к архитектуре Flux и обеспечивает более тесную связь компонентов Flux с центральным экземпляром Flux.

Опять же, я считаю, что для того, чтобы по-настоящему понять Flux, вам действительно нужно его использовать, так что следите за обновлениями!

Удачного кодирования :)