Redux: drop part of state as unmounting component?

Question

i'm currently writing an app with react, redux and react-router.

Many of the route (or subroute) of the app, fill the state of the redux store with eventually own reducers that are combined.

but often, the part of the state that is manage by the routed component is specific to this component, and "can be dropped" after the component is unmounted.

i fear that as the user browse different screen, he will fill the state with unused data and bloat the whole app. so i'm thinking about a way to drop part of the state that are unused.

let's take i.e. a CRUD app for multiple distinct entities (Questions, Posts, Images, ....). While i'm listing the Questions it might not be necessary to have Posts in the state, and vice-versa. Should i drop the Posts list while transitioning to the Question list ?

is this a bad practice? is there a good way to do this ? what to you think?

Answer 1

@Dan Abramov not only is this not necessary but it also can lead to difficult to track bugs. We have experienced that, since componentWillUnmount() is asynchronous, when dispatching an action to clear a certain reducer inside of componentWillUnmount() can cause bugs when you go from this view directly to another view that relies on this section of the reducer.

For example:

Say you have the following store state shape:

const state = {
    list: ["thing"]
}

Then imagine I use this state in a view called Things

Then imagine I realize that in 9 out of 10 of my other views I am not using the state.list, so I decide I want to prevent "bloat" or "memory leaks" and I put an action that clears this section of my state in the componentWillUnmount in Things

You would expect that the sequence of events would always be:

1. Unmount Things
2. dispatch action to clear state.list
3. Then mount the next view
4. Then in 1 out of the 10 views repopulate state.list IF you need it in this view

However, this is not the sequence. Sometimes it instead will be:

1. Unmount Things and go directly to another view that needs state.list
2. Immediately mount this next view. Our view DOES need state.list so we dispatch this action. OR since state.list already exists we do not dispatch the fetch action because we already have it.
3. Just a moment later the componentWillUnmount dispatches the CLEAR action successfully
4. You unintentionally CLEAR the state.list in this view even though you did not want to. And of course since we are @connected our screen goes blank!

That is, even though Redux is synchronous componentWillUnmount is not synchronous and therefore any action dispatched within it can not be guaranteed to happen in the order you intend. This is a problem in any edge case where you do actually go directly to another view that DOES want that section of state.

One way around this is to have a conditional inside of componentWillUnmount that says "Only dispatch the CLEAR action IF I am leaving this view (unmounting it) for the following reason... NOT WHEN I AM GOING TO THIS OTHER VIEW THAT DOES RELY ON THIS SECTION OF STATE. You can do this by, for example, having a property in localState that is called something like shouldIClearList:, and it is true by default unless I click the button called, goToMyOtherViewThatNeedsList. However, this adds unnecessary complexity in many cases where the link to the other view that needs list is in a completely different top level parent component like the Navbar, and therefore, whether or not the view you are trying to go to is this "problematic view" is not easily "known" by your child Things component.

I actually think the idea of "Bloat" is a valid one, and the best way to clear redux upon unmounting without running into an issue like this would be greatly appreciated. The only solution I can see off the bat is to NOT ever clear the reducer inside of componentWillUnmount. It is too dangerous. OR if you do absolutely have to, making sure there is absolutely no way in your app to go from this view directly to another view that needs this section of state (a very hard thing to do in a huge app without having to have some kind of documentation shared across all of the software teams at the company).

Answer 2

Unless you’re dealing with tens of thousands of records, it’s probably not worth the effort and will complicate your code. Are you sure this is a real problem for your app? Keeping the old state is actually handy, e.g. for instant “Back” button.

If you feel strongly about it you can indeed dispatch a cleanup action when unmounting certain components, or on a route change. However I think that in the vast majority of apps this would be unnecessary, and keeping a cache might be preferable as long as you remember to check for any new items after mounting.

Answer 3

If your data was loaded in the detail component (not master), I think it's OK to restore the state.

Because the state of detail component won't actually be 'cached', besides, data will be downloaded again even you are switching back to show the same resource. And if you're going to show a different resource, the residual state of last visited resource remains until data of current resource is downloaded, and that will be wired to the users.

One of the approach is to define an action/reducer to restore the state when the detail component is going to unmount.

Another way is to restore the state when route changes:

import { LOCATION_CHANGE } from 'react-router-redux'
import * as types from 'constants/ActionTypes'

const initialState = {}

export default function show(state = initialState, action) {

  switch (action.type) {

    case types.LOGOUT:
    case LOCATION_CHANGE:
      return initialState

    case types.SHOW_SUCCESS:
      return action.payload

    default:
      return state
  }
}