использование экземпляра отправки в хранилище redux вместо передачи в dispatch в качестве параметра

#javascript #redux #middleware #react-redux

#javascript #redux #промежуточное программное обеспечение #реагировать-redux

Вопрос:

В документах Дэн не приводит особых аргументов в пользу изменения способа передачи отправки в промежуточное программное обеспечение. Он просто говорит это:

Но есть и другой способ включить цепочку. Промежуточное программное обеспечение может принимать функцию отправки next() в качестве параметра вместо считывания ее из экземпляра хранилища.

В чем причина этого? Для меня это выглядит еще более странно теперь, когда код внутри applyMiddleware будет принимать 2 аргумента с сохранением и отправкой, а не просто хранить отдельно.

Ответ №1:

Странно выглядеть не проблема.

 const logger = store => next => action => {
  console.log('dispatching', action)
  let result = next(action)
  console.log('next state', store.getState())
  return result
}
  

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

Причина, по которой это делается, заключается в том, что исправление обезьяны не зарекомендовало себя как рекомендуемый метод программирования. Передача функции next в функцию является более гибкой и не требует ничего от вызываемой функции (функции разработчика), что снижает нагрузку на разработчика и снижает вероятность ошибок.

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

Комментарии:

1. «Формат» (более точно определяемый как метод) называется каррированием .

Ответ №2:

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

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

Оригинальный дизайн обсуждался в выпуске Redux № 55, и Дэн предложил переписать, а затем отклонил свое собственное предложение в выпуске № 1744.