Contrib.social

[2.1.x] UI Patterns Library: add sub-components

Open on Drupal.org →
Created on 1 April 2023, over 1 year ago
Updated 15 January 2024, 11 months ago

Problem/Motivation

We already have sub-components: they are not defined in the upstream design system, but they exists in the UI Suite implementation.

Examples from ui_suite_boostrap 5:

  • Accordion item, as a "child" of Accordion
  • Card body, as a "child" of Card
  • Dropdown item, as a "child" of Dropdown
  • List group item, as a "child" of List Group
  • Navbar nav, as a "child" of Navbar
  • Nav item, as a "child" of Nav

Examples from ui_suite_dsfr :

  • Tab and Tab panel, as a children of Tabs
  • Footer menu and Footer top, as a children of Footer

Examples from ui_suite_material 2 :

  • list item, as a "child" of List

Examples from ui_suite_protocol :

  • Footer section, as a "child" of Footer

They exist because it was sometimes needed to split a thick (with complicated structures in props and slots) upstream component in 2 or 3 implemented components (with flatter structures in props and slots). Because it is both a good practice (easier to implement, easier to understand, easier to maintain...) and a necessity for Drupal site building.

So, the main difference between a component and a sub component is:

  • A component can be placed in the slot of any parent component. A button, can be in a card body, a banner, an alert... There is no coupling between parent and children components.
  • A sub component is expected to be placed in a slot of its parent component. Example: carousel item only fits in a slot of carousel.

Today, there is a loose convention : putting the component label in between parenthesis. This convention shows there is something missing in our API.

Proposed resolution

sub-components are normal components :

  • They have their own meta properties: id, label, description...
  • They have their own fields (slots) and settings (props)
  • Usually, they don't have variants, but it may happen
  • They generate "#type => pattern" render arrays. They show up on every discovery.

They have a specific "parent" property where the value is another pattern ID. Having this property is all a component needs to be a "sub-component". A sub component has one and only one parent component.

The differences are visible in the library:

  • They don't have their own preview alone (because most of the time the preview is bad with out the parent component)
  • They don't have their own library page: they are displayed in the parent library page

User interface changes

Yes, it changes the library pages.

API changes

No. The added property is not breaking anything.

✨ Feature request
Status

Postponed

Version

2.0

Component

UI Patterns Library

Created by

🇫🇷France pdureau Paris

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

Comments & Activities

  • Issue created by @pdureau
  • Comment over 1 year ago →
    🇫🇷France duaelfr Montpellier, France

    I'd love some way to hide components in the library but I think it could be wider than only subcomponents.
    Some might also be kind of parent elements. For example you could have a generic card component that you want to expand for more specific uses like card_news, card_event or whatever. You could want this generic element to be hidden in the library.

    If the purpose of this feature is only to hide elements in the library. I think it should be a lot simpler.
    My proposal is to add a hidden property on patterns we don't want to show.

    We could start by only providing a way to hide them in the library, then we could extend that feature for consumers too. Let's see some examples.

    Hide the pattern everywhere (library and consumers):

    mypattern:
  hidden: true

    Hide only in the library:

    mypattern:
  hidden: library

    Hide in the library and… in layouts:

    mypattern:
  hidden: 
    - library
    - layouts

    I believe only hiding in the library can be done in 1.x but extending that to consumers would need to be done in 2.x
    What do you think about it?

  • Assigned to pdureau
  • Comment over 1 year ago →
    🇫🇷France pdureau Paris
  • Open on Drupal.org →
    Core: 10.0.7 + Environment: PHP 8.1 & MySQL 5.7
    last update over 1 year ago
    Not currently mergeable.
  • @pdureau opened merge request.
  • Issue was unassigned.
  • Status changed to Postponed about 1 year ago
  • Comment about 1 year ago →
    🇫🇷France pdureau Paris

    Let's move this to 2.x now the development rbanch is open and active.

    However, not in the scope of 2.0.0, so let's target 2.1.x

  • Comment 11 months ago →
    🇫🇷France pdureau Paris
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024