Redux FAQ: Действия

Содержание

Действия

Почему тип действия должен быть строкой или по крайней мере сериализуемым? Почему мои типы действий должны быть константами?

Как и состояние, серилизуемые действия позволяют использовать несколько определяющих Redux особенностей, таких как отладка с помощью путешествия во времени (time travel) и запись и воспроизведение действий. Использование чего-то вроде Symbol как типа значений или instanceof для проверки типа действий сломает это. Строки — сериализуемы и хорошо себя документируют, поэтому они являются наилучшим типом для действий. Важно помнить, что можно использовать типы Symbols, Promises, или другие несериализуемые значения в действиях, если действия предназначены для миддлвэров. Действия должны быть сериализуемыми только в тех случаях, когда они фактически взаимодействуют с хранилищем и передаются редюсерам.

Мы не можем полостью обеспечить сериализуемые действия по причинам производительности, поэтому Redux только проверяет, что каждое действие — это простой объект и его тип определен. Остальное зависит от Вас. Но Вы можете заметить, что использование сериализуемых типов помогает в отладке и воспроизведении проблем.

Инкапсуляция и централизация частоиспользуемых кусков кода является ключевым понятием в программировании. Конечно, пока возможно вручную создавать объекты действия где угодно и вручную писать каждый тип значения, но определение многоразовых констант делает поддержку кода легче. Если Вы вынесите константы в отдельный файл, то сможете проверять Ваш import на опечатки, таким образом вы не сможете случайно использовать неправильные строки.

Дополнительная информация

Документация

Обсуждения

Всегда ли редюсеры и действия преобразуются "один к одному"?

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

Дополнительная информация

Документация

Обсуждения

Как я могу выполнять "побочные эффекты", такие как AJAX вызовы? Зачем нам нужны вещи типа “генераторов действий”, “thunks” или “мидлвар” для осуществления асинхронного поведения?

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

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

Redux вдохновлен функциональным программированием и из коробки выполнение побочных эффектов в нем не имеет места. В частности, функции редюсера всегда должны быть чистыми функциями типа (state, action) => newState. Однако, миддлвэры Redux-а позволяют перехватывать действия и добавлять к ним сложное поведение, включая побочные эффекты.

В целом, Redux предполагает, что код с побочными эффектами должен быть частью процесса создания действий. Пока эта идея может быть реализуема внутри UI компонента. В большинстве случаев имеет смысл вынести эту логику в переиспользуемую функцию, тогда она может быть вызвана из нескольких мест — иначе говоря, получаем функцию-генератор действия (action creator).

Самый простой и часто используемый путь сделать это — добавить Redux Thunk миддлвэр, который позволяет Вам писать генераторы действий с более сложной и асинхронной логикой.

Другой широко применяющийся подход — Redux Saga, который позволяет Вам писать выглядящий более синхронизированным код, используя генераторы, и может действовать как “фоновые потоки” или “демоны” в Redux-приложении.

Еще один подход — Redux Loop, который инвертирует процесс, позволяя вашим редюсерам объявлять побочные эффекты в ответ на изменение состояния и выполнять их отдельно.

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

Дополнительная информация

Документация

Статьи

Обсуждения

Должен ли я отправлять несколько действий подряд от одного генератора действия?

Нет точного правила, как Вы должны структурировать свои действия. Использование такого асинхронного миддлвэра, как Redux Thunk, конечно, позволяет выполнять такие операции, как

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

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

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

Дополнительная информация

Документация

Обсуждения

results matching ""

    No results matching ""