Allow SDCs to be marked to be excluded from UI

Something that came up before is how this relates to ✨ Allow SDCs to specify what components are allowed in its respective slots Active . I actually don't think this is exactly the same as what's being worked on there. What we want to do here is prevent exposing the component to the UI at all. The difference is that this is the component indicating it should be hidden from the UI, vs ✨ Allow SDCs to specify what components are allowed in its respective slots Active where it might be possible for the canvas to indicate what components it can accept.

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

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

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.

It seems that no_ui would be most consistent with the rest of Drupal which is why I proposed that. I'm not against has_ui but between no_ui and has_ui, they feel equally clear to me with no_ui being more consistent. I'll let @pdureau to make the final call here. 😊

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 😉

I would imagine the default values would be these:

• status=stable
• no_ui=false or has_ui=true

I believe that if component doesn't provide any of these props, display builders should happily use the component.

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? 😅 Again, I'm fine with anything but just pointing it out after realizing this.

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.

In the other scenarios where we're using no_ui, other properties are using snake_case too. It looks like all of the SDC properties are currently camelCase so we'd be introducing the first deviation from that. I think we should avoid that since we can. But again, no strong opinions here, just trying to help us close this as quickly as possible with something reasonable 😅

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 removed 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? 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

Internal is semantically different from hiding something from the UI. The idea of noUi is that you could provide SDCs that are API like the image component being built into Experience Builder, but it may not make sense to expose them to the UI.

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) but we do want that to be available in the interface to put on the page? 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 retractors (+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.

Fixed it within Gitlab 😇

OK great, I will commit it.

+1, this is looking good! Glad we were able to resolve this quickly. This is a nice improvement for folks configuring UI/page builders!

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

♥️

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

nod_ → closed merge request !12723