[Tracking] Design system (components)

[luxaritas]

General Components

• [ ] #51
• [ ] #52
• [ ] #53
• [ ] #54
• [ ] #56
• [ ] #57
• [ ] #58
• [ ] #59
• [ ] #60
• [ ] #61
• [ ] #62
• [ ] #63
• [ ] #84
• [ ] #55
• [ ] #64
• [ ] #65
• [ ] #66
• [ ] #67
• [ ] #68

Form elements

• [ ] #69
• [ ] #70
• [ ] #71
• [ ] #72
• [ ] #73
• [ ] #74
• [ ] #75
• [ ] #76
• [ ] #77
• [ ] #78
• [ ] #79
• [ ] #80
• [ ] #81

[luxaritas]

We're planning on building our components on top of the Inkline library. The idea is to help limit the amount we're re-inventing the wheel, plus they've probably thought more carefully around things like micro-interactions and accessibility where we may not do as good of a job. Inkline shouldn't have the issues we've seen with bootstrap (it's designed to be customizable, it's build to be tree-shaken, and it has a minimal dependency footprint, and doesn't require coordinating multiple libraries like we currently do with bootstrap and bootstrap-vue).

Our plan is to "wrap" inkline components in our own components, where they exist. That way: 1) We don't require new developers to understand inkline - just what we expose in our codebase 2) We can make any additional standard customizations we want 3) Custom components in our design system that inkline doesn't expose can be surfaced consistently with the ones it does expose 4) Admittedly, I have a bit of nervousness around inkline since it appears to only have one maintainer. If we need to, this provides us an easy way to swap out inline with something else (or our own implementation)

We also want to implement versions of these components in Figma to use in our mockups

[luxaritas]

Additional inspirations:

• Vuetify 3
• Bootstrap
• Carbon

[luxaritas]

These issues are currently blocked by #29