Allow SDCs to be marked to be excluded from UI

This is a good idea as there are often components that aren’t meant to be used by the end user directly.

Great idea. 2 proposals:

SDC's status property

We already have the status property:

      "type": "string",
      "title": "Development Status",
      "description": "Use this property to identify if the component can be safely used in production.",
      "enum": [
        "experimental",
        "stable",
        "deprecated",
        "obsolete"
      ]

https://git.drupalcode.org/project/drupal/-/raw/HEAD/core/assets/schemas...

Display building tools can ignore "obsolete" components, for example. Do we add an "internal" value?

Drupal plugins's no_ui

The Laurii's proposal. Some Drupal plugins have a no_ui property (declared as PHP attributes because of the discovery, it will be in YAML for SDC):

• FieldType
• all the Views plugins

For example, in FieldType:

   * @param bool $no_ui
   *   (optional) A boolean stating that fields of this type cannot be created
   *   through the UI.

I like this request, here is a starting point proposition.
I would like to challenge the no_ui term because of negative naming (boolean blindness).
I understand it's used on plugins, but we can go to has_ui as default true.

@pdureau is fast, so my proposition is a 3rd one, has_ui with default true!

I wouldn’t want to use obsolete to convey this as it’s misleading. The internal or no_ui approaches seem fine. I prefer the former only so there are less things to define but perhaps it’s confusing to mix things like stable and internal

What is happening is this optional property is missing (which will be the case for most of the components)

• with status, if missing, we show the component in UI
• with no_ui, if missing, it is like no_ui = false so we show the component in UI
• with has_ui, if missing, is it like has_ui= true ?

Yes with has_ui, if missing, it is like has_ui= true

I wouldn’t want to use obsolete to convey this as it’s misleading. The internal or no_ui approaches seem fine.

Of course, "obsolete" was just an example of some filtering UI tools are already able to do. If we go the status way, we need a new value.

However, there is the cardinality issue: is a component able to be "internal" and "experimental"/"stable"/ "deprecated"/"obsolete" at the same time? If yes, let's go for no_ui or had_ui. If no, status has my (little, not enforced) preference.

The reason I think this should be separate from status is that internal / no UI components have a lifecycle too. You may want to deprecate an internal component too or have an internal component be experimental.

So, let's forget status 😉

This is a very useful addition, especially for design systems that include internal or utility components not meant for end-user selection. I agree with the preference for using has_ui (default true) over no_ui due to better readability and avoiding boolean blindness.

Also, keeping this separate from status seems clearer, since internal as a status could be misinterpreted as lifecycle-related rather than visibility-related. This distinction helps maintain clarity for both developers and UI tools.

Thanks to @lauriii, @mogtofu33, and @pdureau for moving this forward quickly!

Back to no_ui as it makes more sense if missing then it is false.

Thanks for the fast MR @mogtofu33

I guess you also need to update:

• https://git.drupalcode.org/project/drupal/-/blob/11.x/core/assets/schema...
• https://git.drupalcode.org/project/drupal/-/blob/11.x/core/assets/schema...

Opening the bikeshed of the year; it looks like SDC is using camelCase for the properties. Should we name this as noUi then? 😅

Indeed, SDC is using camelCase for libraryOverrides and thirdPartySettings (only).

JSON schema is mixing:

• camelCase for standard properties (example: additionalProperties)
• kebab-case for custom properties (example: x-translation-context)

I would personally prefer the Drupal wide consistency (no_ui) than the SDC wide consistency (noUi). But this is not a strong opinion.

Schema added, description and title could be optimized, feel free to update them directly on the MR.

description and title could be optimized, feel free to update them

Thanks. I may remove any mention of "internal". "No UI" is already descriptive enough.

Hmm… don’t like “property” used in description but see it’s in status

Perhaps:

Title: Exclude from UI
Description: Use “true” to exclude a component from the UI and “false” to show it

Though I don’t love that either

I would personally prefer the Drupal wide consistency (no_ui) than the SDC wide consistency (noUi). But this is not a strong opinion.

I would have agreed with this if we didn't already have thirdPartySettings in SDC yaml but third_party_settings in config. But given that we have that, I think it would be weird to make no_ui the outlier for a key that we don't camelCase.

I would do camel case to be locally consistent even if it’s not globally consistent

I would have agreed with this if we didn't already have thirdPartySettings in SDC yaml but third_party_settings in config. But given that we have that, I think it would be weird to make no_ui the outlier for a key that we don't camelCase.

I would do camel case to be locally consistent even if it’s not globally consistent

OK for me. The analogy with thirdPartySettings and third_party_settings is convincing. I will do the changes soon.

Also, thanks @sonam_goswami55 for your feedbacks, and welcome to the community.

So we have:

    "no_ui": {
      "type": "boolean",
      "title": "Internal",
      "description": "Use this property to exclude a component from the UI, for internal components."
    },

Why not call it internal directly? not as a new value of status but additionally.

We already have a sort of internal prefix for libraries we don't want people to rely on, that would solve the camelcase issue too

I see that makes sense.

I'm not super happy with the negation, can we have something clearer, it's not obvious that UI = display builders, no_ui could mean the component only output hidden html (script tags). I'm all for consistency but is there a big overlap of folks writting SDCs and FieldTypes/views plugins that needs to be hidden?

I asked some AIs for the naming, got a few interesting suggestions: uiHidden (clearer that the SDC has an output, just we don't want to list it), excludeFromUiBuilders longer but can't really argue about the clarity.

Even got headless as a suggestion since it's for programmatic use, not saying we should use that but it's an interesting take on the situation :)

I'm not super happy with the negation, can we have something clearer, it's not obvious that UI = display builders, no_ui could mean the component only output hidden html (script tags).

You are joining Jean's initial position here.

noUI was picked because it was already a Drupal thing and the mechanism we are proposing is the same:

• if a View plugin has "no_ui": View UI is not proposing it to the site builder
• if a FieldType plugin has "no_ui": Field UI is not proposing it to the site builder
• if a SDC has "noUi": display building tools can choose to not propose it to the site builder or the content contributor

fair enough, let's go with that

Really don't want to bikeshed this, but #25 had a great argument for using camel case which seems it convinced most detractors (+1 with myself).

"Exclude from UI" is probably more accurate than "Internal" for the schema docs.

Really don't want to bikeshed this, but #25 had a great argument for using camel case which seems it convinced most detractors (+1 with myself).

"Exclude from UI" is probably more accurate than "Internal" for the schema docs.

Agree & agree. I will do the change as soon as I can.

Done that myself 😄

It is a surprising move, but thanks you.

However, but there are still mentions of "internal" in descriptions. "No UI" is already descriptive enough and I am afraid "internal" will add confusion.

OK great, I will commit it.

This is a nice improvement for folks configuring UI/page builders!

♥️

Committed 9e51e1e and pushed to 11.x. Thanks!

There's no change record yet 😅

thanks Wim :)

Needs work for the change record.

That will be an awesome improvement, thanks to you all.

Here's the change record draft i created: https://www.drupal.org/node/3542594

CR reads fine to me. Can't wait to add this to some of my ui_suite_uswds components. I didn't mark fixed as didn't want to jump the gun.

Change record should explain a bit where that is used (not used in core yet) administrative uis of drupal canvas and display builder for examples.

Also SDC do not stand for 'Structured Data Component (SDC)', so some work to the change record wouldn't be bad

CR changes: Fixed SDC acronym definition, changed target audience to include Themers, included reference page builders and a note that it's each page builder choice to decide if they respect this metadata.

I'm still not 100% happy with the CR, but RTBC to put this in front of nod_ and pdureau eyes.

It's not just good, it's good enough!

Thanks nod_

Adding to release highlights.