13

As a Redux beginner, given (the idea of) a somewhat larger application I imagine a root reducer similar to:

const rootReducer = combineReducers({ accounting, crm, sales })

Application state in this case would contain accounting, crm, and sales even if the user is only using one part of the application. This may be advantageous, for example as a cache when switching back and forth between accounting and CRM, but you probably do not want to retain all data of all views that have ever been opened, that is the complete possible state tree without any pruning, within the application forever or even initializing the whole tree to its initial state on load.

Are there idioms, patterns or libraries which solve this or am I missing something?

As a partial solution which solves retaining all the data I imagine something like resetting parts of the state to their initial state when navigating away from certain parts of the application given some declarative rules such as:

  • set accounting = {} (indirectly, through an action such as ACCOUNTING_LEAVING) when <Accounting/> receives componentWillUnmount
  • delete/set crm.mail = {} when <MailEditor/> receives componentWillUnmount

I have not seen examples which clean up the state in any way. Many "list + detail view" examples store state like { list: [...], detail: {...} }, but when switching to the detail view the list is neither emptied, nor nulled, nor deleted. This is nice when I might return to the list view a couple of moments later, but not when using an application 9 to 5 without ever releasing data.

Thomas Luzat
  • 638
  • 7
  • 18

1 Answers1

8

A few related thoughts:

  • Unless you're expecting dozens or hundreds of megabytes of data to be cached in your store, you're probably worrying about this too soon. Write your app, benchmark, and then optimize.
  • Dispatching actions to clear out portions of the store is entirely valid and reasonable.
  • My Redux addons ecosystem catalog may have some libraries listed that would be useful. In particular, the Component State and Reducer pages point to some libraries that do things like dynamically adding and removing reducers from your store, and resetting state.
  • You may also be interested in my collection of high-quality React and Redux tutorials.

Overall, how you organize your state, when you update it, and what you update it with is up to you. Redux simply provides a pattern and rules for the process of doing the updates.

markerikson
  • 42,022
  • 7
  • 87
  • 109
  • (Another) Helpful list, almost immediately lead me to react-ui, which seems to handle removing state in a similar fashion (on componentWillUnmount); I will investigate some of the libraries to find (or add ...) one suitable for my use cases. The component-based approach for managing reducers and state seems to get solved in many different ways there (at least as many as opinions exist on what should be state). – Thomas Luzat Apr 25 '16 at 16:16
  • 3
    Wait, you're telling me that different developers have different ideas on how to do things? I'm shocked, _shocked_! :) – markerikson Apr 25 '16 at 17:05
  • I'm just in the process of investigating Redux and am very confused by this. It seems logical to me that in a large, multi-view application, you generally _don't_ want state to persist in the browser _after_ the user has left a "page". Storing state in components means you don't have to worry about this - state is destroyed with the component - but putting it in a Redux store seems to require a significant overhead in terms of explicitly managing its life cycle. This makes me lean very heavily _away_ from Redux and _towards_ a component-based approach to state management. What am I missing? – Dan King Dec 13 '17 at 15:26
  • Yes, if you store data inside of components, and you stop rendering those components, the data does go away "automatically" as a result. However, that data is also not easily shareable across multiple parts of your app. If you put the data in Redux, it's easily accessible anywhere in the app, but it's also up to you to determine when that data should be cleared out. I wouldn't say it requires "significant overhead", exactly - it could easily just be dispatching a "CLEAN_UP" action from `componentWillUnmount`, and handling that appropriately in the reducers. – markerikson Dec 13 '17 at 16:42
  • It's also worth noting that this situation is not unique to Redux, but applies to _any_ situation where you're storing data outside the component tree. That includes a Redux store, MobX stores, Backbone collections, Angular services, or some global variable. – markerikson Dec 13 '17 at 16:43
  • 1
    @markerikson Are there any news since last year on this, are there any libraries that will handle for us ? – whatamidoingwithmylife Oct 23 '18 at 13:24
  • Nothing specific that I remember seeing. That said, I've also had to stop actively looking for new libraries to catalog in the addons list, as I've got too much stuff going on to keep up with that. So, it's possible that something exists that I haven't seen. – markerikson Oct 23 '18 at 18:05