Design: Package interfaces use Pajamas components
(this description is rough - will add more detail later)
Problem
Currently all registry pages use a row component that is specific to package. All interfaces should strive to use Pajamas components to keep the UI consistent.
History
This component was chosen over the Pajamas table due to poor mobile performance, poor handling of dynamic data, poor load times
Objective
- Audit all use cases of this component in use, both within package and similar UI elements elsewhere in GitLab (e.g. issue list). Take note of whether the user is searching or browsing, if some information is more important than other information, and all fields displayed
- Audit all information the component can display (& any idiosyncrasies, such as merge icon...)
- Audit future vision of all interfaces that use this component - what will be added? Are there new use cases?
- Secondary research on linear v. tabular layouts - usability/accessibility, compare with use cases
- Understand technical constraints of Pajamas table, the package row component
- Collect data on viewport width of all interfaces
- Collate research and determine a path to have all package UIs using Pajamas components
Potential solutions
- Add row component to Pajamas
- Address issues with Pajamas table and use Pajamas table
Dependencies
- Ongoing 'bulk select' pattern in Pajamas
- Pajamas team - either to address table or help adding row component
- Teams that own UIs with similar components (e.g. issues list)