To begin using Seeds, check out the ‣ repository and the published Storybook. The Storybook documentation is paired with more design and implementation-focused documentation in Zeroheight.
Seeds is taking a lot of inspiration from atomic design when it comes to making decisions about what is a component in the new system. The majority of components in Seeds are the smallest atomic units intended to be building blocks that when pieced together will make up the full content of a page (i.e, a Button, a Heading, an Icon). We also include in Seeds some molecules, which are repeatable patterns made up of our own atoms (i.e., a Dialog, an Alert, Tabs).
Currently in UIC, in addition to having some atoms and some molecules, we also have organisms, which are essentially large pieces very specific page content. These kinds of components at the organism level will not belong in our new design system. They contain business logic, are challenging to maintain and allow for customizations, and are not repeatable patterns. Due to needing to accommodate slight customizations in jurisdictions over time, they have built up a messy system of props and toggles. This kind of large page content belongs in an individual implementation, re-built using Seeds atoms.
By moving this direction, we improve theme-ability, customizability, maintainability, and flexibility, both for ourselves and for our consumers.
As we move through this atomization process, we are discovering pieces of UI made from Seeds atoms that seem reusable, but aren’t necessarily a component in their own right. We are calling these patterns. We want to offer consumers guidance around and examples of repeatable patterns built from our atoms. Components like MediaCard (built from a Card and a HeadingGroup) or ActionBlock (built from an Icon, Header, and a Button) are patterns.
Design system tokens are another significant addition to Seeds from UIC. These are implemented as CSS variables. The intention of our design tokens is that they can be overridden once and theme the full component library.
In addition to the high-level, global Bloom design tokens like our set of colors, sizes, and typography, we now have an expanded set of semantic tokens that is critical to helping consumers theme and customize Seeds. The more we rely on semantic tokens, both internally and as consumers, the more theme-able and consistent the UI will be. Ideally, consumers are never overriding a global token, but relying on semantic tokens.
For example, we have the semantic token --seeds-color-primary assigned to --seeds-color-blue–500, and we then use --seeds-color-primary across Seeds where it makes sense according to the design system. If a consumer wants to change that color, they can at root override --seeds-color-primary which trickles down to immediately affect all Seeds components.
But we also drill down into more specific, use-case focused semantic tokens, like --seeds-bg-color-surface assigned to --seeds-color-white which is used across Cards and Dialogs, or --seeds-input-border-color assigned to --seeds-color-gray-450 which is used across all form components.
Individual components will lean first on using semantic tokens but may also consume design system tokens.
The base set of tokens are not meant to be overridden, but the full set of components is theme-able by overriding semantic tokens at the root level once.
In order to support consumers in creating custom page content and as another attempt to support customization and flexibility, a few of our components are taking a subcomponent / slotting approach.
A component that demonstrates this well is the Card component. If you look at the Card stories, you can see that in order to build a Card, you make use of multiple “subcomponents” - a Card wrapper, Card.Header, Card.Section, and Card.Footer. Our styles are added to make these components fit together nicely in different scenarios and allows consumers to customize what sections they want in their Card and in which order, as opposed to adding in a prop like hideFooter.