V3 Evolution

Data Architecture

• Originally Redux-only
• Purpose-built response blobs from the server
• Very little data reuse, and a lot of duplication

Data Architecture

• Entities model
  • Store raw resource records on the client
    • FulfillmentPlans, SalesOrders, etc.
  • Derive data views for components to consume at the container level
  • Potential for record-level updates from the server

Data Architecture

• Redux has a bad habit of causing global rerenders
• Our epic pipeline has a bad habit of spreading Redux updates across event loops
• React now provides some out-of-the-box solutions to help mitigate these situations

Context Migrations

• Context Providers allows us to house data within a vertical slice of the application
• Mini reducers allow us to isolate state changes to a given Context Provider, or mixed modes can update local state as well as Redux data models

DisplayGrid

• As originally implemented:
  • Allows for up to 500 records at up to 40 or so columns to be viewed per page
  • Allows for drag-and-drop column reordering
  • Allows for draggable column resizing

ExpandableDisplayGrid

• First major overhaul:
  • Added the notion of expandable rows:
    
    
    
    
     
  • Migrated to CSS Grid layout
  • Added virtualization, to only render rows within the visible scrolling area

HooksDisplayGrid

• Second major overhaul:
  • Slim down top-heavy component and prop-drilling
    • Migrated shared data needs into context
  • Moved a lot of the more bloated/expensive computations into hooks

Build Details

• We use Webpack to manage bundling
• We use some code splitting to reduce bytes shipped to the client (mostly SVGs and language packs)
• Naming chunks with contenthash helps cache life
• Some initial problems with code splitting prior to CDN
  • Long-lived sessions could request invalid filenames

Performance

• How do we prevent performance footguns?
  • Reducing the count and complexity of our epics
  • Migrating to context reduces the need for Redux and associated plumbing for state management
  • Drive UI components from the UI when possible
  • Better usage of RxJS to deconstruct epic chains

Performance

• Performance tests in Puppeteer
  • Both workflow-oriented and component-oriented timings are tracked and data is stored to Postgres
  • Increase our usage of performance marks and measures within the UI project itself
  • Use these metrics to ensure from one release to the next that we're not impacting performance
    • If we do, revisit the changeset in question, and potentially explore other solutions