Что такое react redux
Итак, вот некоторые особенности Redux, с которыми вы, наверняка, уже сталкивались, но не совсем понимали, что и как они делают… и, конечно же, примеры.
Мы рассмотрим 15 малоизвестных особенностей Redux:
1. Ключевые принципы Redux
В основе работы Redux лежат 3 главных принципа:
1️⃣ Единственный источник истины
Это означает, что состояние всего приложения содержится в хранилище в виде дерева объектов.
2️⃣ Состояние только для чтения
Состояние можно изменить только при отправке действия.
Так как все состояния централизованы и происходят последовательно друг за другом, то нет необходимости следить за состоянием гонки.
3️⃣ Изменения выполняются чистыми функциями
Вы пишите редукторы, чтобы указать на изменение состояния при помощи действий.
Так как редукторы являются чистыми функциями, вы можете контролировать порядок их вызова, отправлять дополнительные данные или даже писать переиспользуемые редукторы.
2. Преимущества Flux перед Redux
Flux — это шаблон, Redux — библиотека. При использовании Redux вам придется пойти на некоторые компромиссы:
3. Различие между mapStateToProps() и mapDispatchToProps()
> mapStateToProps()
Это утилита, которая помогает вашему компоненту обновлять состояние (которое обновляется некоторыми другими компонентами). Эта функция передается в качестве первого аргумента в connect и впоследствии будет вызываться каждый раз при изменении состояния хранилища Redux.
> mapDispatchToProps()
Это утилита, которая помогает вашему компоненту запускать событие действия (отправка действия, которое может вызвать изменение состояния приложения). Компонент получает [dispatch](https://react-redux.js.org/api/connect#dispatch) по умолчанию.
4. Диспетчеризация действия в редукторе
Причиной для внесения этого пункта в мой список стал следующий популярный вопрос со Stackoverflow: “Можно ли отправить действие в самом редукторе?” Отвечая на этот вопрос, скажу лишь одно:
Отправка действия в редуктор — это анти-шаблон.
5. Диспетчеризация действия при загрузке
6. Сброс состояния в Redux
7. Использование символа @ в функции декораторе connect
В JavaScript символ @ используетсядляобозначения декораторов, при помощи которых выдобавляете или видоизменяете классы и свойства.
8. Различие между React context и React-Redux
> React context
React context предоставляет способ направлять данные через дерево компонентов без необходимости передачи свойств сверху вниз вручную на каждом уровне.
Используется для небольших приложений, тогда как Redux сам по себе обеспечивает более основательное и мощное управление состояниями.
> React-Redux
React-Redux — это официальная библиотека, которая предоставляет привязки React для Redux. Она позволяет компонентам React считывать данные из хранилища Redux и отправлять туда действия для обновления данных.
9. Создание AJAX-запроса в Redux
AJAX позволяет отправлять асинхронные HTTP-запросы для передачи и извлечения данных с сервера.
Чтобы выполнить вызов AJAX в Redux, можно использовать мидлвар redux-thunk для определения асинхронных действий.
10. Лучший способ получить доступ в хранилище Redux
Лучший способ — использовать функцию connect() с применением шаблона функций высшего порядка. Это позволяет отобразить креаторы состояния и действия в компонент и автоматически передать их, когда обновится хранилище.
11. Зачем использовать константы?
ownProps является необязательным параметром, который мы добавляем в mapStateToProps() или mapDispatchToProps() в качестве второго аргумента. Используйте его в том случае, если вашему компоненту нужны данные из его собственных свойств для извлечения данных из хранилища.
Вам необязательно включать значения из ownProps в объект, возвращаемый из mapStateToProps . connect автоматически объединит разные источники свойств в конечный набор.
13. Различие между call() и put() в Redux-Saga
redux-saga — это библиотека, которая призвана облегчить управление побочными эффектами приложения, а также сделать их более эффективными в выполнении, легкими в тестировании и способствующими улучшению обработки ошибок.
Проще говоря, вы используете call() для создания описания эффекта, который дает команду мидлвару для вызова промиса. После этого мидлвар вызывает функцию и проверяет ее результат.
Таким образом, call() и put() являются функциями креаторов эффектов.
14. Различие между Redux-Saga и Redux-Thunk
Мидлвар Redux Thunk позволяет написать креатор действия, который возвращает функцию вместо действия. Thunk можно использовать для задержки отправки действия или для отправки только при выполнении определенного условия.
15. Установка начального состояния в Redux
Существуют 2 способа:
2.Использовать явную проверку внутри редуктора.
Надеюсь, я понятно объяснил эти 15 особенностей Redux. Интересно, а знали ли вы о них?
Основы Redux для начинающих
Что такое Redux?
Redux — это инструмент для управления состоянием приложения. Построен на принципах технологии Flux и функционального программирования. Создан компанией FaceBook, но вопреки распространенному мнению может использоваться не только в связке с React, но также и с другими фреймворками/библиотеками.
Flux — это тип архитектуры и набор паттернов проектирования веб-приложений. Подробнее на Wiki
Redux использует методологию flux. Она состоит из 4 понятий:
В React по умолчанию нет какого-то глобального state (состояния), которое было бы доступно во всем приложении. Вы можете только сохранять данные в рамках одного компонента. К примеру, у вас есть интернет магазин и в нем есть корзина с товарами. Если работать только со стейтом компонента Корзина, то вам эти данные будут недоступны в других компонентах. Также например, у вас есть иконка корзины в углу экрана, которая должна показывать количество товара, которые пользователь добавил туда. Так вот средствами чисто React, это будет сложно реализовать.
Вот именно поэтому есть такие библиотеки как Redux, для хранения всех данных приложения в одном месте и удобного их обновления.
Основные понятия Redux
Как я уже писал выше, основные понятия редакса — actions, dispatcher, store.
Store — это состояние веб-компонента, которое хранит в себе всю информацию (или ту которую вы решили сохранить в него). В дальнейшем стор будет доступен из любого компонента вашего приложения.
Action — действие, описывает что нужно сделать. Согласно принципам функционального программирования, мы не можем изменять объект напрямую, поэтому нам нужны экшены, чтобы передать их в диспатчер и «сказать», что нужно сделать.
Dispatcher — сообщает хранилищу о каком-то действии (action) и передает ему обновленную информацию.
Теперь когда мы разобрали основные понятия, давайте посмотрим как работает Redux:
Схема работы Redux
Компонент генерирует действие (action), диспатчер сообщает об этом хранилищу (store), хранилище изменяет состояние и данные передаются в компонент (View).
Есть еще одно понятие в Redux это reducer (редюсер). Редюсер — это чистая функция, которая принимает как аргумент хранилище и экшен. Основные правила редюсеров:
Более подробно про чистые функции можно прочитать тут.
Простой пример использования Redux
Теперь на простом практическом примере разберем как работать с Redux.
Мы сделаем простое приложение ToDo, которое даст возможность создавать свои таски с сохранением их в store. Это будет простое приложение для примера, основной упор сделан на работу с Redux.
Итак, есть 2 варианта, вы можете скачать стартовый проект и просто запустить установку, или пошагово пройти и создать проект со старта.
Установка и настройка проекта
Чтобы создать приложение заново, открываем командную строку или Git Bash
Далее заходим в папку проекта и устанавливаем Redux и пакет для Реакта — react-redux
Если вы скачали архив с уже готовым приложением, тогда его нужно распаковать, войти в папку с приложением и в командной строке/терминале запустить команду:
Теперь, чтобы запустить наш проект нужно воспользоваться следующей командой:
Проект будет собран и запущен, автоматически откроется вкладка в браузере
Результат выполнения команды npm run start
Для того, чтобы не верстать всё заново, мы используем Bootsrap. Давайте его установим.
Также подключим стили в файле src/index.js
Создание базовой структуры для хранилища
Теперь давайте сделаем базовую структуру для Redux. Создадим папку src/store, а в ней 4 файла
Сначала определим какие типы экшенов нам нужны в файле actionTypes.js. Можно типы и не определять, но в дальнейшем это даст нам возможность сократить время на дебагинг, если вдруг понадобится изменить имя экшена, они все находятся в одном месте, что тоже удобно. Если нам понадобится экшен в другом месте, нам достаточно будет импортировать его в другом модуле.
В нашем приложении, например, нам нужен будет экшен в 2 файлах: actions и reducer. Создадим файл actionTypes.js и в нем определим наши типы:
В файле store/actions.js мы опишем все экшены, которые нам потребуются для приложения:
Выше вы видите типичную структуру экшена: это функция, которая возвращает объект с двумя свойствами:
Теперь давайте рассмотрим функцию редюсер (store/reducer.js):
Тут мы импортируем наши типы экшенов, затем определяем переменную для того, чтобы задавать ID каждому новому таску.
Сам reducer принимает в качестве аргументов state (или равняется пустому массиву) и экшен. Далее мы проверяем тип екшена и в зависимости от этого производим определенные манипуляции со стейтом.
Давайте размеберем на примере экшена TASK_ADD. При добавлении нового таска, нам необходимо сделать копию текущего стейта и добавить к нему новый таск
Далее на основании этого редюсера нам нужно создать store с помощью функции createStore. Создадим файл store.js с таким содержимым:
* У меня также вторым параметром добавлена след. строка
Это для работы плагина для Chrome — Redux DevTools. Удобный плагин для дебагинга.
Теперь после создания store, мы можем использовать его в любом модуле нашего приложения.
Основные методы для работы со store
Redux в функциональных компонентах (хуки)
Наше приложение будет построено при помощи функциональных компонентов и хуков, поэтому мы немного рассмотрим какие хуки предоставляет нам Redux для работы в таких компонентах.
. В документации редакса говорится о том, что лучше этот хук не использовать часто, а лучше пользоваться useSelector()
Теперь давайте вернемся к нашему приложению. В index.js нам нужно обернуть наше приложение в компонент Provider и передать ему store через пропсы. Store мы создали в файле store/store.js
Следующим шагом давайте создадим папку, в которой будем хранить наши компоненты и назовем ее componetns. В ней создадим 3 файла:
Для начала импортируем хук useDispatch(), т.к. в этом компоненте мы будем диспатчить 2 экшена: выполнение таска (toggleTask) и удаление (removeTask). В компоненте у нас есть событие onChange — при клике на этот компонент мы будем диспатчить экшен для переключения состояния таска, ну а при клике кнопки удалить — диспатчим экшен для удаления таска из нашего стора.
Далее файл src/components/TaskList.js
Теперь последний компонент AddNewTask.js
Тут у нас будет 2 обработчика handleTaskTitleChange() и handleTaskSubmit(). Последний будет диспатчить экшен для создания нового таска. В идеале, тут бы еще добавить проверку на пустую строку и обрезать лишние пробелы, но у нас не об этом сейчас 🙂
Теперь остался заключительный шаг, изменить файл scr/App.js и добавить немного стилей
В итоге у нас получилась вот такое приложение
Итоговое приложение
Redux: шаг за шагом
никаких деревьев, только камни
Redux стал одной из самых популярных реализаций идей Flux для управления потоком данных в приложениях на React. Однако в процессе изучения Redux часто возникает ситуация, когда «из-за деревьев мы не видим леса». Далее будет представлен простой и продуманный подход к приложениям, использующих Redux. На примерах мы шаг за шагом реализуем рабочее приложение, попытаемся применить принципы Redux на практике и обосновать каждое решение.
Продуманная методология для идиоматического Redux
Redux — это не просто библиотека. Это целая экосистема. Одна из причин его популярности — это возможность применять различные паттерны проектирования и подходы к написанию кода. К примеру, если мне нужно совершить некоторые асинхронные действия, то мне стоит использовать санки? Или может быть промисы? Или саги?
Какой подход верный? Единственного и четкого ответа нет. И нет «лучшего» пути использования Redux. Стоит признать, что большой выбор подходов заводит в тупик. Я хочу продемонстрировать свой личный вариант использования библиотеки. Он понятный, применимый к самым разнообразным сценариям из жизни и, что самое главное, он прост в освоении.
Итак, пора создать наше приложение!
Для продолжения нам нужен реальный пример. Давайте создадим приложение, показывающее самые популярные посты с Reddit.
На первом экране мы выясним у пользователя три наиболее интересные для него темы. После того, как пользователь сделает выбор, будем показывать список постов по выбранным темам (все посты либо посты по конкретной теме). По клику на пост в списке будем показывать его содержание.
Установка
Поскольку мы используем React, то для начала работы возьмем Create React App — официальный стартовый шаблон. Также установим redux, react-redux и redux-thunk. Результат должен быть похож на этот.
Давайте изменим index.js и создадим в нем стор, подключим санки:
Одна из главных вещей, которая часто упускается в различных Redux туториалах: а где же место Redux в этом цикле? Redux является реализацией Flux-архитектуры — паттерна для организации передачи данных в React-приложениях.
В классическом Flux для хранения стейта приложения используется стор. Диспатчинг ( передача) экшенов вызывает изменение этого стейта. После этого происходит перерендер представления в соответствии с измененным стейтом:
Flux упрощает разработку, создавая однонаправленный поток данных. Это уменьшает спагетти-эффект по мере роста кодовой базы приложения.
Одна из сложностей в понимании работы Redux — это множество неочевидных терминов типа редюсеров, селекторов и санков. Для более четкого понимания взглянем на расширенный Flux-цикл. Это просто различные Redux-инструменты:
Как вы могли заметить другие Redux-инструменты типа миддлваров или саг не показаны. Это сделано намеренно, эти инструменты не играют существенной роли в нашем приложении.
Файловая структура проекта
Создадим корневую папку /src и в ней следующие подкаталоги:
Папка store в свою очередь состоит из доменов, которые содержат:
State-first подход
Наше приложение имеет две стадии. На первой мы предлагаем пользователю выбрать три темы. Мы можем начать с реализации любого элемента Flux-цикла, но для себя я выяснил, что проще всего начать со стейта.
Итак, какой стейт приложения требуется для первой стадии?
Нам нужно будет сохранить список тем, полученных с сервера. Также нужно будет сохранить id выбранных пользователем тем (максимум три id). Будет нелишним сохранить порядок выбора. Например, если, в нашем случае, уже выбрано три темы и пользователь выбирает ещё, то мы будем удалять самую старую из выбранных тем.
Каким образом будет стуктурно организован стейт приложения? В моей предыдущей статье есть список полезных советов — Avoiding Accidental Complexity When Structuring Your App State. Руководствуясь этими советами, мы получим следующую структуру:
URL каждой темы будет служить уникальным id.
Я подготовил шаблон для создания редьюсера, вы можете посмотреть на него здесь. Обратите внимание, что для обеспечения иммутабельности нашего состояния (как того требует Redux), я выбрал библиотеку seamless-immutable.
Наш первый сценарий
Шаблон для создания умного компонента можно найти здесь. Также нам будет нужно вызвать его внутри корневого компонента App. Теперь, когда всё настроено, попробуем получить несколько тем с сервера Reddit.
Правило: умные компоненты не должны содержать никакой логики, кроме передачи действий (диспатчинг экшенов ).
Наш сценарий начинает работу с использования componentDidMount — метода представления. Исходя из правила выше, мы не можем запускать логику прямо из представления. Поэтому, для получения списка тем, мы будем диспатчить экшен. Это асинхронный экшен и он будет реализован с помощью санков.
Текущий исходный код нашего приложения можно увидеть здесь.
Несколько слов о сервисах
Как уже отмечалось ранее, сервисы используются для работы с внешним API, в большинстве случаев с сервер-API, как API Reddit. Плюс от использования сервисов в том, что наш код становится более независимым от изменений API. Если в будущем Reddit решит что-то изменить (конечную точку, названия полей), то эти изменения затронут только наши сервисы, а не всё приложение целиком.
Правило: cервисы должны быть stateless (то есть не должны иметь состояния).
На самом деле, это довольно неочевидное правило в нашей методологии. Представим, что случилось бы, если бы наше API требовало пароль. Мы могли бы сохранить стейт для логина с помощью данных для входа в систему внутри сервиса.
Однако наша методология разработки не позволила бы сделать это. Потому что весь стейт приложения должен находиться в сторе. Подходящим решением в этом случае будет передача каждого сервиса с данными для логина в виде аргумента и сохранения стейта логина в редюсере.
Реализация сервиса довольно проста, увидеть её можно здесь.
Завершение сценария — редюсер и представление
После того, как стейт обновился, мы должны вызвать перерендер представления. Это значит, что представление должно улавливать изменения той части стейта, от которого оно зависит. Это делается с помощью mapStateToProps.
Правило: умные компоненты должны обращаться к состоянию только с помощью селекторов.
Почему? Идея состоит в том, чтобы инкапсулировать внутренний стейт приложения и скрыть его от представления. Представьте, что позже мы решили изменить внутреннюю структуру. Без селекторов нам пришлось бы вносить изменения в каждый компонент представления, что нежелательно. Использование селекторов позволит проводить рефакторинг, изменяя только редьюсер.
Сейчас topics/reducer.js выглядит так:
Несколько слов о глупых компонентах
Глупые компоненты получают данные от родителя через пропсы и могут хранить локальный стейт.
Итак, когда же нам надо переходить от умного компонента к глупому?
Правило: вся логика представления в умных компонентах должна выноситься в глупые.
Если вы посмотрите на реализацию ListView, то вы можете увидеть некоторые скрипты представления, например итерацию строк. Мы должны избегать написания такой логики внутри умного TopicsScreen. Такой подход позволяет пользоваться умными компонентами только как прослойками. Другой плюс такого подхода в том, что ListView становится переиспользуемым.
Следующий сценарий — выбор нескольких тем
Первый сценарий завершен. Переходим к следующему: пользователь может выбрать только три темы из списка.
Важно отметить, что санку нужно получить доступ к состоянию. Также обратите внимание, что соблюдается правило, по которому доступ к стейту осуществляется через селектор.
Нам нужно будет обновить редюсер таким образом, чтобы он мог обрабатывать TOPICS_SELECTED и сохранять новые выбранные темы. Возникает вопрос, а должен ли selectTopic быть санком? Ведь мы можем сделать selectTopic простым объектом действия и передать его внутрь редюсера. Это тоже правильный подход. Лично я предпочитаю хранить бизнес-логику в санках.
Несколько слов о бизнес-логике
Один из принципов хорошей методологии является разделение представления и бизнес-логики. Где на данный момент у нас реализована бизнес-логика?
Правило: вся бизнес-логика должна находиться внутри обработчиков событий (санков ), селекторов и редюсеров.
Переход к следующей стадии — список постов
Когда у нас больше одного экрана в приложении, то нам нужна навигация. Зачастую для навигации используется react-router. Я сознательно избегаю маршрутизации, чтобы не усложнять наше приложение. Выбор внешних зависимостей, таких как маршрутизатор, часто отвлекает от основного процесса разработки.
Это все похоже на то, что мы уже делали ранее, за исключением одного: мы должны знать, когда именно показывать кнопку (как только будет выбрано минимум три темы). Возможно у вас возникнет желание добавить новую переменную для этих целей. Это избыточно: эквивалентное значение мы уже можем получить из данных, которые есть в стейте. Следовательно, эту часть бизнес-логики мы должны реализовать, как селектор.
Экран постов — снова state-first
Напоминание: задача второй стадии — отобразить список постов, которые можно отфильтровать в зависимости от выбранной темы. Пользователь может кликнуть на пост в списке и увидеть его содержание. Следуя обозначенной ранее структуре, получаем следующее:
И создаем новый редюсер здесь.
Первый сценарий — список постов без фильтрации
Наш стейт готов! Теперь реализуем упрощенную версию сценария без фильтра.
Это все очень похоже на то, что мы делали ранее. Реализация, по традиции, здесь.
Впрочем, ничего нового: реализация на месте.
Следующий сценарий — фильтр постов
Сценарий начинается с показа пользователю доступных фильтров. Мы можем получить данные, используя стейт редьюсера тем с помощью уже готового селектора. Когда фильтр будет выбран, мы диспатчим экшен, изменяющий стейт с помощью редюсера постов.
Полная реализация этого шага здесь.
Последний сценарий — содержание поста
Все готово
Код выше завершает реализацию нашего приложения. Полная версия приложения доступна на GitHub: https://github.com/wix/react-dataflow-example.
Какие выводы мы сделали:
Помните, что Redux предоставляет большое поле для экспериментов. Существуют подходы отличные от того, что использовали мы. У меня есть друзья, предпочитающие использовать redux-promise-middleware вместо санков и писать бизнес-логику только в редюсерах.
Если вы хотите поделиться своей собственной методологией для решения нашей задачи, не стесняйтесь: делайте PR в репозиторий проекта и мы рассмотрим его.
Краткое руководство по Redux для начинающих
Библиотека Redux — это способ управления состоянием приложения. Она основана на нескольких концепциях, изучив которые, можно с лёгкостью решать проблемы с состоянием. Вы узнаете о них далее, в этом руководстве по Redux для начинающих.
Примечание Вы читаете улучшенную версию некогда выпущенной нами статьи.
Содержание:
Когда нужно пользоваться Redux?
Redux идеально использовать в средних и крупных приложениях. Им стоит пользоваться только в случаях, когда невозможно управлять состоянием приложения с помощью стандартного менеджера состояний в React или любой другой библиотеке.
Простым приложениям Redux не нужен.
Использование Redux
Разберём основные концепции библиотеки Redux, которые нужно понимать начинающим.
Неизменяемое дерево состояний
В Redux общее состояние приложения представлено одним объектом JavaScript — state (состояние) или state tree (дерево состояний). Неизменяемое дерево состояний доступно только для чтения, изменить ничего напрямую нельзя. Изменения возможны только при отправке action (действия).
Действия
Действие (action) — это JavaScript-объект, который лаконично описывает суть изменения:
Типы действий должны быть константами
В простом приложении тип действия задаётся строкой. По мере разрастания функциональности приложения лучше переходить на константы:
и выносить действия в отдельные файлы. А затем их импортировать:
Генераторы действий
Генераторы действий (actions creators) — это функции, создающие действия.
Обычно инициируются вместе с функцией отправки действия:
Или при определении этой функции:
Редукторы
При запуске действия обязательно что-то происходит и состояние приложения изменяется. Это работа редукторов.
Что такое редуктор
Редуктор (reducer) — это чистая функция, которая вычисляет следующее состояние дерева на основании его предыдущего состояния и применяемого действия.
Чистая функция работает независимо от состояния программы и выдаёт выходное значение, принимая входное и не меняя ничего в нём и в остальной программе. Получается, что редуктор возвращает совершенно новый объект дерева состояний, которым заменяется предыдущий.
Чего не должен делать редуктор
Редуктор — это всегда чистая функция, поэтому он не должен:
Поскольку состояние в сложных приложениях может сильно разрастаться, к каждому действию применяется не один, а сразу несколько редукторов.
Симулятор редуктора
Упрощённо базовую структуру Redux можно представить так:
Состояние
Список действий
Редуктор для каждой части состояния
Редуктор для общего состояния
Хранилище
Хранилище (store) — это объект, который:
Хранилище в приложении всегда уникально. Так создаётся хранилище для приложения listManager:
Хранилище можно инициировать через серверные данные:
Функции хранилища
Прослушивание изменений состояния:
Поток данных
Поток данных в Redux всегда однонаправлен.
Передача действий с потоками данных происходит через вызов метода dispatch() в хранилище. Само хранилище передаёт действия редуктору и генерирует следующее состояние, а затем обновляет состояние и уведомляет об этом всех слушателей.
Советуем начинающим в Redux прочитать нашу статью о других способах передачи данных.