У чому різниця між redux-thunk та redux-promis?

Наскільки я знаю і виправляю мене, якщо я помиляюся, redux-thunk - це проміжне програмне забезпечення, яке допомагає нам відправляти функції асинхронізації та налагоджувати значення в самій дії, тоді як, коли я використовував redux-обіцянку, я не міг створити асинхронні функції, не реалізуючи власні механізм, оскільки Action видає виняток з диспетчеризації лише простих об'єктів.

Які основні відмінності між цими двома пакетами? Чи є якісь переваги використання обох пакунків в одній програмі для реагування на одній сторінці, або дотримання redux-thunk було б достатньо?

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-promis для рутинних асинхронних завдань, що виробляють обіцянки, а потім масштабуйте, щоб додати Thunks (або Sagas тощо) зі збільшенням складності :

• Коли життя просте, а ви просто виконуєте базову асинхронну роботу з творцями, які повертають єдину обіцянку, redux-promiseце покращить ваше життя та спростить це, швидко і легко. (У двох словах, замість того, щоб вам потрібно було думати про "розгортання" своїх обіцянок, коли вони вирішуються, а потім про написання / відправлення результатів, redux-promis (-diddleware) подбає про всі ці нудні речі для вас.)
• Але життя ускладнюється, коли:
  • Можливо, ваш творець дій хоче дати кілька обіцянок, які ви хочете надіслати як окремі дії, щоб розділити редуктори?
  • Або у вас є якась складна попередня обробка та умовна логіка для управління, перш ніж вирішити, як і куди надсилати результати?

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

Але зауважте, що якщо ваш Thunk виробляє та відправляє обіцянки, то ви захочете використовувати обидві бібліотеки разом :

• Thunk складав оригінальні дії та надсилав їх
• redux-promiseПотім буде обробляти розгортання на редукторі (-ах) індивідуальних обіцянок, згенерованих вашим Thunk, щоб уникнути шаблону, що тягне за собою. (Ви можете замість цього робити все в Thunks, за допомогою promise.then(unwrapAndDispatchResult).catch(unwrapAndDispatchError)... але чому б ви?)

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

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

  ---

ПРИМІТКИ / ПОСИЛАННЯ:

• Я вважаю, redux-promise-middlewareщо більш повне і зрозуміле втілення ідеї в основу оригіналу redux-promise. Він знаходиться в стадії активної розробки, а також добре доповнюється redux-promise-reducer.
• Є додаткові подібні проміжні засоби, доступні для складання / послідовності ваших складних дій: одна дуже популярна redux-saga, яка дуже схожа на redux-thunk, але базується на синтаксисі генераторських функцій. Знову ж таки, ви, швидше за все, використовували б його разом із redux-promise.
• Ось чудова стаття, в якій безпосередньо порівнюються різні варіанти асинхронної композиції, включаючи thunk та redux-promis-middleware. (TL; DR: "Redux Promise Middleware значно різко зменшує шаблон порівняно з деякими іншими параметрами" ... "Я думаю, що мені подобається Saga для більш складних програм (читайте:" використовує "), а Redux Promise Middleware для всього іншого." )
• Зауважте, що є важливий випадок, коли вам може здатися, що вам потрібно відправити кілька дій, але ви насправді цього не робите, і ви можете зробити прості речі простими. Ось тут ви просто хочете, щоб декілька редукторів реагували на ваш асинхронний виклик. Але немає жодної причини, чому кілька редукторів не можуть контролювати один тип дії. Ви просто хотіли б переконатися, що ваша команда знає, що ви використовуєте цю умову, тому вони не припускають, що лише один редуктор (із пов’язаною назвою) може обробити дану дію.

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

ReduxPromise повертає обіцянку як корисне навантаження під час відправлення дії, а потім проміжне програмне забезпечення ReduxPromise працює, щоб вирішити цю обіцянку і передати результат редуктору.

ReduxThunk, з іншого боку, змушує творця дії утримуватися від фактичного відправлення об'єкта дії до редукторів, поки не буде викликано відправлення.

Ось посилання на підручник, де я знайшов цю інформацію: https://blog.tighten.co/react-101-part-4-firebase .