About Redux Async without middleware (redux-thunk, redux-saga… )

Question

Some action have async function like fetch. But, i don't want to use middle ware like redux-thunk or redux-saga. So, i hesitate to use this code.

/* 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}))
})

...

Is this code violated for Redux paradigm ?

Answer 1

Redux FAQ "How can I represent “side effects” such as AJAX calls?..

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 functions you posted are action creators, so it does seem to be a proper place to put them, however in the next paragraph they say:

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.

Is there any reason why you're opposed to using redux-thunk, redux-saga, redux-loop, etc? They all exist to help you out really. You can choose to do do side effects manually, but it's less managed that using a middleware to do it IMO.

Answer 2

It is totally fine to inject dispatch into your action creator and use it for whatever you need it.

Outsourcing more logic from your components into your actions (or your middleware) is actually a good thing if you plan to reuse this logic in different places. It is completely legit that the logic inside your actions may also include async operations (as in your case) that postpone a dispatch or operations that dispatch several other actions. In case of redux-thunk this is called composition .

Your solution is somehow a "shortcut" compared to the "redux-thunk-way", where your thunk would first travel through the middleware and then control will be immediately inverted by redux-thunk. With redux-thunk, you would also have the benefit of getting getState injected, besides dispatch , which gives you direct access to the entire store (without redux-thunk, you would have to resort to mergeProps in your component to have both access to the store and dispatch at the same time).

Also the binding of dispatch to your actions is more standardized with redux-thunk, which uses currying, so it will be less boilerplate code inside your mapDispatchToProps and look cleaner (since you do not have to inject dispatch yourself everytime).