Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Improving State: Case Studies

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.

5da13604dfea95af68ac2ad1d1ec2cdf?s=128

Yashika Garg

May 17, 2019
Tweet

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