I just recently got introduced to Redux and decided to learn how to implement it. At the moment I'm refactoring some of my previous studying-projects and implementing the global state logic provided by the tool.
The thing is, I've recently stumbled upon the thunk middleware for async actions and got curious about something that's probably a simple concept misunderstanding but that I just can't get over.
So, why would I dispatch an async action? I just can't see the benefits of doing that way instead of waiting for the execution of whatever I'm doing and just then dispatch the action carrying the data I want.
Using a simple fetch call as an example, why would I not do the following:
->await fetch data
->dispatch fetched data
And instead do this:
->dispatch action
->await dispatch action
There's probably some use cases that I don't know of because for me, a beginner, sounds like extra code for something that maybe didn't require it? Idk.
Could someone help me? =)
Yep, as you found, that's Dan Abramov's original explanation of why something like the thunk middleware exists.
I recently wrote a new Redux docs page on Writing Logic with Thunks, which goes into more detail on the purpose behind thunks and how to use them correctly. I'll quote from the "Why Use Thunks?" section:
Thunks allow us to write additional Redux-related logic separate from a UI layer. This logic can include side effects, such as async requests or generating random values, as well as logic that requires dispatching multiple actions or access to the Redux store state.
Redux reducers must not contain side effects, but real applications require logic that has side effects. Some of that may live inside components, but some may need to live outside the UI layer. Thunks (and other Redux middleware) give us a place to put those side effects.
It's common to have logic directly in components, such as making an async request in a click handler or a useEffect hook and then processing the results. However, it's often necessary to move as much of that logic as possible outside the UI layer. This may be done to improve testability of the logic, to keep the UI layer as thin and "presentational" as possible, or to improve code reuse and sharing.
In a sense, a thunk is a loophole where you can write any code that needs to interact with the Redux store, ahead of time, without needing to know which Redux store will be used. This keeps the logic from being bound to any specific Redux store instance and keeps it reusable.
The Redux FAQ entry on "why do we use middleware for side effects?" links to additional information on this topic.
Related
I would like to understand when it is appropriate to use a redux middleware over a redux-observable epic (and vice versa).
From the redux middleware documentation
It provides a third-party extension point between dispatching an action, and the moment it reaches the reducer. People use Redux middleware for logging, crash reporting, talking to an asynchronous API, routing, and more.
From the redux-observable documentation
While you'll most commonly produce actions out in response to some action you received in, that's not actually a requirement! Once you're inside your Epic, use any Observable patterns you desire as long as anything output from the final, returned stream, is an action.
My understanding is that an action in a redux middleware may or may not hit a reducer and if it does, it may or may not result in a change of state. In an epic you can produce a new action which may or may not hit a reducer or result in a change of state.
It looks like both can be used to enable side effects so the difference between the two is becoming a bit blurry to me.
Question: Is the FRP foundation the only thing that sets them apart or are there specific events in the lifecycle of an application that are better dealt with a classic middleware or an epic?
"Middleware" are a general type of thing that can be used to customize a Redux store. redux-observable is a specific Redux middleware, which lets you use RxJS logic to interact with dispatched actions.
I'm a beginner with redux-saga and as a task I thought I'd try to convert a large existing React app from Promises to redux-saga. I'm making some progress, but one issue I came on is that when I used Promises I was able to set component-local variables depending on whether the promise fulfilled or rejected. Now it seems I just "hand over" the request to redux-saga and never know (in the call site) whether it fulfilled or not, and now I don't know (within my component) whether it succeeded or not.
For example, let us say I have this promise-based call which fetches my user's games
getCurrentGamesForUser = (nickname, token) => {
return logic.getGamesForUser(nickname, token)
.then(currentGames => {
this.needToUpdateGamesFlagFromSocketIO = false
this.setState({currentGames})
sessionStorage.setItem('currentGames', JSON.stringify(currentGames))
})
.catch(({message}) => this.onError(message))
}
Here I'm setting the flag this.needToUpdateGamesFlagFromSocketIO -- as well as a sessionStorage variable -- if my promise succeeds.
Now, as I understand it, I would convert this to
getCurrentGamesForUser = (nickname, token) => {
this.props.dispatch(getCurrentGames(nickname,token))
}
and this works fine. If there's an error, that will be sent to the store from the saga and my component will reflect that.
But what do I do about the local flags and the session storage? Do I need to add these to the store as well? That seems a messy way to go, unless I had a separate store for each component, a local store for each component, which also seems messy. I saw some discussion of a similar topic here, https://github.com/redux-saga/redux-saga/issues/907, but there doesn't seem to be an answer. I'm sure I'm missing the "redux way" of handling all this, and so would welcome any guidance.
Redux-Saga is meant to offload all action based triggers outside component to a separate saga scope. So unfortunately there is no straightforward way to implement what you have requested. Although there are some suggested workarounds in the issue tracker you have mentioned.
The primary aim of redux-saga was ease of management of side affects by offloading it to a separate execution context. One of the tradeoff, is communication can only happen through component -> action -> saga -> store -> component. Hence for the above requirement, I believe using redux-saga would be counterproductive.
That said, you can always use redux-saga in combination with other promise / callback based methods such as redux-thunk.
Usecases such as above would be better suited for callback based implementations while complete isolation of side effects to redux would be handled well with redux-saga.
I sometimes have a GUI component that needs to know when an async action completes. Basically I dispatch an action and I want a promise that yields when the process is completed. From what I understand the component can't simply listen for actions from the store. Or can it?
I use redux-saga, but I think this is a general problem.
The way I do this now is to create a promise and pass the accept/reject functions to the actions - so that whatever handles it can resolve the promise for me. I then keep the promise and hope that the action are picked up and the methods called. (I don't store the methods in state, just in the sagas processing the action.)
This seems fragile, and I wonder: Is there any other way my component can receive an event when a process is completed? I know I could use the state for signaling, but that sometimes seem too much scaffolding for this little thing.
Edit
One case I ran across is submitting of forms. The (sagas) middleware will first run validation, which could also be async, then submit the form to the server. While this is going on, I don’t want the user to be able to click again or edit. This is what the promise helps ensure. As always, when writing up a problem to someone, i realize that a redux state flag would be better in this specific case - although somewhat elaborate. However, I have more cases like this so my question stands.
We use Redux in large parts of our React application. One area where we struggle with is the context menu. Up to now it worked like this:
onRightClick -> createItems -> openMenu -> onItemClick: invoke callback and close menu
So we had a callback in each item when it is clicked. With Redux, that no longer works, because:
dispatch(actionCreator_openContextMenu(items))
... performs a store update. The Redux action returned by the action creator cannot have callbacks in it, because they are not serializable/jsonizable.
We furthermore need to perform asynchronous operations (i.e. server roundtrips) in many context menu click actions, so the click actions are not plain store updates.
The question is: how does this align with the Redux pattern and its constraints? How would one do this with Redux?
To clarify: this question is not about the UI side in react, it's about redux.
I actually wrote an article that covers this exact question: Creating Reusable Generic Modals in React and Redux. The approach I described in that article can be summarized as having the code that requests the dialog include a pre-made action object that gets passed to the dialog component as a prop, and the dialog can then dispatch that action (possibly with additional info attached) when it's closed.
A couple other options:
Have the dialog dispatch some "signal" action when it closes, and use sagas or observables to execute the additional async logic in response
There's an interesting-looking library called redux-promising-modals. I haven't used it yet myself, but it appears to have a prebuilt middleware and reducer for tracking a lost of open modals. The middleware returns a promise whenever you dispatch PUSH_MODAL_WINDOW, and will resolve the promise when you dispatch the corresponding POP_MODAL_WINDOW.
I think what you are looking for is a redux middleware that could handle async side effects. There are dozens of libraries out there that can help with this, but I would suggest your team looks into some of the following libraries that have great communities and are well documented:
Redux-Saga https://github.com/redux-saga/redux-saga (easy to understand and test)
Redux-Thunk https://github.com/gaearon/redux-thunk (extremely easy to understand, hard to test)
Redux-Observable https://redux-observable.js.org/ (you would need some previous knowledge on reactive programming, easier to test than redux-thunk)
I'm familiarising myself with both Flux architecture, and Reflux - the simpler version, without a dispatcher - for use with ReactJS.
In full Flux, it sounds like actions have (or at least, can be made to have) a definite and non-trivial purpose: they can be used to update external services (eg. save data back to the server via an API), as described in this question: Should flux stores, or actions (or both) touch external services?
However, in Reflux, the actions are definitely just dumb message parsers. So my question is, what purpose do they serve? Why have them at all? What bad things would happen if your Views/Components just called methods on your store directly?
I'm about to convert my little app from Flux to Reflux, and it looks like I'll be moving all the logic currently in my actions over to the store. It seems to me like the actions in Reflux do nothing other than act as a useless middleman between the component and the store. What am I missing?
Besides the ability to listen for an action in any number of stores as pointed out in the OP comments:
Reflux actions can also touch APIs and such, by placing it in the preEmit action hook for example. Typically you'd create an async action, add some async stuff in the preEmit hook, and then call the "completed" or "failed" sub-actions when the async work is done (or has failed). You can also do sync work in the preEmit hook of course. Logging comes to mind.
It's also fully possible to listen to an action in a store and perform the async work in the store, then call .completed or .failed from there, but I think the consensus that has formed is that stores shouldn't do that work, stores should just react to changing data, not perform business logic.
Async actions also work as promises. Of course you could implement your stores to do that as well, but I'd argue that that's a lot of responsibilities for a data store.