Различных фреймворков много, благодаря чему перед разработчиками и верстальщиками рано или поздно встает вопрос: что лучше использовать в данном проекте, а что – нет, зачем может понадобиться именно та среда разработки, а не эта и так далее. Разумеется, что ответить на эти вопросы можно по-разному, информации об этом тоже множество. Но попробуем в этом материале разобраться в необходимости использования Redux, в причинах его востребованности и его особенностях.
Некоторые его любят, некоторые – уже не сильно, но сколько мастеров – столько и мнений. Управлять огромным потоком данных и их связями действительно было сложновато до появления фреймворка Redux. Но вдохновленный набором шаблонов программирования Flux Facebook, Redux предназначен для управления состоянием данных в приложениях JavaScript. Хотя он в основном используется с библиотекой React, многие веб-разработчики с успехом применяют его с иными фреймворками и библиотеками, такими как jQuery, Angular или Vue.
При очень небольшом размере (около 2 КБ, включая расширения) Redux гарантирует, что каждый компонент некоторого приложения может иметь прямой доступ к состоянию приложения без необходимости отправлять props (входные параметры) дочерним компонентам или использовать функции обратного вызова для отправки данных обратно.
В этом материале давайте посмотрим на то, как Redux глубоко укоренился в концепциях функционального программирования и каким образом можно решить, нужно ли веб-мастеру его использовать в своем приложении, описания интерфейса сайта.
Когда и зачем нужен Redux
Здравый смысл подсказывает, что нет смысла при каждом новом проекте постоянно запускать новые фреймворки и работать только в них, ведь их описывают как самые новые и блестящие инструменты для самых разных задач. Но разве компоненты не имеют своего состояния? Зачем вообще нужен этот вот самый инструмент для управления данным состоянием некоторого компонента?
Не поймите превратно, React велик и могуч и вполне можно в проекте обойтись только одним этим фреймворком и более ничего не использовать. Тем более, что мы уже рассматривали подробно React и приводили примеры веб-проектов, что использовали только эту библиотеку для создания функционала интерфейса (то же самое приложение, по сути). Но по мере того, как приложение становится более сложным, с большим количеством разных компонентов, использование всего лишь одного фреймворка для управления всем этим «массивом», объемом данных и так далее может стать очень проблематичным и осложненным действом. Проблем может появиться много, даже неудобств и излишней трудоёмкости.
И именно в этот момент Redux способен сэкономить время; он значительно уменьшает и упрощает сложности, возникающие в таких больших приложениях. Если у веб-разработчика есть опыт работы в React, он может великолепно понять, что поток данных React таков, что родительские компоненты передают props (входные параметры) дочерним компонентам. В огромном приложении с данными, что используются в разных компонентах, постоянно изменяемыми и сохраняемыми в хранилище, создающими множественные связи – рано или поздно сам код станет очень трудно читать и даже улучшать. Вам самим, в первую очередь.
Чтобы представлять, о чем идет речь, посмотрим на диаграмму ниже.
В React (как, впрочем, и в других фреймворках) связь между двумя компонентами, не имеющими отношения родитель-потомок (дочерний элемент), не рекомендуется. React обращает внимание, что если такое сделать (создать связь), можно вполне создать собственную глобальную систему событий по шаблону Flux; и именно в этот момент и появляется на сцене Redux.
С Redux у нас есть хранилище, в котором можно сохранять все состояния приложения. Если в компоненте A происходит изменение состояния, оно затем передается в хранилище, а другие компоненты B и C, которые должны знать об этом изменении состояния в компоненте A, могут получать эту самую информацию об этом изменении из хранилища:
.jpg)
Увидели? Это даже намного лучше, чем мы предполагали. Если бы наши компоненты взаимодействовали друг с другом, мы создали бы уязвимую и нечитаемую базу программного кода с множеством ошибок. Redux делает ситуацию другой, меняет её и совершенствует.
Компонент A отправляет изменения своего состояния в хранилище, и если Компонент B и C нуждаются в данных об этих изменениях состояния, они могут получить их из хранилища. Таким образом, логика потока данных является бесшовной.
Помимо своей основной миссии, Redux предоставляет и множество иных преимуществ при своем использовании. Посмотрим на основные три таких момента, что являются сами по себе особо важными среди прочих:
- Предсказуемость результатов
Имея только один источник данных (хранилище), у разработчиков становится мало проблем с синхронизацией текущего состояния компонентов (данных этого самого хранилища) с действиями и другими частями приложения.
- Поддержание работоспособности
Redux имеет строгие рекомендации о том, как должен быть организован код. Соответственно и, что разумно, это дополнительно обеспечивает предсказуемый результат, который упрощает управление кодом.
- Простота тестирования
Работа с кодом в Redux включает в себя чистые функции, которые изолированы друг от друга, что коррелирует с золотым правилом написания тестируемого кода: написать небольшие функции, которые делают только что-то одно и являются независимыми.
Здорово и все просто. Если приложение сложное – используем Redux и забываем обо всем прочем. Но так ли это в действительности? Что если существуют некоторые особенности, когда Redux все же нужен?
Когда Redux может не потребоваться
Это может показаться некоторым читателям вполне очевидным, но мы все равно упомянем об этом. Не обязательно использовать Redux. Иногда имеет смысл и вовсе не делать этого. Если какой-либо из сценариев ниже верен для вас, вам, вероятно, вообще не нужен Redux:
- Вы и ваши друзья (или коллеги) уже получили заранее определенный способ совместного использования и организации состояния между компонентам. Иными словами, вам уже было сказано в каком фреймворке нужно доделать/переделать/создать.
- Вы все еще обучаетесь работать в React или любом ином фреймворке. Redux необычен и без знания, как минимум, того же React новичкам может быть сложновато.
- Если приложение будет состоять в основном из простых действий, таких как изменения пользовательского интерфейса, то они вполне могут и не быть частью хранилища Redux. Обработать их можно на уровне компонентов.
- Вам не нужно управлять событиями на стороне сервера (SSE) или группой веб-сайтов, что будут использовать одинаковые компоненты, но с изменяемым состоянием.
- Если планируется создать выборку данных из одного источника данных для каждого представления.
Нашли что-то свое, тогда с большой вероятностью Redux может не потребоваться. И неважно, какое приложение, какая работа сайта и какой проект. Все зависит от их сложности, масштабности. Но что касается самого Redux, то этот фреймворк при своем весе около 2 КБ имеет весьма непростые возможности.
Redux в частях и под лупой
Действия (actions)
Это просто события, созданные с помощью функций для отправки данных из приложения в хранилище. Данные могут быть отправлены различными способами, такими как отправка формы, вызов API или обычного взаимодействия с пользователем. Каждое действие в Redux имеет свойство type, которое описывает тип действия, а также «важную» информацию, отправляемую в хранилище. Давайте рассмотрим самый простой пример действия (actions.js) в работе, размещенного на GitHub.
Чтобы вызвать действие в любом месте приложения, Redux использует метод dispatch(), который отправляет действия в хранилище Redux, указывающие на изменение состояния (dispatch.js)
Редюсеры (Reducer)
Поскольку Redux не позволяет приложению вносить изменения в состояния компонентов, сохраняемых в хранилище, он использует dispatch() для этого. Функция dispatch() просто указывает на намерение изменить данное состояние, но на самом деле не меняет его ... вот почему и нужны редюсеры (Reducer).
Редюсеры (Reducer) – это функции, которые считывают из хранилища текущее состояние приложения через отправленное действие, а затем возвращают новое состояние. Посмотрим на код ниже (handle-auth.js), который получает данные о текущем состоянии, а затем возвращает следующее состояние:
При создании более сложных приложений рекомендуется использовать метод combineReducers(). Этот метод объединяет все редюсеры в приложении в один список функций (index-reducer.js), где каждый из них обрабатывает свою часть состояния приложения, а параметр состояния отличается и является персональным для каждой функции.
Здесь также стоит отметить, что редюсеры должны быть написаны с чистыми функциями, особенности которых в том, что:
- Они не делают внешних вызовов сети или базы данных.
- Их возвращаемые значения зависят только от значений их параметров.
- Их аргументы следует рассматривать как неизменяемые, то есть их не стоит менять вообще.
Хранилище
Хранилище похоже на сердце фреймворка Redux. Это единственный источник истины, в котором находятся все состояния приложения и который обеспечивает доступ к состоянию с помощью нескольких методов, действий отправки данных и регистрации записей. Любое отправленное действие возвращает новое состояние данных в хранилище с помощью редюсеров. И вот как выглядит код хранилища (create-store.js)
Функциональное программирование и Redux
Если вы уже определились и решили использовать Redux в своей работе, кроме всего вышесказанного необходимо знать, как работает функциональное программирование. Redux был основан на принципах функционального программирования и понимание его концепций даст яркое и четкое представление о том, как Redux работает в целом, и почему он способен делать именно то, что делает. Без понимания целостности фреймворка работать в нем сложно и относится такая мысль ко всем средам разработки без исключения.
Так что же это за принципы такие «функционального программирования»?
- Могут использоваться «чистые», первого класса.
- Могут использоваться вспомогательные функции (высшего порядка), такие как карта (map), фильтр (filter).
- Функции могут связываться вместе, рассматриваться, как объекты первого класса, передаваться в качестве аргументов.
- Существует возможность управления потоком данных и объектов, используя функции и массивы.
- Порядок выполнения кода неважен
Функциональное программирование включает в себя написание более простых, меньших и изолированных функций. Следуя этой схеме работа с кодом, тестирование и отладка упрощаются. Поскольку функции малы и изолированы, это делает их многоразовыми в использовании. Вот и поэтому их можно копировать и вставлять в любое место, туда, где они необходимы.
Это также позволяет избежать ситуаций, когда необходимо писать больше кода. Но опять же, функциональное программирование требует понимания понятий, таких как чистые функции, анонимные функции, закрытие и функции первого класса. И это только часть нужных понятий.
Завершение
Это правда. Redux является большой библиотекой по управлению состоянием приложения. И так же, правда и то, что свою популярность фреймворк заслужил. Но что особенно может быть интересным, что Redux успешно применяется в таких проектах, как Wordpress, аналогично тому, как RedBox нашел применение в Uber и Twitter. И еще одна правда заключается в том, что Redux не слишком-то подходит для каждого конкретного приложения.
Приложения, выполняющие, в основном, простые действия и не требующие рендеринга (обработки) на стороне сервера, вероятно, не нуждаются в Redux; их действия можно обрабатывать на уровне компонентов. Но в любом случае, Redux – отличный инструмент, который стоит попробовать тем, кому нравится React; если уже знакомы с React и умеете в нем работать.
Впрочем, как и всегда, некоторые полагают Redux устаревшим для работы с данными. Но тут уж, кому и что ближе, а факты – они просто есть.
