Architecture and scope of this project

[KingOfTac]

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

1. 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.
2. 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.
3. 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.

[awentzel]

I agree with nearly everything you've said here. Obviously, we will want to document our approach concisely and thoroughly. As a product owner, I really believe this could cut down engineering effort up to 75%, and if we build this as easy to use as Create React App and is always pegged to the latest open web standards and innovations that land in evergreen browsers. This is what could bring hundreds of companies to FAST is my dream.

My immediate corporate needs include FAST Web Components, Design System, Layout System, and responsive Web Patterns for UX would be a bonus. I want my teams to focus on business requirements with a plug-n-play brand design system. I have three primary SaaS platforms currently under management and another coming in Q1. If the entire technology stack can match just think of how lean and productive my engineering teams can be with reliability, stability, and performance built in.

[awentzel]

How should we get into more implementation details? Does it make sense to do that here, or perhaps, that's just better in an RFC or within PRs.

[KingOfTac]

Probably within RFC or PRs. I imagined this discussion to mainly be for determining the overall scope of the project, at least for a V1 release with whatever gets dropped here as out of scope for v1 going into a backlog to discuss later or refine further if they are deemed to be of some value to the project later on.

[awentzel]

Should we move this to https://github.com/Adaptive-Web-Community/Adaptive-Web-Components/discussions

[KingOfTac]

Should we move this to https://github.com/Adaptive-Web-Community/Adaptive-Web-Components/discussions

That would be a good place I think

[bheston]

I'm aligned with the alignment principles you mention above regarding following FAST convention and contributing to the larger FAST community where our goals are aligned.

I also agree that some sort of layout capabilities are important. This was something I started looking into in Adaptive UI and the density system, though it was unclear exactly how it would manifest in the components or how many layout-only (not traditional components) would be built as part of FAST. This would be a great place to formalize that aspect of interface glue.

Initially I see the core requirements as a full component set based on fast-foundation using adaptive-ui for styling. We have a lot of great work started on this, and this is the area I will initially focus. I agree with the further discussion above that PR comments are a great way to address that, and as I mentioned in Discord I have a version of components in process that I propose to start with. I will be getting this into this package and submit a PR. I expect this to be highly "expected" and "non-controversial" work as it will closely follow the deprecated fast-components and Fluent Web Components.

Following that, design-system-as-a-service was a discussion point in FAST that I think would be perfect to address here. I have some thoughts about how this could work based on the existing Design Token infrastructure. It's actually the third part of my blog post series I need to finish. Rob had also written about a potential "Iteration 6" in The Future of FAST Foundation. One large point to consider in this is how much the design might be allowed to change between app runs. That is, is the "service" aspect of this runtime or build time. There are cases for both models. I propose once we get the larger project off the ground we work on the details of this.