20181121 Technical Council Meeting Notes

Presentation of UI assessment to bring TC up to speed and seek recommendations

Areas of concern, will focus on intersection of quality, performance, and accessibility.

• Routing architecture: does not use routing architecture to control the view. Refresh, deep linking, back button use does not result predictable UI state, the URL does not go to a predictable state of the UI.
  • Architecturally significant, can eliminate entire categories of problem.
  • Makes it difficult to manage focus, which becomes a problem for accessibility.
  • Having access to the data is essential, data retrieved at moment component rendering. Data access controlled at server, not at higher level, so often pull back more data. Not having a higher-level gateway for data makes it hard to get the same data back every time, in the right order. Too much coupling between component and data. In inventory, makes 26 requests for detail view. Often hit browser limit for concurrent requests for data.
  • Because we have components that manage their own routing, there are many components that would need access to the URL to preserve predictable state. So difficult developers must choose between using search and sort or not, interferes with providing accessibility. Accessibility lab shows screen readers have very hard time with this.
  • Summary: data fetching and routing should be provided to the components, components should not manage these themselves.
  • Need to apply same patterns as have in e-holdings, apply to inventory. Want to have solution implemented in a few modules before generalizing and providing to core.
• Stripes God Object
• (Skipping sections due to time)
• Data layer
  • Performance around fetching and caching data
  • Stripes connect is limited it what it can do for caching, much make round-trip to server for every bit of data with every user action.
  • Requests to server are not batched
  • Poor for performance and user experience
  • No real improvement path with stripes-connect
  • Suggestion is to replace with Apollo GraphQL
• Proposed Strategy
  • rewrite ui-inventory
    • Use routing from e-Holdings, use GraphQL

Source of problem: the architecture was not in place at beginning and the cost is now becoming apparent. The architecture is key to enabling the user experience, but the current architecture does not allow the desired experience. To give the experience, need to put the architecture in place, and question is how. ui-inventory is most complex, has large backlog. Would need to do assessment to fully understand how to navigate our way out of this situation. Will put the issues into three buckets and try to come up with a proposed strategy:

1. bugs that would be eliminated by rewrite
2. performance improvements
3. features that have not been implemented yet.

If could work with POs, could do the assessment in a couple weeks and have a better idea of what we have to do.