I am wondering how folks using Redux are approaching their backend persistence. Particularly, are you storing the "actions" in a database or are you only storing the last known state of the application?
If you are storing the actions, are you simply requesting them from the server, then replaying all of them when a given page loads? Couldn't this lead to some performance issues with a large scale app where there are lots of actions?
If you are storing just the "current state", how are you actually persisting this state at any given time as actions happen on a client?
Does anyone have some code examples of how they are connecting the redux reducers to backend storage apis?
I know this is a very "it depends on your app" type question, but I'm just pondering some ideas here and trying to get a feel for how this sort of "stateless" architecture could work in a full-stack sense.
Thanks everyone.
Definitely persist the state of your reducers!
If you persisted a sequence of actions instead, you wouldn't ever be able to modify your actions in your frontend without fiddling around inside your prod database.
Example: persist one reducer's state to a server
We'll start with three extra action types:
I use redux-thunk to do async server calls: it means that one action creator function can
dispatch
extra actions and inspect the current state.The
save
action creator dispatches one action immediately (so that you can show a spinner, or disable a 'save' button in your UI). It then dispatchesSAVE_SUCCESS
or aSAVE_ERROR
actions once the POST request has finished.(N.B.
$.ajax
would totally work in place of thewindow.fetch
stuff, I just prefer not to load the whole of jQuery for one function!)The reducer just keeps track of any outstanding server request.
You'll probably want to do something with the
someResponseValue
that came back from the server - maybe it's an id of a newly created entity etc etc.I hope this helps, it's worked nicely so far for me!