This issue exists to raise awareness of our intent to implement the following (significant) changes:
- Change the default design system and styles for the
fast-components package.
- 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:
- 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>
- 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!
This issue exists to raise awareness of our intent to implement the following (significant) changes:
fast-componentspackage.fast-components-msftBackground
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-componentspackage 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 thefast-componentspackage 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:fast-componentswill be FAST styled components leveraging the default FAST design system values. The components exported here will follow the convention of being prefixed withfast:fast-componentswith 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 withmsft:This change is breaking, and I believe a good reflection of what should be our v1 implementation of
fast-componentsandfast-components-msft. As always, we welcome your feedback and thoughts!