16 Sat 08:55 AM – 05:20 PM IST
Accepting submissions till 01 Nov 2019, 03:15 PM
After a successful edition in Delhi in 2018, we are back with the 2019 edition of ReactFoo Delhi.
ReactFoo Delhi features talks and discussions on:
16 November 2019
C D Deshmukh auditorium, India International Centre (IIC) Main, 40 Max Mueller Marg, Lodhi Gardens, Lodhi Estate, New Delhi - 110003.
For information about the event, sponsorships, bulk ticket purchases and partnerships, write to email@example.com or call 7676332020.
Email us firstname.lastname@example.org for bulk ticket purchases, and any queries on the sponsorship.
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.
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.