Improving State: Case Studies

Given an SPA, where you have multiple lists, dialogs, headers, detail pages, each reusing data from different components, redux has been the most popular tool for state management. But our problem doesn't just resolve on choosing the state management tool, it gives birth to another problem of how we can organise this state so that when our application expands with our user's needs, as a developer, we should be able to cater that in minimum time and almost no bad code or hacks. Estimating the features could be beyond our reach but creating an expandable state structure that can evolve with needs without being a clutter is in our hands. In this talk, we will discuss three different state structuring strategies I have implied in my recent project to achieve my goal: Structuring based on components, Considering the source of data - UI and API calls as a base for assembling state and Deriving state from interactions with data.

Transcript

1. Improving State: Case Studies Yashika Garg Frontend Architect @ SiteDocs
2. Who Am I Yashika Garg Frontend Architect @ SiteDocs yashikag.com yashikagarg13 yashika_garg
3. It’s not tool, It’s what comes afterwards • Multiple state management tools • Problem of structuring state lies with developers • Effects ◦ Productivity ◦ Estimates ◦ Code clearity ◦ Application expansion • Requires iterations and think through
4. Component Specific State • Clubbing state variables related to a component • Example { locations: { list, error, isLoading } }
5. Component Specific State • Problem: Multiple components using same data set leads to data redundancy • Example: ◦ Global select location modal and form’s change location input both uses list of locations ◦ { locations: { list, loading, error } } { formLocations: { list, loading, error } }
6. State Based on Source of Data • Segregate state variables based on whether they come from backend or generated from UI • { UI: { locations: { ids, loading, error, filter: { formId // Use selector to filter data at FE } } }, DB: { locations: {} // Data that comes from backend } }
7. State Based on Source of Data • Problem: Data that comes from backend are not just records but also has information of UI States • Example: ◦ List of form groups ▪ Repeatable to a maximum limit ▪ Each replica is repeatable ▪ Total stays below maximum limit ▪ Repeat button added to last repeated group ◦ Should we create separate list of groups for keeping UI Interactions and data from backend??
8. State Based on Data Interactions • Structure state based on how application interact with given set of data • Example ◦ List of locations ▪ Need entire list in global location selection modal ▪ Need locations based on selected form in form template ▪ { locations: { list, error, isLoading, ids, filters } }
9. State Based on Data Interactions • Example: List of form groups { groups: { [groupId]: { id, name. items, repeatable, isRepeated, isReplica, numberOfTimesRepeated, isLastReplica } } }
10. Other Questions that bother • Should list be stored as array or object ◦ Think based on interactions ◦ If data is represented as list =>Array ◦ If each object in list has its own set of interactions then you will end up accessing a particular object multiple times => Object
11. Other Questions that bother • If two different data objects share same structure, can the structure be reused ◦ Think based on interactions ◦ If one structure is exposed at one time, structure can be reused ◦ Example: ▪ Signed form and Form Template
12. Conclusion • Process of evolution • Unique to each application • Visualizing interactions can simplify state structuring
13. Questions { ? }