Redux FAQ: Store Setup
Table of Contents
- Is it OK to have more than one middleware chain in my store enhancer? What is the difference between next and dispatch in a middleware function?
- How do I subscribe to only a portion of the state? Can I get the dispatched action as part of the subscription?
- How do I persist store state and restore it on the next launch?
Store Setup
Is it OK to have more than one middleware chain in my store enhancer? What is the difference between next and dispatch in a middleware function?
Redux middleware act like a linked list. Each middleware function can either call next(action) to
pass an action along to the next middleware in line, call dispatch(action) to restart the
processing at the beginning of the list, or do nothing at all to stop the action from being
processed further.
This chain of middleware is defined by the arguments passed to the applyMiddleware function used
when creating a store. Defining multiple chains will not work correctly, as they would have
distinctly different dispatch references and the different chains would effectively be
disconnected.
Further information
Documentation
Discussions
- #1051: Shortcomings of the current applyMiddleware and composing createStore
- Understanding Redux Middleware
- Exploring Redux Middleware
How do I subscribe to only a portion of the state? Can I get the dispatched action as part of the subscription?
Redux provides a single store.subscribe method for notifying listeners that the store has updated.
Listener callbacks do not receive the current state as an argument—it is simply an indication that
something has changed. The subscriber logic can then call getState() to get the current state
value.
This API is intended as a low-level primitive with no dependencies or complications, and can be used to build higher-level subscription logic. UI bindings such as Presenter-middleware can create a subscription for each connected component. It is also possible to write functions that can intelligently compare the old state vs the new state, and execute additional logic if certain pieces have changed.
The new state is not passed to the listeners in order to simplify implementing store enhancers such as the Redux DevTools. In addition, subscribers are intended to react to the state value itself, not the action. Middleware can be used if the action is important and needs to be handled specifically.
Further information
Documentation
Discussions
- #303: subscribe API with state as an argument
- #580: Is it possible to get action and state in store.subscribe?
- #922: Proposal: add subscribe to middleware API
- #1057: subscribe listener can get action param?
- #1300: Redux is great but major feature is missing
Libraries
How do I persist store state and restore it on the next launch?
Two mechanisms, depending on who owns the storage:
- State the OS saves for you (rotation + process death on Android/iOS):
use
redux-kotlin-compose-saveable— describe the slice worth keeping with aStateSaverand anchor it withrememberSaveableState. The snapshot rides Compose'sSaveableStateRegistry, and on restore the library dispatches your restore action synchronously during composition, so the first frame already shows the rehydrated state. - State you persist yourself (a database, files, a server session): load
it before creating the store and seed it via
preloadedState—createStore(reducer, restoredState)for the core store, or thepreloadedStateparameter oncreateModelStore/createConcurrentModelStorefor routedModelStatestores, which overlays the restored models onto the declared defaults.
Don't restore by dispatching after the UI is up — the first frame renders the initial state and then visibly jumps.
Further information
Documentation
- Advanced: Saving state across rotation & process death
- API: createStore
- Troubleshooting: State persistence & restore
Example
- TaskFlow — durable
domain state in SQLDelight + volatile UI state via
rememberSaveableState.