SDC formatter - compatibility with UI patterns module

Some information about UI Patterns.

ui-patterns:// notation is resolved before being sent to SDC as things must be done with JSON schema references. SDC is receiving the non UI Patterns schema and UI Patterns is not required for the next steps.

So ui-patterns:// references are not vendor locking or weird specific UI Patterns mechanisms, there are only shortcuts to avoid writing heavy prop definitions and are totally legit and respectful.

In other words, custom_field is receiving the resolved JSON schemas without any trace of UI Patterns in them.

For example, ui-patterns://identifier is resolved as this JSON schema before being managed by SDC:

type: string
pattern:  '(?:--|-?[A-Za-z_\x{00A0}-\x{10FFFF}])[A-Za-z0-9-_\x{00A0}-\x{10FFFF}\.]*']'

So it is just a string with constraints, you can pick a way:

• propose a textfield input with the pattern value in a pattern HTML attribute. This is a generic solution for any JSON schema string with pattern property.
• propose just a textfield, with the risk of sending some not compliant string, but it is only UI logic here so a acceptable in my opinion.
• just skip the prop. It is OK to ignore the props with schemas you are not handling yet. SDC is not business logic, it is only UI modeling, the UI components must be usable without all props covered, we simply lose a part of the UI logic and rely on default values.

Here is the documentation of the "Explicit prop typing": https://project.pages.drupalcode.org/ui_patterns/2-authors/0-authoring-a...

The schema is resolved before the SDC plugins are instantiated. However, for this resolution to happen, you need both:

• a schema resolver. It is a generic mechanism, you need only one and it will be compatible with all stream wrapper. UI Patterns and Canvas both already provides one, and Core will soon provides one.
• the specific stream wrapper provider (UI Patterns for ui-patterns://, Canvas for json-schema-definitions://, Core 11.3 for module:// and theme://...)

If something is missing, the reference will not be solved. That's why it is important to move all this to Core. The sooner UI Patterns and Canvas drop their own stream wrappers (and schema resolvers...), the better.

A proposal for custom_field in this comment: https://www.drupal.org/project/ui_patterns/issues/3585523#comment-16555588

Hello @apmsooner,

First, thank you for jumping on this feature request so quickly, it is much appreciated. I finally had an opportunity to test the MR, and it goes a long way towards addressing my issues.

============================

Background

To be clear about what I am trying to achieve.

I have a multi-value custom_field (pane_title, pane_body) with unlimited cardinality. I wish to render the field in an accordion component (from ui_suite_bootstrap). I am using UI Patterns and Layout Builder.

The accordion component has a single slot to populate with accordion_items, which has a slot for the title and a slot for the content. I would like to map pane_title to accordion_item:title and pane_body to accordion_item:content.

===================

Test 1

I start by adding a UI Pattern component to layout builder and selecting accordion.

In the content slot, I choose Source: [Entity] -> [Field], and choose my custom_field.

In Formatter, I choose SDC (Single Directory Component)

In Component, I choose (Accordion Item)

In Slots:Title, I choose pane_title, Format type: Plain text, Label display: Hidden.
In Slots:Content, I choose pane_body, Format type: Plain text, Label display: Hidden.

After saving I view the rendered node. I see the pane_title in the accordion item title only (this is an improvement) and I see pane_body in the accordion content only (again, big improvement).

However, the field labels are still rendering. Still, this is a significant improvement.

================

Test 2

As I was attempting different configurations, one thing I want to draw your attention to is that UI Patterns has a feature whereby for multi-value fields, there is an option to choose a "Component per item". I don't know if it would make your life easier or more difficult to support this, but from my perspective, it might be easier. However, this currently does not work close to how I think it should.

If I choose Component per item (instead of SDC) as the Formatter, choose accordion_item, then attempt to configure the pane_title / pane_body in such a way as to hide pane_body in the accordion_item:title, and hide pane_title in accordion_item:content, the result is both pane_title and pane_body are rendered in both slots, completely ignoring my configuration.

================

The SDC formatter is definitely the closer of the two options I tested, but both seem to have challenges adhering to my configuration (specifically hiding the sub-field labels).