To Redux or not to Redux
This is a question that has come up during the last 12-18 months across multiple teams by both newbies and experienced front end developers.
If you are new to the React scene, you may have seen countless blog posts about the React/Redux duo.
If you are an old timer, you know the whole story (Flux->Dan->Redux->hooks??) and you have worked on many projects with either Redux or MobX or the more recent Unstated or may be even Apollo.
The core idea behind State Management libraries is to produce a centrilized, consistent application's state.
If you come from Java for example, you would most probably think we are basically using a glorified global session object. Right away, this consititues a smell and a No No on the Java playbook. Before going down this route, breath calm and lets keep going on. During the last ten years the front-end ecosystem has evolved rapidly, abruptly and many patterns are still arising.
UI = f(state) vs UI = f(time)
- Decision oriented apps: e.g. Dashboards
- Task oriented apps:
- End User facing apps:
- am I missing one? Generally speaking most of data is useless on the next page. Apps have business flows where you need to carry data from page A to B to C, from shopping to Cart.
In simple scenarios, the URL can be a very useful tool to pass state between screens.
Apps may have a couple of concepts that need to be on the Global state. Examples of these are:
- User's info such as online, subscribed, tier, full name, etc - whetever is relevant for your app.
- User's preferences
- Env based App's configuration
- Auth status, permissions
For this Global state, Context is a good fit.
If you want to preserve some of this information across sessions, I would use a ContextProvider/Consumer that gets the initial data from localStorage.
All opinions and views in this blog are my own and have no connection to my current workplace.