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

насколько я понимаю, и поправьте меня, если я ошибаюсь, redux-thunk - это промежуточное ПО, которое помогает нам отправлять асинхронные функции и отлаживать значения в самом действии, когда я использовал redux-обещание Я не мог создавать асинхронные функции без реализации моего собственного механизма, поскольку действие вызывает исключение отправки только простых объектов.

в чем основные различия между этими двумя пакетами? Есть ли преимущества использования обоих пакетов одна страница реагировать приложение или придерживаться redux-thunk будет достаточно?

3 ответов


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-promise для рутинных асинхронных задач, а затем масштабируйте, чтобы добавить Thunks(или Sagas и т. д.) по мере увеличения сложности:

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

в тех случаях, пользу redux-thunk это то, что он позволяет инкапсулировать сложность внутри вашего action-creator.

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

  • Thunk будет составлять исходное действие(Ы) и отправлять их
  • redux-promise после этого отрегулировал бы разворачивать на редуктор(ы) индивидуальное обещание(ы), генерируемое вашим Thunk, чтобы избежать шаблона, который влечет за собой. (Ты!--32-- > мог бы вместо этого делайте все в Thunks, с promise.then(unwrapAndDispatchResult).catch(unwrapAndDispatchError)... но зачем тебе это?)

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

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

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

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

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

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

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

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