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
   

   View Slide

2. Who Am I
   Yashika Garg
   Frontend Architect @ SiteDocs
   yashikag.com
   yashikagarg13
   yashika_garg
   

   View Slide

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
   

   View Slide

4. Component Specific State
   ● Clubbing state variables related to a component
   ● Example
   {
   locations: {
   list,
   error,
   isLoading
   }
   }
   

   View Slide

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
   }
   }
   

   View Slide

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
   }
   }
   

   View Slide

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??
   

   View Slide

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
   }
   }
   

   View Slide

9. State Based on Data Interactions
   ● Example: List of form groups
   {
   groups: {
   [groupId]: {
   id,
   name.
   items,
   repeatable,
   isRepeated,
   isReplica,
   numberOfTimesRepeated,
   isLastReplica
   }
   }
   }
   

   View Slide

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
    

    View Slide

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
    

    View Slide

12. Conclusion
    ● Process of evolution
    ● Unique to each application
    ● Visualizing interactions can simplify state structuring
    

    View Slide

13. Questions
    { ? }
    

    View Slide