Scalable Redux for large web applications
Redux solves many data handling problem which were hard to think before. But as your application grows, it is hard to manage store at scale. This talk is about our experience of how we solved these problems in our current organization.
We achieved these benefits with our proposed solution:
- Managing store for growing set of developers and teams.
- Abstracting your Redux store
- Keeping it DRY
- Propagating common changes/patterns
- Ease of shipping complexing features at scale
- Challenges in Redux with large scale apps
- How we solved it
- Maintaining large scale apps with growing teams
For any modern stack that revolves around React/Vue/Elm or likewise libraries, we usually go ahead and use Redux for state management. It works well, it’s just aesthetics may always be improved. What we try to cover here is how to build your store architecture around Redux so that for every part of the state you need to define, you don’t have to create a reducer from scratch. Instead how about just providing the config and something else do the magic for you ;)
At Mindtickle we use a common Redux store across multiple applications. It has done good at easing our lives, and that we think is worth sharing with the community.
- Manage your complex sync/async flows just by passing a simple config.
- Handling scoped states becomes a breeze, as it is just another config. Have same method of handling scoped state also enables us to standardise read and manipulation operations over the same.
- Standardization of flow management by creating common reducer pattern for teams
- For every new person joining the team, he/she needs to understand just the reducer generator logic once. No more going to each reducer file and understanding the same.
- Keeping your app performant with such patterns.
We got to a state to get reducers created by just providing corresponding config. This enables us to write just one reducer generator throughout the application. For every reducer needed in the application, developer just needs to provide a config and the rest is automatically taken care of. How this helps with above issues-
For every part of state doing the same thing, logic need not be repeated in reducers for corresponding states.
Handling scoped states becomes a breeze, as it is just another config. Have the same method of handling scoped state also enables us to standardise read and manipulation operations over the same.
Basic understanding of Redux.