О Redux Async без промежуточного программного обеспечения (redux-thunk, redux-saga ...)
Некоторые действия имеют асинхронную функцию, например выборку. Но я не хочу использовать промежуточное ПО, такое как redux-thunk или redux-saga. Итак, я не решаюсь использовать этот код.
/* actions */
...
export const fetchRequest = ({category, query, dispatch}) => ({
type: actionTypes.FETCH_REQUEST,
promise:
fetch(`${API_URL}${category}?${query}`, {headers: headers})
.then(response => response.json())
.then(data => dispatch(fetchRecieve(data))),
})
export const fetchRecieve = data => ({
type: actionTypes.FETCH_RECIEVE,
data,
})
...
/* In x.jsx */
...
const mapDispatchToProps = dispatch => ({
onClick: (category, query) => dispatch(fetchRequest({category, query, dispatch}))
})
...
Нарушается ли этот код для парадигмы Redux?
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
Ответы 2
Redux FAQ «Как я могу представить« побочные эффекты », такие как вызовы AJAX? ..
In general, Redux suggests that code with side effects should be part of the action creation process. While that logic can be performed inside of a UI component, it generally makes sense to extract that logic into a reusable function so that the same logic can be called from multiple places—in other words, an action creator function.
Функции, которые вы разместили, являются создателями действий, поэтому кажется подходящим местом для их размещения, однако в следующем абзаце они говорят:
The simplest and most common way to do this is to add the Redux Thunk middleware that lets you write action creators with more complex and asynchronous logic. Another widely-used method is Redux Saga which lets you write more synchronous-looking code using generators, and can act like “background threads” or “daemons” in a Redux app. Yet another approach is Redux Loop, which inverts the process by allowing your reducers to declare side effects in response to state changes and have them executed separately. Beyond that, there are many other community-developed libraries and ideas, each with their own take on how side effects should be managed.
Есть ли причина, по которой вы против использования redux-thunk, redux-saga, redux-loop и т. д.? Все они существуют, чтобы действительно помочь вам. Вы можете сделать побочные эффекты вручную, но это менее управляемо, чем использование промежуточного программного обеспечения для этого IMO.
Во-первых, спасибо за хороший ответ! На самом деле, я не против их использования, просто есть любопытство использовать без промежуточного программного обеспечения. Теперь ... я готов к изучению Thunk или Saga. Еще раз спасибо !!
Вполне нормально внедрить dispatch в создатель действий и использовать его там, где вам это нужно.
Передача большего количества логики из ваших компонентов в ваши действия (или ваше промежуточное программное обеспечение) на самом деле является хорошим делом, если вы планируете повторно использовать эту логику в разных местах. Это полностью законный, что логика внутри ваших действий может также включать асинхронные операции (как в вашем случае), которые откладывают отправку, или операции, которые отправляют несколько других действий. В случае redux-thunk это называется сочинение.
Ваше решение - это своего рода «ярлык» по сравнению с «redux-thunk-way», где ваш преобразователь сначала будет проходить через промежуточное ПО, а затем управление будет немедленно инвертировано с помощью redux-thunk. С redux-thunk у вас также будет преимущество внедрения getState, помимо dispatch, который дает вам прямой доступ ко всему хранилищу (без redux-thunk вам придется прибегнуть к mergeProps в вашем компоненте, чтобы иметь доступ к хранить и отправлять одновременно).
Кроме того, привязка dispatch к вашим действиям более стандартизирована с помощью redux-thunk, который использует каррирование, поэтому внутри вашего mapDispatchToProps будет меньше шаблонного кода и он будет выглядеть чище (поскольку вам не нужно каждый раз вводить dispatch самостоятельно).
Спасибо за хороший ответ! Я думаю, мне нужно больше узнать о Redux. Очень ценю ваше объяснение.
mapDispatchToProps выполняет работу, которая должна выполняться один раз внутри промежуточного программного обеспечения. Я бы сказал, что вы нарушаете хорошие методы программирования, создавая сознательно WET-код.