#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.