The Redux store is like a company’s budget

Have you ever seen executives at an organization duck into a super-important meeting to discuss the budget, including overall costs and revenue? It’s something executives often grapple with, investing in the next big thing or pushing and pulling funding between pet projects.

But it’s a common document that all executives at a certain level have access to, and it serves to get them on the same page.

I posit that the Redux store is a lot like a organization’s budget, and React components are a lot like employees.

This analogy can help developers decide whether to keep data in the Redux store, local React components’ state, or neither.

Here’s how:

1. A company’s budget serves to keep its different divisions in-sync, similar to how the Redux store serves to keep the application in-sync. Think “single source of truth,” the first fundamental principle of Redux. For example, if the budget reflects 60% expenditures on Bob’s crazy idea, all executives see this (regardless of whether or not they agree with Bob’s idea), and the idea is to sync expectations. Similarly, if an app retrieves data (e.g. search results) from the back-end that can be used in multiple views (e.g. map view vs. list view, like in Airbnb), those views can operate off of the same data.
2. A company only stores high-level information in its budget, similar to how the Redux store should normally only store high-level data. A company’s budget might stipulate expenditures allowed by the sales department, and the VP of sales might then be responsible for the details of that slice of budget, which are not of interest or relevance to other departments. Similarly, the Redux store is best used for data that is relevant across the application (or which may need to be resurfaced throughout interaction with the app).
3. Only high-level executives get access to the budget, similar to how only React connected components get access to the Redux store. Many organizations give access to the budget on a need-to-know basis (usually only executives), since it contains a trove of high-level information. Similarly, you shouldn’t create containers everywhere and connect every component needlessly to the Redux store unless they have a reason for access, or are a high-level component handling an important, complex purpose.
4. Budgets have categories that need careful, often subjective consideration, similar to how the React store has slices. Should the budget be split by function (e.g. sales, marketing) or revenue type (e.g. subscriptions, advertising) or product line (e.g. trucks, cars)? Should the React store be split into resource type (e.g. apartment, user) or feature (e.g. search results, user dashboard)?
5. Budgets let employees handle details through sub-budgets, similar to how the Redux cycle allows components to have local state. The CTO will decide how much to pay each developer, as long as everything fits within the technology portion of the overall budget. Unless something goes wrong, it’s not a concern of other departments or executives. So the CTO likely manages a separate tech budget. Similarly, the Redux store doesn’t need to know or store information pertaining to only one component — that information can be handled by the (class) component itself. For example, a controlled form doesn’t need to inform the Redux store (“higher ups”) every time a user changes an input field.
6. Most employees don’t have access to any part of the budget and are just told what to do, just like many React components can remain functional components (pure functions). For a developer to accomplish her job, she doesn’t need access to the company’s budget, nor does she need to keep her own budget. Similarly, many components can be functional components, receiving props and rendering based on those props, without maintaining either local state or having access to the Redux store.

See another comparison, or flaws in my hypothesis above? Please comment below!