Для чего нужны Redux Saga и Redux Thunk

Что проверяют

Понимаете ли вы, зачем нужен промежуточный слой, и знаете ли разницу между подходами.

Как отвечать

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

Thunk позволяет отправлять функцию вместо объекта. Функция получает отправку и текущее состояние и может делать что угодно.

const load = (id) => async (dispatch, getState) => {
  dispatch(started());
  try { dispatch(success(await api.get(id))); }
  catch (e) { dispatch(failed(e.message)); }
};

Просто, читается сверху вниз, покрывает подавляющее большинство задач. Входит в Redux Toolkit по умолчанию.

Saga строится на генераторах и описывает эффекты декларативно: не «сделай запрос», а «вот описание запроса, выполни его». Отсюда её сильные стороны:

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

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

Есть и третий подход на реактивных потоках, где вся асинхронность выражается операторами.

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

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

Где спотыкаются

Берут генераторные саги ради простой загрузки данных.

Пишут побочные эффекты прямо в редьюсере.

Не знают, зачем вообще нужен промежуточный слой.

Дублируют кэш серверных данных вручную вместо готового решения.