Create strategy for system-specific components in new documentation site

[line47]

The system specific strategy is taking the HCgov and Mgov system specific components/patterns and making them part of the core design system.

Currently we have theme (HCgov/Mgov) specific components which include headers, footers logos/icons and stars. As well as several custom css classes and overrides for specific components.

HCgov specific components

• HCgov header
• HCgov footer
• HCgov logo (logo)
• Inset (typography style)

HCgov specific overrides / custom css

Logo, Inset, FormLabel, Button, PrivacySettings, Header, Footer

Mgov specific components

• Mgov card
• HHS icon (logo)
• Mgov specific icons
• Mgov logo (logo)
• Simple footer
• Stars
• Consistent header (MAX team maintains this)

Mgov specific overrides / custom css

Tooltip, Icons, HelpDrawer, Forms, Dialog, Choice, Buttons, SImpleFooter, NavigationMenu, Navbar, GlobalHeader, Card

Add components to core design system

Lift these components out of the child design systems and reintroduce them into the core design system. This will simplify the consumption of the design system components and in theory all components could then come from core.

Adjust and combine overrides with existing styles

Utilizing token theming, and class aliases, we should be able to merge overrides with the existing styles. Using class aliases that inherit other class settings, we should be able to provide the same class names for the time being until they can be deprecated sometime in the future. Token theming should be extensible enough to handle any kind of variation needed. This of course would require token theming to be in place in Master in order to begin implementation. Classes which are defined in sub-systems but not defined in core can simply be appended to existing style definitions to automatically gain priority.

Documentation site

These components will fit into the documentation site under the components or patterns section and in the case where we have 2 different headers we will have a header section with multiple header pages under that section. For example...

• Headers
  • Mgov header
  • HCgov header

In addition, the components will always be visible no matter what theme you select. Because all themes contain all component theme variables, these theme specific components should look theme-related by default, or can be tweaked with relative ease.

What this strategy for system-specific components does

• Begins to move components into a single design system and away from our current siloed structure
• Raises the visibility of all design system components for all product teams of the design system
  • For example, Stars is something that Mgov has and HCgov could probably make sure of
  • For example, Card is something that Mgov has and HCgov could probably make use of
• Begins to surface redundancy and similar components where we might consider homogenization in the future
• Supports a future where we are leveraging theming for all components in the design system
• Makes supporting components easier under one roof

[zarahzachz]

I love the idea of pulling these components into Core - makes it way easier to spot duplication and reduces the need for our team maintaining multiple components with slightly different APIs

[babsdenney]

This looks like a good approach and support having core level components. My only concern is teams not having an option to share components that aren't or suitable or ready for the design system. This happens a lot on Medicare, where components are made individually by teams instead of sharing a single component. If we are going to only have core level components I think there still needs to be a place or process for teams to share components.