Skip to content

Discussion: What belongs in the DSR documentation pages? What belongs in the code? #568

Description

@natalia-fitzgerald

Discussion topic

What is our DSR philosophy for which component variants should live in the DSR on the Storybook documentation pages? How about in the code?

Background

  • The DSR is primarily intended to serve CFPB developers and designers as a shared source of component code that can be used to build consistent and accessible CFPB products and reduce the burden of maintaining custom or duplicative code.
    • The DSR provides React versions of CFPB Design System components
    • The DSR can include React versions of cf.gov components that are not yet DS components
    • In an ideal world, the CFPB Design System is the source of truth for patterns and components.
  • A secondary audience is non-CFPB developers and designers that wish to build websites using the reusable components that we provide in the DSR.

Related questions

  • Should the Storybook documentation pages exclusively include components and patterns with known use cases; for use in CFPB web products?
    • Generally, the minimum bar has been that 2+ web products must have a need for a specific component before we add it to the DS and/or DSR.
  • Should the actual code include generic versions of components that could be used by the secondary audience?

Let's share ideas!

@anselmbradford @virginiacc @billhimmelsbach @flacoman91

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions