Экшены

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

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

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

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

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

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

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

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

Обсуждения

  • Twitter: most common Redux misconception
  • #1167: Reducer without switch
  • Reduxible #8: Reducers and action creators aren't a one-to-one mapping

  • Stack Overflow: Can I dispatch multiple actions without Redux Thunk middleware?

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

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

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

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

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

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

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

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

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

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

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

Статьи

Обсуждения

**Статьи**

- [Decembersoft: What is the right way to do asynchronous operations in Redux?](https://decembersoft.com/posts/what-is-the-right-way-to-do-asynchronous-operations-in-redux/)
- [Decembersoft: Redux-Thunk vs Redux-Saga](https://decembersoft.com/posts/redux-thunk-vs-redux-saga/)
- [Redux-Thunk vs Redux-Saga: an overview](https://medium.com/@shoshanarosenfield/redux-thunk-vs-redux-saga-93fe82878b2d)
- [Redux-Saga V.S. Redux-Observable](https://hackmd.io/s/H1xLHUQ8e#side-by-side-comparison)


**Обсуждения**

- [Reddit: discussion of using thunks and sagas together, and pros and cons of sagas](https://www.reddit.com/r/reactjs/comments/8vglo0/react_developer_map_by_adamgolab/e1nr597/)
- [Stack Overflow: Pros/cons of using redux-saga with ES6 generators vs redux-thunk with ES2017 async/await](https://stackoverflow.com/questions/34930735/pros-cons-of-using-redux-saga-with-es6-generators-vs-redux-thunk-with-es2017-asy)
- [Stack Overflow: Why use Redux-Observable over Redux-Saga?](https://stackoverflow.com/questions/40021344/why-use-redux-observable-over-redux-saga/40027778#40027778)

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

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

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

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

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

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

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

Статьи

Обсуждения

results matching ""

    No results matching ""