Add support for documenting design system components

Created on 9 February 2023, about 2 years ago

Problem/Motivation

It is clear that we want to be able to document design system components. However there are questions that would need to be worked out:

  1. How or where these components would be listed?
  2. Does drupal have any awareness of components to use as the source for the list of possible components?
  3. What would the alias pattern be for CMDocuments that are documenting Components?

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

✨ Feature request
Status

Active

Version

1.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States swirt Florida

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @swirt
  • πŸ‡ΊπŸ‡ΈUnited States swirt Florida
  • πŸ‡ΊπŸ‡ΈUnited States swirt Florida
  • πŸ‡ΊπŸ‡ΈUnited States mortona2k Seattle

    I have been using SDC for displaying entities using SDC Display. UI Patterns also provides a way to render SDC using different drupal displays (blocks, fields, layout builder).

    Just pointing out that this may be an example of how we might want to track usage of these things.

    On the other hand, usage of SDC in code is very different to track.

  • πŸ‡ΊπŸ‡ΈUnited States swirt Florida

    I like the idea. Sadly I have no site that is using Single Directory Components so I am not sure how to even begin on this. I am guessing there is something in Drupal that discovers them all, but that is just a guess. If you have any ideas on how to proceed, I am all ears.

  • πŸ‡ΊπŸ‡ΈUnited States mortona2k Seattle

    I don't really know how to proceed.

    The question in this ticket is actually extremely complex.

    What is a component, as a design concept?

    What is a component to a developer?

    What is a component in Drupal?

    What is a component to a content editor?

    Components are...

    To a designer, components are what they see on the surface. They may not be considering the underlying structure or the UI needed to create components.

    To developers, components are code structures that can be reused. They need to know what's available to extend or how changes will affect the system.

    In Drupal, we may call a chunk of anything a component. A menu link, a menu block, a region, paragraphs, etc. But the data structure is different from the code file structure. There may not be one single code file that represents what is conceptually a discrete component on the page. For example, a block type rendered with a customized layout in layout builder.

    To a content editor, a component may be what is useable by them to edit content in a template.

    I am currently reviewing some modules for auditing content architecture. The Xray Audit module has a report that shows available display modes for entities, and a summary of how they are configured.

    As far as documenting how "Components" are used within the content model, I think that kind of report covers the expectation. Maybe template overrides in use would be good if we could surface that, or preprocess hooks in use by contrib and custom modules.

    I'm hoping that more solutions like UI Patterns come out to help manage use of SDCs in a system. That seems to be the integration point with design systems.

  • πŸ‡ΊπŸ‡ΈUnited States swirt Florida

    These are great suggestions @mortona2k. Thank you.

Production build 0.71.5 2024