[Intent to implement] Change default styles for fast-components and create a new MSFT package

[chrisdholt]

This issue exists to raise awareness of our intent to implement the following (significant) changes:

1. Change the default design system and styles for the fast-components package.
2. Create a new package for Microsoft styled components: fast-components-msft

Background

In our previous implementation of FAST, we were building for both a variety of frameworks and design systems. This led us to make certain decisions about how we structured the project and how packages were broken up. As we've created our web component packages, we elected to include all core functionality (class, template, default styles) as part of a single package. The reasoning here was that we are building as an extension of the web platform and not individual frameworks. Our goal of being able to use FAST with any framework is more easily accomplished by building with web standards.

Once we had decided to include all the parts and pieces in a single tree-shakeable package, it made sense to also include a default design system and a default set of components as the primary exports. This allows users to leverage components directly from the fast-components package or leverage just the parts they need and recompose their own components. At the time we had started building out our web component proof of concept, the only style and design system investment the team had fully completed was the Microsoft styles (fast-components-styles-msft) so the decision was made to have the default export visually match the Microsoft package for the time being.

FAST is a foundation, MSFT is an implementation

As we move forward and look to shift out of "beta" and into a more stable release, we feel it's important to make a change to the default component styles we are exporting from fast-components. While FAST is organizationally under Microsoft, the goals of our project are industry focused. Additionally, FAST has its own brand and its own visual design language. Our goals with the FAST design system and the fast-components package is to provide flexibility at scale, a good foundation for individuals and teams to build with, as well as the ability to create their own design systems by mixing the component templates and classes with styles specific to their design language.

With this in mind, and considering that we now have a UI system for FAST-DNA (currently named "fast-frame"), shifting our default exports to align with these goals makes sense. Additionally, we hold a strong belief that goals and components which are specific to Microsoft should not be elevated above those of other design systems and organizations. This is a good thing for the community and for the goals which are specific to Microsoft. By providing a MSFT specific package, we can better support the needs of that community. In many cases, this may be as simple as providing convenient patterns which are specific to the MSFT design system but not prevalent in other systems (such as this example).

Next Steps / Implementation

We've created a feature branch to manage this change without disrupting other in-progress work (features/fast-components-msft). Within a week we'll raise a PR to merge these changes from the feature branch to master. As mentioned above, the change will establish the following:

1. The default exports of fast-components will be FAST styled components leveraging the default FAST design system values. The components exported here will follow the convention of being prefixed with fast:

<fast-button>Button</fast-button>

2. A new MSFT package which implements the template and classes from fast-components with MSFT specific styles and a MSFT specific implementation of the design system. This will serve as an example and pattern for other design systems wishing to leverage the system. The components exported here will follow the convention of being prefixed with msft:

<msft-button>Button</msft-button>

This change is breaking, and I believe a good reflection of what should be our v1 implementation of fast-components and fast-components-msft. As always, we welcome your feedback and thoughts!

[janechu]

Can you specify how this change is breaking?

[chrisdholt]

A new package has been created as part of this proposal: fast-foundation. This package includes the templates, classes, and utilities needed to compose a web component. The fast-components package will leverage those parts to compose custom elements based on the flexible FAST design system. The fast-components-msft package will use those to compose custom elements with Microsoft styles.

In regards to @janechu's question on how this is breaking:

• The exports from the packages will change. fast-components will not re-export the parts from fast-foundation. Shared templates, classes, and utilities for primitives will live in fast-foundation.
• The visual system for the fast-components package will change
• The design system for the fast-components package will differ slightly
• Dependencies have changed

The fast-foundation work is being done with #3122 and as the build has succeeded, we will be merging this package :).