Одна из причин за что НЕ любят Redux

Redux был революционной технологией в экосистеме React. Это позволило нам иметь глобальное хранилище и устранило проблему prop drilling в нашем дереве компонентов. Для совместного использования иммутабельных данных в приложении он по-прежнему остается отличным инструментом, который очень хорошо масштабируется.

Проблема одностраничных приложений

Появление фреймворков для создания одностраничных приложений (SPA), например, React, внесло множество изменений в то, как мы разрабатываем веб-приложения. Сильное разделение бэкэнда и фронтенда позволило нам сфокусироваться и разделить задачи между командами. Это также внесло много сложностей, особенно в сопровождении состояния веб-приложения. Асинхронный запрос данных теперь означает, что данные должны находиться в двух местах: во фронтенде и на бекенде. Мы должны подумать о том, как лучше всего хранить эти данные глобально, чтобы они были доступны для всех наших компонентов, сохраняя при этом кэш данных для экономии времени на частых запросах. Большая часть разработки фронтенда теперь включает поддержку глобального хранилища - денормализации данных, устаревание данных и различные специфические баги.

Redux - это не кэш

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

Граница между ответственностью бэкэнда и фротенда быстро стирается, когда мы начинаем воссоздавать базу данных на фротенде . Как фротенд-разработчикам, нам не нужно досконально разбираться в таблицах и их связях, чтобы создать простой пользовательский интерфейс. Нам также не нужно знать, как лучше всего нормализовать наши данные. Эта ответственность должна лежать на людях, которые сами проектируют таблицы — на бэкэнд-разработчиках. Бэкенд-разработчики затем могут предоставить абстракцию для фронтенд-разработчиков в виде документированного API. В настоящее время существует множество библиотек (redux-observable, redux-saga и redux-thunk, и это лишь некоторые из них), построенных вокруг Redux, чтобы помочь нам управлять данными из бэкэнда, каждая из которых добавляет уровень сложности к уже и так сложной для инициализации библиотеке. Иногда нам нужно сделать шаг назад, прежде чем сделать шаг вперед.

Более простой подход к хранению данных с бэкэнда

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

React Query

Это библиотека с очень простым API и парой хуков для управления запросами (выборка данных) и мутациями (изменение данных). Благодаря использованию React Query удается писать гораздо меньше шаблонного кода, чем с Redux. Становится проще сосредоточиться на UI/UX веб-приложения, не заботясь о проблемах поддержки состояния бэкэнда.

Чтобы сравнить эту библиотеку с Redux, рассмотрим пример двух методов. Для примера используем простой список TODO, полученный с сервера. Реализация с Redux.

import React, { useEffect } from "react";
import { useSelector, useDispatch } from "react-redux";
import axios from 'axios';

const SET_TODOS = "SET_TODOS";

export const rootReducer = (state = { todos: [] }, action) => {
  switch (action.type) {
    case SET_TODOS:
      return { ...state, todos: action.payload };
    default:
      return state;
  }
};

export const App = () => {
  const todos = useSelector((state) => state.todos);
  const dispatch = useDispatch();

  useEffect(() => {
    const fetchPosts = async () => {
      const { data } = await axios.get("/api/todos");
      dispatch({
        type: SET_TODOS,
        payload: data
      });
    };

    fetchPosts();
  }, []);

  return (
    <ul>{todos.length > 0 && todos.map((todo) => <li>{todo.text}</li>)}</ul>
  );
};

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

import React from "react";
import { useQuery } from "react-query";
import axios from "axios";

const fetchTodos = async () => {
  const { data } = await axios.get("/api/todos");
  return data;
};

const App = () => {
  const { data } = useQuery("todos", fetchTodos);

  return data ? (
    <ul>{data.length > 0 && data.map((todo) => <li>{todo.text}</li>)}</ul>
  ) : null;
};

По умолчанию код с React Query уже включают повторную выборку данных, кэширование и инвалидацию устаревших данных с предустановленной конфигурацией. Можно также установить конфигурацию кэширования на глобальном уровне. Везде, где вам нужны эти данные, теперь вы можете использовать хук useQuery с уникальным ключом, который вы установили (в данном случае todos), и асинхронным вызовом для получения данных. Пока функция асинхронная, реализация не имеет значения — вы можете так же легко использовать Fetch API вместо Axios. Для изменения внутреннего состояния React Query предоставляет хук useMutation.

SWR

SWR концептуально почти идентичен React Query. React Query и SWR были разработаны примерно в одно и то же время, и оба положительно повлияли друг на друга. В документации по React Query также есть подробное сравнение этих двух библиотек. Как и React Query, SWR также имеет очень удобочитаемую документацию. По большей части вы не ошибетесь ни с одной из библиотек. Независимо от того, что в конечном итоге станет нормой в ближайшем будущем, будет намного проще провести рефакторинг.

Apollo Client

SWR и React Query ориентированы на REST API, но если вам нужно что-то подобное для GraphQL, то явным претендентом является Apollo Client. Также приятно, что синтаксис почти идентичен React Query.

Встроенные возможности для работы с состоянием

Как только вы начнете использовать одну из этих библиотек, вы обнаружите, что в подавляющем большинстве проектов Redux является излишним. Когда не придется самим заниматься запросом и кешированием данных в веб-приложении, на фронтенде останется лишь небольшая часть глобального состояния. То немногое, что осталось, можно обработать с помощью Context API или useContext + useReducer, чтобы создать свой собственный псевдо-Redux. Или, что еще лучше, для простых кейсов можно использовать встроенное состояние React.

// чисто, красиво и просто
const [состояние, setState] = useState();

1. Что такое Redux Saga?

Redux Saga - это библиотека для Redux и является middleware, которая призвана упростить и улучшить выполнение сайд-эффектов. Cайд эффекты - это асинхронные операции, например, загрузка данных либо иные действия, который должны выполняться помимо изменения данных стора (store). В этом видео начинаем полный практический курс по Redux-Saga. Установим Redux Saga middleware в проект, поговорим о том что такое Redux Saga, как работать с этой библиотекой, что такое эффекты redux-saga, хэлперы takeEvery и takeLatest, воркеры и вотчеры и т.д Смотреть на Rutube

2. Как использовать каналы в Redux Saga?

В этом видео курса по Redux Saga поговорим о каналах в Redux Saga, какие типы каналов есть в redux-saga, рассмотри подробнее Action Channel и сравним реализацию саги с Action Channel и с put/takeEvery, также кратко рассмотрим буферы каналов в Redux Saga (redux-saga). Каналы в Redux Saga - позволяют использовать эффекты для общения со сторонним источником данных или между сагами. Также каналы позволяют использовать очередь для указанных действий и выполнять эффекты последовательно. Смотреть на Rutube

3. В чем отличие блокирующих и неблокирующих эффектов в Redux Saga - call и fork?

В этом видео уроке по Redux Saga поговорим о блокирующих и неблокирующих эффектах в redux-saga, самыми популярными примерами которых являются call и fork. Подробно рассмотрим пример login пользователя в приложении на основе эффектов redux-saga. В redux saga есть блокирующие и неблокирующие вызовы эффектов. Эффекты можно условно разделить на блокирующие и неблокирующие. Блокирующий вызов означает, что когда Saga делает yield эффекта она будет ожидать завершения вызова. И только после перейдет к выполнению следующего эффекта. Самый популярный блокирующий эффект - call. Неблокирующий вызовы означает, что saga сразу же перейдет к следующему эффекту не дожидаясь завершения предыдущего. Самый популярный неблокирующий эффект - fork. Смотреть на Rutube

4. Что такое fork и spawn в Redux Saga?

В очередном видео курса по Redux Saga рассмотрим attached и detached эффекты в Redux Saga, реализуем и сравним примеры на основе эффектов fork и spawn. В Redux saga есть понятие attached и detached эффектов. fork - это attached, он привязан к родителю. Если отменить родительскую задачу - то отменятся и все дочерние (форкнутые). spawn - это detached, он к родителю не привязан. Отмена родительской задачи не приводит к отмене spawned задач. Нужно отменять их явным образом. И ошибки, возникшие в этих задачах, до родителя не доходят. Смотреть на Rutube

5. Когда использовать take, takeEvery, takeLatest, takeLeading в Redux Saga?

В очередном видео курса по Redux Saga рассмотрим такие создатели эффектов (Effect creators) как take, takeEvery, takeLatest, takeLeading, рассмотрим их отличия и особенности, а также создадим имплементации takeEvery, takeLatest, takeLeading на основе take. В случае takeEvery вызванные задачи не контролируют, когда они будут вызваны. Они будут вызываться снова и снова при каждом подходящем действии. У них также нет контроля над тем, когда прекратить наблюдение. take - сага сама обрабатывает action - это pull модель. Сага в этом случае активная, а не пассивная. И здесь есть большая свобода как правильно обработать action. take позволяет выстраивать более сложный флоу.

Смотреть на Rutube

6. Каналы событий в Redux Saga - Event channel

В очередном видео курса по Redux Saga рассмотрим Event Channels - еще один тип каналов в Redux Saga. EventChannel (канал событий) помогают получать события из сторонних источников данных, как правило из шин событий (например, из вебсокетов, или из любых других источников, на которые можно подписываться). Смотреть на Rutube

7. Обычные каналы в Redux Saga - Сhannel

В очередном видео курса по Redux Saga рассмотрим обычные каналы (функция channel) в Redux Saga. Напишем загрузчик файлов на сервер, который будет отправлять прогресс загрузки в канал для обновления progress bar в компоненте. Channel или обычный канал в redux-saga - это тип канала, который не привязан к определенному источнику данных. В этот канал отправляются данные при помощи эффекта put. Канал используется для общения между сагами. Смотреть на Rutube

8. Буферы каналов в Redux Saga

В очередном видео курса по Redux Saga рассмотрим буферы каналов (none, fixed, expanding, dropping, sliding). В Redux Saga существует несколько видов буферов, который используются в каналах.

• none - без буфера.
• fixed - новые сообщения будут попадать в буфер фиксированного размера. В случае переполнения буфера будет выброшена ошибка.
• expanding буфер - в случае переполнения буфера, размер буфера будет динамически увеличиваться.
• dropping буфер будет игнорировать сообщения в случае переполнения.
• sliding - будет добавлять новые сообщения в конец буфера и удалять старые сообщения.

Смотреть на Rutube

9. Как сделать Debounce и Throttle в Redux Saga?

В этом видео курса по Redux Saga рассмотрим эффекты debounce и throttle, напишем хэндлеры для чтения значения поля ввода с помощью debounce и throttle, а также напишем кастомную реализацию debounce и throttle с использованием базовых эффектов. throttle - не будет стартовать новую задачу в течении заданного времени и будет получать только самые поздние actions. Т.е. будет обрабатываться только одно событие в течение заданного временного окна. debounce в отличие от throttle не будет запускаться каждые n миллисекунд. Если пришел еще один action, то предыдущая задача отменится и запустится новая с тем же ожиданием. Смотреть на Rutube

10. Как внедрить зависимости в middleware Redux Saga?

В этом видео курса по Redux Saga рассмотрим как передать данные в контекст middleware Redux Saga, как расширить контекст (setContext) и как прочитать данные из контекста (getContext). Смотреть на Rutube

11. Отличия apply и call в Redux Saga?

В очередном видео курса по Redux Saga рассмотрим отличия эффектов apply и call, для чего они используются, как передать объект-контекст и рассмотрим аналогию apply и call в JavaScript при работе с объектом и this Смотреть на Rutube

12. Как запустить несколько саг в Redux Saga?

В Redux Saga существует множество способов запустить несколько саг одновременно. В основном это необходимо для запуска рутовой саги, в которой могут быть запущено множество саг. То как запускать саги зависит от ситуации. Например, нужно ли чтобы ошибка поднималась вверх в рутовую сагу или это не принципиально. Самые популярные приемы и рекомендации по запуску saga рассмотрим в этом видео. Смотреть на Rutube

13. Как получить данные из стора в Redux Saga?

В этом видео рассматриваем как прочитать данные из стора в саге и напишем селектор, который можно переиспользовать. Смотреть на Rutube

14. Как комбинировать саги с помощью race и all в Redux Saga?

race и all в Redux Saga нужны для того чтобы запускать саги на параллельное исполнение. Их еще также называют комбинаторными эффектов (effect combinators). Смотреть на Rutube

15. Тестирование Redux Saga

В этом видео рассматриваем способы и принципы тестирования в Redux Saga - Как тестировать redux-saga. Можно тестировать саги пошагово т.е. каждый эффект как он указан в коде саге. Также можно протестировать всю сагу целиком записывая задиспатченные actions и используя моки (mocks). В последующих видео курса рассмотрим и другие способы юнит тестирования Redux Saga. Есть также различные библиотеки для тестирования redux saga, например, redux-saga-test, redux-saga-testing, redux-saga-test-plan и т.д. Смотреть на Rutube

16. Как тестировать ветвления в Redux Saga?

В этом видео рассматриваем способы и принципы тестирования в Redux Saga. В некоторых сагах есть ветвления, например, блоки кода в if/else или try/catch. В зависимости от значений условия, могут выполняться различные блоки кода. Для того чтобы протестировать ветвления без повторения всех шагов в саге в различных тестах можно воспользоваться функцией cloneableGenerator из пакета @redux-saga/testing-utils. Смотреть на Rutube

17. Как тестировать Redux Saga? Full Saga testing

В этом видео рассматриваем еще один способ тестирования в Redux Saga - Full Saga Testing. Смотреть на Rutube

18. Как тестировать Redux Saga? Тестирование fork

В этом видео рассматриваем тестирование эффектов fork в Redux Saga. Особенность fork в том, что он возвращает объект задачи. И этот объект иногда передается в другие эффекты например в cancel. И в тестах мы должны создать мок этого объекта и передать его дальше в следующий эффект. Смотреть на Rutube