В чем разница между redux-thunk и redux-prom?

redux-thunk позволяет создателям ваших действий возвращать функцию:

function myAction(payload){
    return function(dispatch){
        // use dispatch as you please
    }
}

redux-promise позволяет им вернуть обещание:

function myAction(payload){
    return new Promise(function(resolve, reject){
        resolve(someData); // redux-promise will dispatch someData
    });
}

Обе библиотеки полезны, если вам нужно отправить действие асинхронно или условно. redux-thunk также позволяет отправлять несколько раз в одном создателе действия. Независимо от того, выберете ли вы один, другой или оба, полностью зависит от ваших потребностей / стиля.

Скорее всего, вы захотите / вам понадобится и то, и другое вместе в вашем приложении. Начните с redux-prom для рутинных асинхронных задач по созданию обещаний, а затем увеличивайте масштаб, добавляя Thunks (или Sagas и т. д.) по мере увеличения сложности:

• Когда жизнь проста, и вы просто выполняете базовую асинхронную работу с создателями, которые возвращают одно обещание, тогда redux-promise улучшит вашу жизнь и упростит ее, быстро и легко. (Вкратце, вместо того, чтобы думать о том, чтобы «развернуть» свои обещания, когда они разрешаются, а затем записывать / отправлять результаты, redux-prom (-middleware) позаботится обо всех этих скучных вещах за вас.)
• But, life gets more complex when:
  • Maybe your action creator wants to produce several promises, which you want to dispatch as separate actions to separate reducers?
  • Или вам нужно управлять сложной предварительной обработкой и условной логикой, прежде чем решать, как и куда отправлять результаты?

В таких случаях преимущество redux-thunk состоит в том, что он позволяет вам инкапсулировать сложность внутри вашего создателя действия.

Но обратите внимание, что если ваш Thunk создает и отправляет обещания, вы захотите использовать обе библиотеки вместе:

• Преобразователь будет составлять исходные действия и отправлять их
• redux-promise затем обработает разворачивание в редукторе (ах) отдельных обещаний, сгенерированных вашим преобразователем, чтобы избежать шаблонного, который влечет за собой. (Вместо этого вы могли бы делать все в Thunks, используя _4 _..., но зачем вам это?)

Еще один простой способ резюмировать разницу в вариантах использования: начало и конец цикла действий Redux:

• Преобразователи предназначены для начала вашего потока Redux: если вам нужно создать сложное действие или инкапсулировать некоторую корявую логику создания действий, не допуская ее к вашим компонентам и определенно вне редукторов.
• redux-promise предназначен для конца вашего потока, когда все сводится к простым обещаниям, и вы просто хотите их развернуть и сохранить их разрешенное / отклоненное значение в хранилище

  ---

ПРИМЕЧАНИЯ / ССЫЛКИ:

• Я считаю redux-promise-middleware более полным и понятным воплощением идеи, лежащей в основе оригинального redux-promise. Он находится в активной разработке, а также хорошо дополнен redux-promise-reducer.
• есть дополнительные похожие промежуточные программы, доступные для составления / упорядочивания ваших сложных действий: очень популярным является redux-saga, которое очень похоже на redux-thunk, но основано на синтаксисе функций генератора. Опять же, вы, вероятно, использовали бы его вместе с redux-promise.
• Вот отличная статья, в которой напрямую сравниваются различные варианты асинхронной композиции. , включая thunk и redux-prom-middleware. (TL; DR: "Промежуточное ПО Redux Promise значительно сокращает шаблонный код по сравнению с некоторыми другими вариантами" ... "Я думаю, что мне нравится Saga для более сложных приложений (читайте: "использует"), и промежуточное ПО Redux Promise для всего остального. ")
• Обратите внимание, что есть важный случай, когда вы можете подумать, что вам нужно отправить несколько действий, но на самом деле это не так, и вы можете упростить простые вещи. Вот где вам просто нужно, чтобы несколько редукторов реагировали на ваш асинхронный вызов. Но нет никакой причины, по которой несколько редукторов не могут отслеживать один тип действия. Вы просто хотите убедиться, что ваша команда знает, что вы используете это соглашение, а они не Предположим, что только один редуктор (со связанным именем) может обработать данное действие.

Полное раскрытие: я относительно новичок в разработке Redux и сам боролся с этим вопросом. Перефразирую самый емкий ответ, который я нашел:

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

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

Вот ссылка на руководство, в котором я нашел эту информацию: https://blog.tighten.co/react-101-part-4-firebase.