Redux: Handling State Between Multiple Routes

- 1 answer

I have to say this is a great way to manage your state for your application. But I have a few questions that I cannot seem to find an answer to anywhere on the internet.

Handling your state across multiple routes, meaning:

I have my state, looks something like this:

    user: {},
    routing: {}

And I have a few different pages, meaning that it adds (for example) todos which only matters in the /todo route. How is something like this handled? Or do I not even include this in redux. I was thinking I could add an object for every route, but that would get messy, quickly. Unless this is the suggested route to take?

I am looking for the correct "redux" answer to this. Would I just not include those values in Redux, or would I create only for every route and just nest the values as I went? Anything is helpful at this point, because I'm running out of an ideas for this.

Thank you everyone!


Just to reply to what has been going on in the comments. This is what my state looks like:

  "routing": {
    "changeId": 1,
    "path": "/",
    "state": null,
    "replace": false
  "todos": {
    "visibilityFilter": "SHOW_ALL",
    "todos": [
        "text": "Use Redux - This is the initial state.",
        "completed": false,
        "id": 0
  "requests": {
    "isFetching": false,
    "data": {}

Pulled almost straight from redux, the routing object is from react-router so this is leading me to believe I don't really need this. But I'm just trying to figure out how keep things clean and how to structure my actions / reducers for a giant application.



The beauty of redux is the composability of the reducers. This means you can store all kinds of information in there, while handling it all quite separately. Here's some oversimplified and generic advice.

  1. Store all app state in Redux. That means a todos property might be there while not on a route that needs it (but it might not be populated).

  2. Decouple routes from data. A route is a method for bundling up a bunch of view elements together. Those view elements may in turn have data requirements, but they are independent of whatever route (or routes!) in which they appear. Your store should have a shape that represents your business domain.

If your application has various entities like todo items, calendar entries, and chat messages, your "model" may look like this:

    name: String
    completed: boolean
    participants: [ ... ]
    messages: [ ... ]
    date: Date
    todos: [ 'todo1', 'todo2' ]

We may have a "todos" route where we focus on todos, but that is simply a representation of some of our domain data. A TodoList component will need data and hook up to the store to get what it needs. A route on which it appears may trigger an action to request the data - or it may come from someplace else entirely. Browsing to a different route starts the process again, but only for whatever data is needed then.

  1. Cache data in the store. If a user clicks from route A to route B and then back again, a server call to re-fetch all of the data probably isn't necessary. Cache invalidation is beyond the scope of this post.