Зачем нужны миддлвары?

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

- логирование
- запросы к серверу и другой асинхронный API
- маршрутизацию приложения
- изменение экшенов
- задержка выполнения (или прекращение)

https://codesandbox.io/s/react-redux-async-actions-react-junior-t2npxd?file=/src/store/checking/index.js

Добавим в наше приложение проверку текста новой задачи перед ее добавлением в список. Представим, что у нас есть какой-то api (асинхронный), который умеет анализировать текст. Если задача полезная, будем выводить поощрительное сообщение, а если нет - то осуждающее (и не будем добавлять эту задачу в список).

Для этого:

- добавляем новый редьюсер (checkingReducer) и набор экшенов (START_CHECKING, FINISH_CHECKING, SET_CHECKING_STATUS;
- добавляем компонент CheckingStatus, который отслеживает статус проверки и выводит сообщение;
- создаем миддлвар checkText, который реагирует только на события добавления нового элемента в список. Он останавливает цепочку обработки экшена и отправляет запрос на проверку текста. Только после окончания проверки он запускает цепочку обработки дальше (если нет ошибки), и экшен отправляется в редьюсер.

#управлениесостоянием #redux #началоработы #примерыкода #документация

Экшены-функции

Еще один вариант - переместить код, связанный с экшеном в функцию-создатель экшена. Но тут есть проблема - у функций-создателей нет доступа к методу store.dispatch.

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

https://codesandbox.io/s/react-redux-functional-actions-react-junior-zyleg0?file=/src/store/items/actions.js

const handleFunction = function(storeAPI) {
  return function(next) {
    return function(action) {
      if (typeof action === 'function') {
        return action(storeAPI.dispatch, storeAPI.getState)
      }

      return next(action)
    }
  }
}

#управлениесостоянием #redux #началоработы #примерыкода #документация

Thunk

И наконец, у Redux есть официальный миддлвар для обработки функциональных экшенов - пакет redux-thunk. Можно заменить нашу самописную handleFunction на него:

https://codesandbox.io/s/react-redux-thunk-react-junior-d71jls?file=/src/store/index.js

#управлениесостоянием #redux #началоработы #примерыкода #документация

Redux: документация и туториалы

У Redux реально огромная и максимально подробная документация. Помимо прочего, там есть два официальных туториала:

* Redux Essentials - изучение сверху вниз, демонстрация лучших практик и распространенных кейсов.

* Redux Fundamentals - изучение снизу вверх, от основ, для лучшего понимания.

Мы, разумеется, начали снизу вверх, как я люблю)) Сначала основы, потом лучшие практики.

#redux #документация

Поток данных в Redux

Визуализация однонаправленного потока данных: https://redux.js.org/assets/images/ReduxDataFlowDiagram-49fa8c3968371d9ef6f2a1486bd40a26.gif

- UI вызывает экшен
- он отправляется в редьюсер
- редьюсер изменяет состояние
- из-за этого изменяется UI

#redux #документация #управлениесостоянием

Основные концепции Redux

- Глобальное состояние является единственным источником правды для интерфейса, все данные находятся в одном месте. Так проще работать, и это проще отлаживать.

- Состояние доступно только для чтения. Любые изменения - только через экшены и редьюсер. Таким образом, интерфейс не сможет случайно переписать состояние.

- Иммутабельность состояния. Редьюсер не мутирует состояние, а создает его копию.

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

#важно #управлениесостоянием #redux #документация

Использование useSelector

Важно: можно использовать хук useSelector несколько раз в одном компоненте, чтобы получать данные из хранилища отдельными маленькими порциями (особенно несвязанные данные). Документация называет это хорошей идеей.

#управлениесостоянием #redux #началоработы #документация #важно

​Асинхронный поток данных в Redux

Миддлвары позволяют добавлять в приложения асинхронную логику изменения состояния. Вот так это выглядит на схеме: https://redux.js.org/assets/images/ReduxAsyncDataFlowDiagram-d97ff38a0f4da0f327163170ccc13e80.gif

Обычный поток данных здесь: https://yangx.top/react_junior/277

#управлениесостоянием #redux #документация

Глобальное и локальное состояние

Должно ли все состояние приложения быть глобальным и содержаться в хранилище? Конечно, нет.

В глобальное состояние нужно выносить только минимально необходимый набор данных. Если вы не уверены, являются ли те или иные данные глобальными, документация Redux дает ряд подсказок:

- Знают ли другие части приложения об этих данных?
- Нужно ли вам на основе этих данных создавать какие-то другие производные данные (например, отфильтрованный список)?
- Используются ли эти данные в нескольких компонентах?
- Есть ли потребность в том, чтобы иметь возможность восстановить состояние этих данных для заданного момента времени (например, история действий пользователя)?
- Хотите ли вы кешировать эти данные (например, чтобы избежать нескольких запросов к серверу)?
- Хотите ли вы сохранить консистентность (согласованность) этих данных во время hot reloading (внутреннее состояние компонентов при этом может быть сброшено)?

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

#управлениесостоянием #redux #началоработы #документация

Почему редьюсер называется редьюсером

В JavaScript есть метод Array.reduce(), который дает возможность превратить входной массив в одно единственное значение согласно какой-то логике - буквально уменьшить (reduce) массив до значения.

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

- previousResult - предыдущее значение, которое было возвращено предыдущим вызовом коллбэка. По факту это накопленное на данный момент значение.
- currentItem - текущий элемент массива, для которого вызывается коллбэк.

Точно так же работает и редьюсер в Redux.

При первом вызове (для первого элемента массива), previousResult еще не существует, поэтому мы используем какое-то начальное значение.

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

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

 
const actions = [
    { type: 'counter/incremented' },
    { type: 'counter/incremented' },
    { type: 'counter/incremented' }
]
 
const initialState = { value: 0 }
 
const finalResult = actions.reduce(counterReducer, initialState)

// {value: 3}

#управлениесостоянием #redux #документация

​Redux DevTools

Redux DevTools - это расширение для браузера (доступно в Chrome и Firefox ). Оно дает возможность просматривать все изменения хранилища.

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

Подключаем пакет redux-devtools-extension и импортируем из него функцию composeWithDevTools. Это аналог функции compose, но тут автоматически еще добавляется интеграция с браузерным расширением.

import { composeWithDevTools } from "redux-devtools-extension";
const store = createStore(rootReducer, composeWithDevTools());

Посмотреть расширение в действии можно здесь: https://furrycat.ru/redux-test/

- Установите расширение
- Откройте панель разработчика - вкладка Redux
- Кликайте на кнопки

#управлениесостоянием #redux #инструменты

Проблемы селекторов

Селекторы - удобные штуки, которые инкапсулируют в себе все общение с хранилищем, однако, у них есть ряд недостатков.

‼️ Проблема #1. Вызов на каждый чих

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

https://codesandbox.io/s/selectors-problems-1-react-junior-5f3kf7?file=/src/store.js

В хранилище есть два поля: items и counter. Они никак не связаны друг с другом. Есть также два селектора getItems и getCounter.

При изменении счетчика (события INCREMENT, DECREMENT) поле items никак не меняется, даже ссылка на него остается прежней. Однако селектор getItems все равно запускается. Он выполняется (возможно с какими-то сложными вычислениями), но возвращает то же самое значение, поэтому ререндера компонента List не происходит.

‼️ Проблема #2. Преобразование ссылочных типов данных

Если у нас есть, например, массив каких-то значений (например, пользователей), а мы в селекторе хотим получить только идентификаторы этих пользователей, то мы используем метод массива .map(). При этом каждый раз создается новый массив, даже если состоит он из тех же самых идентификаторов.

https://codesandbox.io/s/selectors-problems-2-react-junior-8mzn1u?file=/src/store.js

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

✅ Как решить эти проблемы - в следующем посте.

#управлениесостоянием #redux #оптимизация #важно

Reselect - оптимизированные селекторы

В прошлом посте отметили две проблемы селекторов в Redux (возможно, есть еще). Теперь поговорим о решении.

Документация Redux рекомендует использовать библиотеку reselect для создания оптимизированных селекторов.

Идея заключается в том, чтобы отделить простое получение данных из хранилища и их преобразование в селекторе. До этого мы получали данные (store.items) и что-то с ними делали (тяжелые вычисления или маппинг) в одной-единственной функции-селекторе, теперь же нужно разделить этот процесс на несколько функций - отдельно получить, отдельно посчитать.

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

❔Как это работает

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

✅ Решение проблемы #1 (тяжелые вычисления)

https://codesandbox.io/s/selectors-problems-1-reselect-react-junior-0lttp3

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

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

✅ Решение проблемы #2 (маппинг массива)

https://codesandbox.io/s/selectors-problems-2-reselect-react-junior-33czrp?file=/src/components/List.js

Тут решение такое же, как и в прошлом примере. Результат преобразования зависит только от исходного значения. Поэтому мы выносим в отдельный "входной" селектор проверку store.items. Если этот массив не меняется, то и селектор не будет вызван.

#управлениесостоянием #redux #оптимизация #важно

IT-KAMASUTRA о Reselect

У меня была какая-то необъяснимая сложность в понимании reselect, возможно, документация не очень правильно о нем говорит, ну либо причина гораздо более простая 🤓.

В общем, мне немного помогли разобраться три видео из курса по React с канала IT-KAMASUTRA.

81 - React JS - селекторы (reselect part 1)
82 - React JS - mapStateToProps (reselect часть 2)
83 - React JS - подключаем reselect (reselect часть 3)

Есть одна сложность - в курсе речь идет о старой версии redux, в которой не было хуков useDispatch и useSelect. Там все было посложнее, использовался компонент высшего порядка (connect), а глобальное состояние преобразовывалось в пропсы с помощью функций mapStateToProps и mapDispatchToProps. Это может вызвать трудности.

#ссылки #redux #управлениесостоянием

​Reselect

Библиотека для создания мемоизированных селекторов от создателей redux: https://github.com/reduxjs/reselect

Позволяет вычислять "производное" состояние (в хранилище остаются только минимально необходимые данные, все остальное вычисляется).

Селекторы пересчитываются, только если изменяются их зависимости.

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

createSelector (еще раз для полного осознания)

Для создания селектора используется функция createSelector. Она принимает один или несколько "входных" селекторов (в виде массива или просто отдельными аргументами) и один "выходной". Еще может принимать объект с настройками.

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

Для сравнения результатов используется алгоритм строгого сравнения (===, сравнение по ссылке).

Размер кэша

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

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

#redux #управлениесостоянием

Валидация форм в React-приложениях с помощью хука useForm

Статья (англ.): https://blog.openreplay.com/react-form-validation-with-the-useform-hook

Валидация форм в вебе - очень важная задача, которая так до сих пор и не стандартизирована полноценно. Существуют десятки разных решений, и в статье разбирается одно из них - библиотека React Hook Form https://react-hook-form.com/get-started.

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

Предлагаемый библиотекой api интуитивно понятный, хоть и немного громоздкий (впрочем, где вы видели негромоздкую валидацию, да?)

https://codesandbox.io/s/react-hook-form-react-junior-qyv1if?file=/src/App.js

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

Использование

Хук useForm может принимать базовые настройки валидации (можно ничего не передавать и использовать дефолтные) и возвращает несколько методов (`register`, handleSubmit`), а также объект `formState. По названиям очевидно, для чего они предназначены:

* register - регистрирует каждое валидируемое поле с конкретными настройками валидации.
* в handleSubmit нужно передать функцию, которая будет вызвана при удачной отправке формы. Обычно такие методы вызываются на событие form.onsubmit.
* formState содержит актуальную информацию, включая ошибки валидации.

Регистрация поля

Функция register принимает имя поля и объект с настройками валидации и возвращает набор атрибутов для контрола (для отслеживания фокуса и изменений значения). Есть ряд базовых опций, таких как required, minLength, maxLength, pattern. Для каждой настройки можно просто ставить true или конкретное значение (например, минимальная длина или паттерн), а можно передать объект с полями value и message.

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

formState

Содержит флаги isSubmitted, isValid, объект с ошибками errors и др.

#ссылки #валидацияформ

Статус асинхронного запроса

В документации Redux описан хороший паттерн работы с асинхронными запросами. Он не относится непосредственно к Redux, применять его можно где угодно.

Очень часто для отслеживания состояния запроса используют флаги типа isLoading, isLoaded, но намного удобнее иметь дело со строковыми статусами: idle, loading, succeeded, failed. Так проще охватить все возможные состояния и проанализировать их для выведения нужного представления.

Подробнее в документации: https://redux.js.org/tutorials/fundamentals/part-7-standard-patterns#async-request-status

Пример: https://codesandbox.io/s/async-request-status-react-junior-itoqep?file=/src/store/index.js

#redux #документация #паттерны #примерыкода

Flux Standard Actions

Соглашение по структуре экшенов в Redux:

- экшен - это обычный JavaScript-объект
- у него обязательно есть поле type
- любые данные должны лежать в поле payload
- кроме того у экшена может быть поле meta для различной описательной информации
- при необходимости экшен может иметь поле error (булево значение). Если оно равно true, экшен представляет собой ошибку и является аналогом промиса в состоянии rejected. В этом случае в поле payload должен находиться объект ошибки.

#документация #redux #паттерны

Нормализация состояния

Во всех предыдущих примерах элементы хранились в store в виде массива. Но в больших проектах со сложным состоянием разумно использовать другую структуру данных - словарь с доступом по идентификатору (обычный JavaScript-объект).

Это способ "нормализовать" состояние.

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

Допустим, у нас есть массив пользователей и массив постов, которые можно лайкать. Для каждого поста нужно сохранять список пользователей, которые его лайкали. Разумнее сохранять только идентификаторы этих пользователей, а не копировать их полностью. Ведь если придется вносить какие-то изменения, их придется вносить в нескольких местах, что увеличивает вероятность ошибки. При необходимости мы всегда можем получить полные данные пользователя, и удобнее это делать из объекта-словаря (время доступа О(1)), чем из массива (время доступа О(n)).

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

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

Раздел в документации (англ.): https://redux.js.org/tutorials/fundamentals/part-7-standard-patterns#normalized-state

#redux #документация #паттерны

Возращение промиса из thunk

И еще один полезный паттерн, который предлагает нам документация Redux.

Для выполнения асинхронных экшенов мы используем пакет thunk, который позволяет передавать в dispatch функции вместо объектов. Это удобно, например, делать для ajax-запросов к серверу.

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

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

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

Уместо поместить логику отображения лоадера в сам компонент, а не в глобальное хранилище. И это сделать очень просто.

Когда мы передаем в dispatch функцию, thunk возвращает результат ее выполнения. Этим результатом вполне может быть промис, ориентируясь на состояни которого мы можем отображать или скрывать лоадер.

Схема работы

https://codesandbox.io/s/thunks-and-promises-react-junior-5edjgl?file=/src/store.js

Функция addNewTodo(text) это создатель экшена, она возвращает thunk вместо обычного объекта.


function addNewTodo(text) {
return function (dispatch) {
return new Promise(function(resolve) {
// запрос на сервер
dispatch(...)
resolve()
})
}
}


При добавлении нового элемента вызываем dispatch(addNewTodo(text)).

В dispatch попадает функция, а не объект, поэтому она сразу же запускается, а результат этого запуска возвращается.


const [ loading, setLoading ] = useState(false)

const handleSubmit = function() {
setLoading(true)
dispatch(addNewTodo(text)).then(function() {
setLoading(false);
})
}


Таким образом, паттерн заключается в том, что из thunk-функции мы возвращаем промис, который используется непосредственно в компоненте.

#redux #управлениесостоянием #примерыкода #паттерны