First things first. This is meant as a hypothetical for what we could potentially build and provide to the FAST and larger web community as well as fitting our own needs. Discussion is welcome and encouraged so that we can narrow the focus and build a roadmap to meet the needs of the organizations we represent as well as the community's needs.
Abstract
Given that FAST currently does not have a prebuilt solution that members of the community can import and quickly plugin their design systems I think the Adaptive Web Project can be positioned to both provide that solution as well as showcasing the ideal library built with FAST.
The ideas mapped out here are from my own experiences with FAST as well as through observing the needs of the FAST community and their pain points.
High Level Overview
Ideally this project would leverage as much of the existing work from FAST as possible while also helping to fill in gaps in the community's needs. The project should use adaptive-ui and fast-foundation as much as possible and contribute back to FAST when gaps or issues are identified.
The general idea here is to follow a similar pattern to how FAST builds abstractions on top of the platform APIs, where fast-element is the lowest level and fast-foundation is the next step up. The packages we build here would be additional abstractions on top of FAST, where depending on the needs of the team or developer they could import ready to use components or even entire pages and layouts and simply add their design system and any customizations needed.
Capabilities not included with FAST that could be meaningful to the community
- A method/strategy for distributing a FAST-based design system
- This one can be tricky since methods for how configuration gets distributed to front end applications varies between organizations and products, I think we can still build a solution that lends itself well to
adaptive-ui and FAST. This can also be a good opportunity to contribute to the Design Token Architecture community group.
- One potential idea would be to store the design system as JSON and provide it via an API endpoint or CDN. How it would be stored and served would ultimately be up to the developers consuming FAST and the adaptive-web packages, however I think we can provide helpers and solutions for an application to easily consume a design system configuration at runtime or statically through a build process.
- A benefit to this would be that design systems can be versioned and distributed independently of the components and application authors could easily update design tokens without the need to publish a new version of their application if they use the runtime helpers.
- Layout components
- A common request from folks coming from React and other frameworks is components for building layouts. These can range anywhere from simple wrappers around FlexBox and CSS grid to full blown page layouts using semantic HTML elements.
- Examples of components missing from foundation that are frequently requested are
menu-button, split-button, and color-picker.
Potential areas to stand out amongst other libraries
I think we have a great opportunity here to experiment with some more opinionated features that are considered out of scope for FAST, but still provide value to folks looking for prebuilt UI solutions.
One such area could be common UI patterns where adaptive-web-components or a sibling package provides the pattern and consumers of the library feed it the data, or slot in components to quickly build out more complex UI elements. Some examples of this would be login/registration/lost password forms, confirmation dialogs, multi-page forms/multi-step wizards, color-scheme toggles, contact forms, etc.
Another area for prebuilt and opinionated solutions is by leveraging fast-router's FASTElementLayout helper to provide ready to consume page layouts for SPAs and PWAs where consumers need only to slot in the content for the page and provide minimal styling.
Tooling
A point of general frustration amongst the FAST community and the larger web component community is the lack of available tooling with a good out-of-box experience. While this has steadily been getting better with the advent of custom-elements-manifest, it could be better. Something I have experimented with on and off is building a minimal component sandbox for web-components not unlike storybook, but a lot more lightweight and geared specifically for building and testing web components in an isolated environment. Other ideas for tooling include expanding on the FAST figma plugin and other potential design-to-code or code-to-design tools.
First things first. This is meant as a hypothetical for what we could potentially build and provide to the FAST and larger web community as well as fitting our own needs. Discussion is welcome and encouraged so that we can narrow the focus and build a roadmap to meet the needs of the organizations we represent as well as the community's needs.
Abstract
Given that FAST currently does not have a prebuilt solution that members of the community can import and quickly plugin their design systems I think the Adaptive Web Project can be positioned to both provide that solution as well as showcasing the ideal library built with FAST.
The ideas mapped out here are from my own experiences with FAST as well as through observing the needs of the FAST community and their pain points.
High Level Overview
Ideally this project would leverage as much of the existing work from FAST as possible while also helping to fill in gaps in the community's needs. The project should use
adaptive-uiandfast-foundationas much as possible and contribute back to FAST when gaps or issues are identified.The general idea here is to follow a similar pattern to how FAST builds abstractions on top of the platform APIs, where
fast-elementis the lowest level andfast-foundationis the next step up. The packages we build here would be additional abstractions on top of FAST, where depending on the needs of the team or developer they could import ready to use components or even entire pages and layouts and simply add their design system and any customizations needed.Capabilities not included with FAST that could be meaningful to the community
adaptive-uiand FAST. This can also be a good opportunity to contribute to the Design Token Architecture community group.menu-button,split-button, andcolor-picker.Potential areas to stand out amongst other libraries
I think we have a great opportunity here to experiment with some more opinionated features that are considered out of scope for FAST, but still provide value to folks looking for prebuilt UI solutions.
One such area could be common UI patterns where
adaptive-web-componentsor a sibling package provides the pattern and consumers of the library feed it the data, or slot in components to quickly build out more complex UI elements. Some examples of this would be login/registration/lost password forms, confirmation dialogs, multi-page forms/multi-step wizards, color-scheme toggles, contact forms, etc.Another area for prebuilt and opinionated solutions is by leveraging
fast-router'sFASTElementLayouthelper to provide ready to consume page layouts for SPAs and PWAs where consumers need only to slot in the content for the page and provide minimal styling.Tooling
A point of general frustration amongst the FAST community and the larger web component community is the lack of available tooling with a good out-of-box experience. While this has steadily been getting better with the advent of
custom-elements-manifest, it could be better. Something I have experimented with on and off is building a minimal component sandbox for web-components not unlike storybook, but a lot more lightweight and geared specifically for building and testing web components in an isolated environment. Other ideas for tooling include expanding on the FAST figma plugin and other potential design-to-code or code-to-design tools.