Все виды управления состоянием в React

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

Состояние в адресной строке

Самый простой вид состояния — это состояние в URL. Хранилище ключей и значений как часть URL: /search?query=abc. Состояние в URL идеально подходит для простых значений и хранения обновлений как части истории браузера. Примером может служить переключение между списком и элементом с помощью radio button.

export default function Page() {
  return (
    <div>
      <input
        name="view"
        type="radio"
        value="list"
      />
      <input
        name="view"
        type="radio"
        value="tiles"
      />
    </div>
  );
}

Сохранение фильтров и выбора в истории браузера позволяет пользователю отменить выбор, нажав кнопку «Назад» . onChange помещает ту же страницу с добавленными параметрами поиска в URL:

"use client";

import { usePathname, useRouter } from "next/navigation";

export default function Page() {
  const pathname = usePathname();
  const router = useRouter();

  // Нет нужды хранить значение в `useState`, а хранится в URL
  const onChange = (event: React.ChangeEvent<HTMLInputElement>) => {
    const urlSearchParams = new URLSearchParams();
    urlSearchParams.set("view", event.target.value);
    router.push(`${pathname}?${urlSearchParams.toString()}`, { scroll: false });
  };

  return (
    <div>
      <input
        name="view"
        type="radio"
        value="list"
        onChange={onChange}
      />
      <input
        name="view"
        type="radio"
        value="tiles"
        onChange={onChange}
      />
    </div>
  );
}

При выборе опции URL-адрес обновляется с использованием ключа view (поле name инпута) и значения list или tiles. NextJS предоставляет хук useSearchParams для чтения параметров поиска из URL. Мы извлекаем ключ view и устанавливаем defaultChecked параметр каждого инпута:

"use client";

import { usePathname, useRouter, useSearchParams } from "next/navigation";

export default function Page() {
  const pathname = usePathname();
  const searchParams = useSearchParams(); // здесь
  const view = searchParams.get("view") ?? undefined; // здесь

  const router = useRouter();

  const onChange = (event: React.ChangeEvent<HTMLInputElement>) => {
    const urlSearchParams = new URLSearchParams(searchParams);
    urlSearchParams.set("view", event.target.value);
    router.push(`${pathname}?${urlSearchParams.toString()}`, { scroll: false });
  };

  return (
    <div>
      <input
        name="view"
        type="radio"
        value="list"
        // Применим значение по умолчанию из `URLSearchParams`
        defaultChecked={view === "list"}
        onChange={onChange}
      />
      <input
        name="view"
        type="radio"
        value="tiles"
        // Применим значение по умолчанию из `URLSearchParams`
        defaultChecked={view === "tiles"}
        onChange={onChange}
      />
    </div>
  );
}

Значение будет выбрано по умолчанию даже при перезагрузке страницы. Другой вариант с NextJS читать параметры поиска - читать их внутри серверных компонентов. Каждая страница имеет доступ к props, содержащим searchParams как Promise:

interface Props {
  searchParams: Promise<{ [key: string]: string | string[] | undefined }>;
}

export default async function Page(props: Props) {
  const searchParams = await props.searchParams; // здесь
  const view = searchParams.view ?? undefined; // здесь
  /// ...
}

Такие хуки, такие как useRouter или usePathname не доступны в серверных компонентов. Способом сохранения пропсов searchParams, и хуков в одном компоненте является новая функция use:

"use client"; // Можно не создавать отдельный компонент для клиентского кода

import { usePathname, useRouter } from "next/navigation";
import { use } from "react";

interface Props {
  searchParams: Promise<{ [key: string]: string | string[] | undefined }>;
}

// Не нужно создавать async серверный компонент
export default function Page(props: Props) {
  // Доступ к асинхронным `searchParams` с помощью новой функции `use` (React 19)
  const searchParams = use(props.searchParams);
  const view = searchParams.view ?? undefined;

  const pathname = usePathname();
  const router = useRouter();

  const onChange = (event: React.ChangeEvent<HTMLInputElement>) => {
    const urlSearchParams = new URLSearchParams();
    urlSearchParams.set("view", event.target.value);
    router.push(`${pathname}?${urlSearchParams.toString()}`, { scroll: false });
  };

  return (
    <div>
      <input
        name="view"
        type="radio"
        value="list"
        defaultChecked={view === "list"}
        onChange={onChange}
      />
      <input
        name="view"
        type="radio"
        value="tiles"
        defaultChecked={view === "tiles"}
        onChange={onChange}
      />
    </div>
  );
}

Во всех примерах обратите внимание, что инпут - неуправляемый компонент. Поскольку состояние хранится в URL, то нет необходимости в useState. Вот как реализовать то же самое с useState (управляемый компонент):

"use client";

import { useState } from "react";

export default function Page() {
  const [view, setView] = useState<string | undefined>(undefined);

  const onChange = (event: React.ChangeEvent<HTMLInputElement>) => {
    setView(event.target.value);
  };

  return (
    <div>
      <input
        name="view"
        type="radio"
        value="list"
        // `checked` вместо `defaultChecked` для управляемого компонента
        checked={view === "list"}
        onChange={onChange}
      />
      <input
        name="view"
        type="radio"
        value="tiles"
        // `checked` вместо `defaultChecked` для управляемого компонента
        checked={view === "tiles"}
        onChange={onChange}
      />
    </div>
  );
}

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

Состояние на стороне сервера

Состояние сервера относится к данным, которые управляются сервером, а не являются локальными для клиента. Обычно вы читаете данные при загрузке страницы. Данные не обновляются на клиенте, а перезагружаются после обновления (POST, PUT или DELETE). Поскольку эти данные считываются только один раз при загрузке страницы, вам не нужно делать запрос на чтение на клиенте. Вместо этого вы обычно предварительно загружаете данные и HTML на сервере. Вот для чего нужны серверные компоненты:

interface Post {
  title: string;
  body: string;
}

export default async function Page() {
  // Сервер загружает данные прямо в серверный компонент (React 19)
  const post = await fetch("https://jsonplaceholder.typicode.com/posts/1").then(
    (response) => response.json() as Promise<Post>
  );

  return (
    <div>
      <h2>{post.title}</h2>
      <p>{post.body}</p>
    </div>
  );
}

Серверный компонент помечен как async и fetch выполняется непосредственно внутри функции компонента. Клиент получает окончательный макет без необходимости делать еще один запрос к серверу. После обновления сервера (POST/ PUT/DELETE) вам необходимо вручную перезагрузить страницу, чтобы отобразить новые данные. Если вместо этого вы предпочитаете повторно проверять данные на клиенте, используйте такие решения, как TanStack Query. useQuery делает асинхронный запрос, когда страница загружается (на клиенте) и сохраняет ответ в кэше. Периодически делается новый запрос для повторной проверки данных:

"use client"; // Клиентский компонент

import { useQuery } from "@tanstack/react-query";

interface Post {
  title: string;
  body: string;
}

export default function Page() {
  const result = useQuery({
    queryKey: ["post"],
    queryFn: () =>
      fetch("https://jsonplaceholder.typicode.com/posts/1").then(
        (response) => response.json() as Promise<Post>
      ),
  });

  if (result.isPending) {
    return <div>Loading...</div>;
  } else if (result.isError) {
    return <div>Error: {result.error.message}</div>;
  }

  return (
    <div>
      <h2>{result.data.title}</h2>
      <p>{result.data.body}</p>
    </div>
  );
}

Вам необходимо проверить оба isPending и isError, чтобы убедиться, что data определена. Поскольку запрос выполняется на клиенте, при первой загрузке пользователь увидит состояние загрузки (isPending). Этого не происходит с серверными компонентами, поскольку страница загружена и готова к отправке клиенту.

Состояние внутри формы

Форма хранит данные ввода с целью отправки form запроса. React 19 представляет useActionState хук специально для запросов форм. useActionState сохраняет состояние запроса (обычно данные ответа) и заботится о состоянии ожидания.

export default function Page() {
  const [state, action, isPending] = useActionState(api, null);
  return (
    <form action={action}>
      <input type="text" name="email" autoComplete="email" />
      <input type="password" name="password" autoComplete="current-password" />
      <button type="submit" disabled={isPending}>
        Submit
      </button>
    </form>
  );
}

api реализует async запрос (или синхронный) путем извлечения значений из FormData (на основе name инпутов).

"use client";

import { useActionState } from "react";

type State = null; // основано на типе ответа

const api = async (
  previousState: State,
  formData: FormData
): Promise<State> => {
  const email = formData.get("email");
  const password = formData.get("password");
  console.log(email, password);
  await new Promise((resolve) => setTimeout(resolve, 2000));
  return null;
};

export default function Page() {
  const [state, action, isPending] = useActionState(api, null);
  return (
    <form action={action}>
      <input type="text" name="email" autoComplete="email" />
      <input type="password" name="password" autoComplete="current-password" />
      <button type="submit" disabled={isPending}>
        Submit
      </button>
    </form>
  );
}

Все инпуты неконтролируемые, их значения извлекаются из FormData. Нет необходимости в нескольких useState. При такой реализации запрос отправляется внутри клиента. Поэтому console.log будет выведен в консоль браузера.

Серверные действия

Если вы хотите выполнить действие внутри сервера, вы можете использовать серверные действия. Реализация та же самая, но api функция находится в отдельном файле, помеченном как "use server":

"use server";

type State = null;

export const api = async (
  previousState: State,
  formData: FormData
): Promise<State> => {
  const email = formData.get("email");
  const password = formData.get("password");
  console.log(email, password);
  await new Promise((resolve) => setTimeout(resolve, 2000));
  return null;
};

Компонент ссылается на api так же, как и раньше внутри useActionState:

"use client";

import { useActionState } from "react";
import { api } from "./api";

export default function Page() {
  const [state, action, isPending] = useActionState(api, null);
  return (
    <form action={action}>
      <input type="text" name="email" autoComplete="email" />
      <input type="password" name="password" autoComplete="current-password" />
      <button type="submit" disabled={isPending}>
        Submit
      </button>
    </form>
  );
}

При такой реализации api будет выполнено на сервере. Поэтому console.log печатает в логах сервера (в браузере ничего не печатается). При отправке формы на сервер отправляется POST-запрос. Параметры функции и метаданные отправляются как часть RPC-запроса для выполнения API на сервере. При отправке формы на сервер отправляется POST-запрос. Параметры функции и метаданные отправляются как часть RPC-запроса для выполнения API на сервере.

Мутации с TanStack Query

Другой вариант — использование мутаций из TanStack Query с useMutation хуком. useMutation принимает функцию для выполнения, как и useActionState. Невозможно напрямую использовать action формы. Вместо этого можно выполнить мутацию onSubmit: Вам необходимо вручную вызвать preventDefault, чтобы избежать перезагрузки страницы.

export default function Page() {
  const mutation = useMutation({
    mutationFn: api,
  });

  return (
    <form
      onSubmit={(event) => {
        event.preventDefault(); // здесь
        mutation.mutate(new FormData(event.currentTarget));
      }}
    >
      <input type="text" name="email" autoComplete="email" />
      <input type="password" name="password" autoComplete="current-password" />
      <button type="submit" disabled={mutation.isPending}>
        Submit
      </button>
    </form>
  );
}

api то же самое, что и раньше. Он получает FormData и выполняет функцию на клиенте. Даже в этом случае состояние неконтролируемо и извлекается как FormData:

"use client";

import { useMutation } from "@tanstack/react-query";

const api = async (formData: FormData) => {
  const email = formData.get("email");
  const password = formData.get("password");
  console.log(email, password);
  await new Promise((resolve) => setTimeout(resolve, 2000));
};

export default function Page() {
  const mutation = useMutation({
    mutationFn: api,
  });

  return (
    <form
      onSubmit={(event) => {
        event.preventDefault();
        mutation.mutate(new FormData(event.currentTarget));
      }}
    >
      <input type="text" name="email" autoComplete="email" />
      <input type="password" name="password" autoComplete="current-password" />
      <button type="submit" disabled={mutation.isPending}>
        Submit
      </button>
    </form>
  );
}

Состояние на стороне клиента

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

• Состояние URL для пар «ключ-значение» синхронизировано с URL (история браузера)
• Состояние сервера для чтения данных при загрузке страницы
• Состояние формы для отправки form запросов

Состояние клиента необходимо только для управления сложными взаимодействиями: множественными переменными, включая производные значения с множественными состояниями и шагами. Для этих сложных вариантов использования вам нужен способ контролировать мутации и избегать ненужных повторных рендеров. Тогда следует обратиться к библиотекам вроде XState, Zustand, Redux. В большинстве случаев вам может даже не понадобиться внешняя библиотека. Хуки вроде useReducer, useContext, и useState могут быть достаточны для большинства локальных и простых случаев использования.

Функция перехода состояния

Библиотека управления состоянием в основном отвечает за:

• Хранение и предоставление доступа к состоянию
• Обновление состояния (избегая чрезмерного повторного рендеринга)

Распространенный шаблон, ставший популярным благодаря Redux, состоит в функции перехода состояния. Это функция, которая принимает событие и текущее состояние и возвращает следующее состояние. Самая простая реализация этого шаблона - это useReducer:

"use client";

import { useReducer } from "react";

interface State {
  firstName: string;
  lastName: string;
}

type Event =
  | { type: "firstName.update"; value: string }
  | { type: "lastName.update"; value: string };

const reducer = (state: State, event: Event): State => {
  switch (event.type) {
    case "firstName.update":
      return { ...state, firstName: event.value };
    case "lastName.update":
      return { ...state, lastName: event.value };
  }
};

export default function Page() {
  const [state, dispatch] = useReducer(reducer, {
    firstName: "",
    lastName: "",
  });
  const fullName = `${state.firstName} ${state.lastName}`; // Производное состояние
  return (
    <form>
      <input
        type="text"
        name="firstName"
        value={state.firstName}
        onChange={(event) =>
          dispatch({ type: "firstName.update", value: event.target.value })
        }
      />
      <input
        type="text"
        name="lastName"
        value={state.lastName}
        onChange={(event) =>
          dispatch({ type: "lastName.update", value: event.target.value })
        }
      />

      <p>{fullName}</p>
      <button type="submit">Submit</button>
    </form>
  );
}

Такие библиотеки, как @xstate/store и Redux, основаны на этом же шаблоне.

Стэйт машины (конечные автоматы)

Для еще более сложных случаев состояния (объекта) и событий недостаточно. Конечные автоматы моделируют различные состояния явно (например, «открыто»/«закрыто»). Обновление состояния использует ту же событийно-управляемую логику функции редьюсера. Главное отличие в том, что определенные действия разрешены только внутри определенных состояний. Конечные машины можно визуализировать в виде диаграммы. Этот дополнительный уровень абстракции предотвращает непреднамеренные действия, когда они не разрешены в состоянии. Он дает больше контроля над состояниями приложения за счет более высокой сложности . Конечный автомат моделирует всю сложность вашего приложения, поэтому его часто считают более сложным для реализации и требующим больше кода. Стандартным решением для конечных автоматов в React является XState:

"use client";

import { useMachine } from "@xstate/react";
import { createMachine } from "xstate";

const machine = createMachine({
  types: {} as {
    events: { type: "OPEN" } | { type: "CLOSE" };
  },
  initial: "closed",
  states: {
    closed: {
      on: { OPEN: "open" },
    },
    open: {
      on: { CLOSE: "closed" },
    },
  },
});

export default function Page() {
  const [snapshot, send] = useMachine(machine);

  if (snapshot.matches("open")) {
    return (
      <div>
        <p>Open</p>
        <button onClick={() => send({ type: "CLOSE" })}>Close</button>
      </div>
    );
  }

  return (
    <div>
      <p>Closed</p>
      <button onClick={() => send({ type: "OPEN" })}>Open</button>
    </div>
  );
}

Диаграммы состояний

Диаграммы состояний расширяют базовую модель конечных автоматов для создания комплексного решения по управлению состоянием. Диаграммы состояний добавляют дополнительные функции, включая иерархию, параллелизм и коммуникацию. XState реализует модель диаграмм состояний (statecharts ). Он также позволяет нескольким statecharts взаимодействовать друг с другом в модели актора. Актор инкапсулирует логику определенной функциональности в вашем приложении. Модель актора позволяет отправлять сообщения между акторами как модель параллельных вычислений.

Библиотеки управления состоянием в React

Ниже представлен обширный список библиотек управления состоянием для более сложных требований состояние на стороне клиента:

• @xstate/store
• zustand
• jotai
• redux
• Redux Toolkit
• MobX
• xstate
• Valtio
• MobX-State-Tree

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