$30 off During Our Annual Pro Sale. View Details »

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.

Yashika Garg

May 17, 2019
Tweet

Other Decks in Programming

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