Implement Storybook for RS Components

etanb commented 1 year ago

Additional context

Problem Statement

Currently, Engineering can't share with Design, or anyone else, the components we have created for ReportStream. Engineering has a range of components, from raw USWDS components to customized and wrapped USWDS components. Engineering should share with Design the components we have available, as well as, document the changes we've made to USWDS over time. This will reduce churn on alignment between engineering and design when scoping new features/designs.

The goal is a Storybook implementation that would showcase all of our components, and providing context on their usages AND level of customization / deviation from base USWDS components.

What to Know

Previous Design Sync notes https://docs.google.com/document/d/1oH2uDM670ELIuWGBR6wCrfMRrnMcbT62wHB3Bz_EXMo/edit#heading=h.abbhf7q488mi
This will involve Engineering and Design aligning on Storybook content, structure, and usage.

Open questions

Can we write some sort of simple linter / plug-in that evaluates when a new component is imported from Trussworks so we include it in our Storybook instance?
We'll need to sync closely with Design on this ticket for all the resources we have, and all the things that aren't documented. Might need a separate ticket for Design to track their work for that?

To Do (optional)

[ ] ...

Ready?

[ ] Epic reviewed with the team
[ ] All issues added (to the best of our knowledge) and epic is ready

Problem statement

In essence, Storybook is a showcase of all the coded-version of of our design components. For Design (note the capital D) to work well with engineering, they require "building blocks" so they don't have to redesign the wheel every time they create a new feature, do a bug bash or polish something. Currently we have no established component library or styleguide from an Engineering perspective that Design can work with which means they have to shoot-in-the-dark as to what is already coded and what is not. This greatly affects how well we can estimate things going forwards.

Context

Here is a link to our Figma "Master Components" page (which is incomplete) but a good reference point of what we'd want to mirror in our Storybook instance.

We'd also want to implement full page mocks of some of our main pages, like the homepage, unauthenticated and authenticated, different states of components like banners and modals.

Some excellent examples of living Storybooks for inspiration:

Acceptance criteria

[ ] All Styleguide items included in Storybook local instance
[ ] All Components items included in Storybook local instance

Caveat: all of the below very intentionally MUST include not just our customized resources, but anything we use from USWDS and beyond. Design, and anyone else looking at our Storbook, need to know EVERYTHING we're potentially working with.

Styleguide This would be an overview of the fundamental building blocks of our site that would include:

Colors
Typography
Spacing and Formatting
Icons

Components This would be an extensive overview of all the components in use across our site, from base USWDS modals and how we implement them, to customized table components:

Table
Modal
Link
Checkbox
Label
Textinput
Dropdown
Accordion
Button
DateRangePicker
Tooltip
Alert
Form
Banner
Title

This list is not-exhaustive

Add Ons

We may want to explore a few add-ons to our Storybook that would be extremely useful including:

Accessibility: evaluates the ally accessibility of our Storybook components and what levels of compliance they are in.

Figma Designs: a plugin that allows us to easily embed Figma designs within Storybook.

chris-kuryak commented 1 year ago

Ideally, this would be performed during or after the larger website technical rewrite/reconstruction.

chris-kuryak commented 1 year ago

Blocked until website rewrite complete.

chris-kuryak commented 1 year ago

Per Stephen Kao, this may not be blocked by website re-write. Need to get alignment from engr team.

CDCgov / prime-reportstream