React State Management - Part I
We as developers rarely get a chance to build an Enterprise B2B Application from scratch the way we want them to. however, I(LinkedIn) am one of the lucky few who got to build the same on react-redux stack three times in the last three years.
It's one of the most flexible library to work with because you can pretty much choose however you want to build your app. With flexibility, we should also be careful of how we build it because the assumptions and decisions you make now will affect the longterm maintainability of your codebase.
One such decision you need to take in the initial steps is how would you build the global state management in your App. one tried and tested way of managing your state is using Redux with Saga.
Quick disclaimer: this is not a how-to setup react-redux type of tutorial. Official docs and other tutorials on youtube or medium posts might help you with that.
This post is targeted towards developers who already know how to work with react-redux and trying to understand how to scale it.
To have better scalability of your Redux store you should follow three simple steps:
- Keep it clean
- Reuse
- Stick to your plan
Keep it clean
Your store should always have a minimal amount of information as possible. when you are working with a lot of moving parts having a clean store not only makes it easy to debug issues but also to improve productivity.
Here are some ways to keep your store clean.
State vs Store
For most of the components, the data present inside is not much use for the rest of the application.
For example, The details page inside one of the links has a lot of data about that particular feature. But this needn't be saved on the global store as the rest of the app doesn’t have any relation with this data. The data received from the API can simply be stored in the local state instead of pushing the data to the store
When the customer updates his display name in profile screen that data needs to go inside the global store because that value has a logical relationship with rest of the application, that can be the welcome message on the dashboard or it can be the name displayed next to a comment added by the user on any post
Also, transform your response data from API into Readable objects so that it's easy for anyone going through your store object to understand use it quickly.
One way of making a readable store is to make objects based on a feature set. So when the time comes for finding where the value is fetched from, instead of jumping across multiple sagas, selectors to get to the source of the data you can directly check the store for that specific feature object.
This helps in reducing debugging time as you are going directly towards the source of truth instead of going through multiple hoops to get the job done.
Reuse
When you think of reusability in your store, selectors are your friend.
Make sure you create meaningful micro selectors for your store which is used across the app so that you don't rewrite the same extraction logic.
For example, if you want to get the userId or userName from the store instead of extracting the data from the store object every time you can create a selector for it and reuse it across the app.
Structure your store in such a way that each block of data has a clear separation of concerns. always question yourself does this data belong to this block. The more thought you put in when you create your structure the better because once your store is made it's hard to change it without introducing bugs into your code.
Reusability not only depends on how you structure your store but also how you create your API contract. Try fetching the data at once for a logical block that you know will be used in another section of the App. otherwise, you will be making redundant calls to fetch parts of data.
Stick to your plan
In the name of flexibility, when a new feature is being developed sometimes we often create the module the way we want to create it. it's ok as long as it follows the principles agreed by the team. but when it deviates too much from the initial plan it creates a problem not only in making your app inconsistent but also will affect the productivity as it will take time to understand the intent of the previous developer who built it.
Let's go with the previous example you are building a profile page, which has some new fields that are introduced recently, you might be tempted to create another saga and create new store block for a specific response but this will leave two sets of similar data related to the user is now in two places.
you should never be in a situation with two sets of similar data as now you need to sync between both and there is no deterministic approach to understand which one has the latest data.
This would be part one of the series of making an enterprise-grade state management with React, stay tuned.
We are building products that is being used by all the top tech companies around the world. If you want to learn more about our team & culture https://medium.com/sequoia-com/building-a-culture-is-bigger-than-building-a-product-41a6057d6fe6
