🇫🇷France @pdureau

pdureau → created an issue.

@karanpagare thanks for your work. Can you do a MR?

Also, why all the Context Switchers are in the "Converted" group? why not in the main group or a specific "Context switching" group?

Mikael proposes to remove the "Converted" group because it seems users don't care about this.

And introduce a group by Context, so

• Component
• Block
• Wysiwyg
• Entity
  • [Entity] Link
  • [Entity] -> Field
• Field
  • [Field] Formatter
  • [Field] Label

pdureau → created an issue. See original summary → .

thanks

Should there be a reverse relationship too? An example of this would be to limit people to put accordion_items only into accordion_group components.

Indeed Mike. Let's not forget this.

Thanks you @laurii to restart this thread and for your proposal. The minimum / maximum properties are interesting.

For this proposal as for the previous, I am mainly hoping component authors will not rely on those indications to allow themselves to do weaker or dirtier component templating. They have to understand those indications will not always be strictly enforced.

To complement, this, here is a study of what the other technologies do. Maybe we can find there something which will validate one of our existing proposals or a new idea to explore.

Oracle Content Management

For any layout slot, you can specify certain restrictions on the components allowed in the slot.

If you restrict components in a slot, any user dragging a component that is not allowed will see a warning message and will not be able to add or move a component to that slot.

data-allowed-items='["<id>:", "<type>, "<type>:<id>",...]'
data-disallowed-items='["<id>":"<type>", "<type>:<id>",...]

Example:

<div id="slot101" 
     class="scs-slot" 
     data-allowed-items='["scs-app","scs-title"]' 
     data-disallowed-items="['File List', 'scs-map']">
</div>

https://docs.oracle.com/en/cloud/paas/content-cloud/creating-experiences...

Analysis:

allowed and disallowed look like supports and conflicts from Lauriii's proposal. We can put as values component IDs or applicative blocks ID ( something we want to avoid in SDC because of the separation of concerns).

Vuejs's defineSlots()

The purpose of the macro is to improve Developer Experience (DX) by adding suggestions and type validation directly in your code editor/IDE. defineSlots accepts a literal type as its parameter, where each property represents the name of a slot, and the value is a function defining the props the slot accepts.

Suppose in your AppProducts component you want to provide product information and define their types.

interface Product {
id: number;
name: string;
price: number;
}

const slots = defineSlots<{
default(props: {
highlight: { // You can use literal types
name: string;
price: number;
};
}): void;
list(props: {
products: Product[];
}): void;
}>();

https://vuejs.org/api/sfc-script-setup#defineslots
https://escuelavue.es/en/devtips/typescript-vue-scoped-slots-defineslots

Analysis:

This one is complex and I am not sure my understanding is 100% OK. We are restricting slots content according to the schema of the injected component. For example, we accept in a menu component's items slot only components with a certain prop ID and/or a certain prop schema.

What else?

Does someone want to share other examples, from UI components tech or display building tools?

Also, why all the Context Switchers are in the "Converted" group? why not in the main group or a specific "Context switching" group?

First proposal done. Now, let's collect feedbacks.

Before:

After:

It make the context tracking easier from a source to another:

a

Checked with Hugo. No bugs found. It is only an UX issue, so let's go.

pdureau → created an issue.

Currently rebasing.

Also, what about stories? We merge?

Currently rebasing. Let's merge

Hi @lus just a side note while waiting for the expected answer: {% set tags = tags and tags is not sequence ? [tags] : tags %} is better/safer than {% set tags = tags is sequence ? tags : [tags] %}

but, be careful, tokens can return renderables, yes they are like UFOs right? so string may not be accurate.
let’s check that, maybe i am wrong

Very interesting! If tokens can returns renderables, that mean the current list of prop types is wrong:

  prop_types: ['slot', 'string', 'url'],

https://git.drupalcode.org/project/ui_patterns/-/blob/2.0.x/src/Plugin/U...

Looks good to me. I will ask another maintainer to review.

But before, little cspells fix expected: https://git.drupalcode.org/project/ui_patterns/-/jobs/5325802

"String and token" may be too long. But I don't have a better proposal.

Hi Hugo,

Some of UI Patterns sources plugins are not really data sources but context switchers:

It seems you are:

1. Editing a "Component per item" formatter on a reference field (so, you start from the field context)
2. Picking the same field in "Data from a field" (so you stay at the same field context, but you lost the "per item").
3. And then you pick a field formatter

Don't you have a the choice to pick the same formatter directly at step2?

It looks like (without being identical) the yesterday situation when you were:

1. Editing a "Component per item" formatter on a reference field (so, you start from the field context)
2. Picking a "Referenced entities" source (so you move "up" to the content entity context)
3. And then picking the same field "Data from a field"

Maybe our UX is confusing. So I am proposing to:

1. Add a label with the current context at the beginning of the component form

Only the most precise available context, as provided by to the configurable plugin:

• Component field formatter: [Field]
• Component per item field formatter: [Field item]
• Layout: [Entity] or nothing (or [Page] or [Content] when they will be added to UI Patterns 2]
• Block: [Entity] or nothing (or [Page] or [Content] when they will be added to UI Patterns 2]

I skip Views plugins because there is no context switching (yet) here.

1. Prefix the context sensitive source with the expected context

2. Rename our context switchers to make the switch more explicit

With an Unicode arrow in the label, for example:

Wrapping up

So, for the today example, you will have this:

1. "Component per item" [Field item]
2. "[Content] ➜ [Field]"
3. The selected field formatter

To make it obvious we went from "Field item" to "Field".

For yesterday example:

1. "Component per item" [Field item]
2. [Content] ➜ Referenced [Content]
3. [Content] ➜ [Field]

Is it clearer with this labelling? I am open to any suggestions or wanring ;)

hi Goz,

I use "Token" source usually to achieve that, without putting a token as value of course. Maybe we can rename "Token" source as "String" knowing there is a token processor running on its value?

Hi Mikael, I know you are busy but it is part of your initial scope. Don't hesitate to assign to Christian if necessary.

Tell about the source tree and the #ui_patterns render property

Moved to 2.0.5

Let's merge 🐛 [2.0.x] Keep patterns directory structure when converting them to components Active first

Great find! We can merge this ASAP.

However, would it be possible to not hardcode /templates/patterns/

      $component_path = str_replace('/templates/patterns/', '/components/', $legacy_definition['base path']);

UI Patterns 1.x components can be found in other places.

I am not very comfortable with this proposal. Not because of Marc's work. It seems he did a great job. But because of some weird stuff on Drupal Core side.

I will take the time to review it properly.

Thanks. Can you create a MR?

Also, you are using Drupal\Core\Hook\Attribute\Hook annotation. Does that mean we need to update our Drupal Core requirement (currently: ^9 || ^10 || ^11) ?

Up :)

Don't hesitate to ask for help if needed.

I am ok with the proposal. What about you Mikael?

Great plan!

Commit once pipeline is good.

pdureau → created an issue.

Hi Rajab,

Thanks for the MR, it is very exciting.

2 feedbacks:

• Do we really need dependency to the contrib token module? Core Token API is not enough?
• Can you add an automatic test with aria-label="[node:field_link:title] about [node:title]" target="_parent"?

We have just merged this to Drupal Core: https://git.drupalcode.org/project/drupal/-/commit/1cf4278

    // Handle children as slots.
    $children = Element::children($element, TRUE);
    foreach ($children as $key) {
      $element['#slots'][$key] = $element[$key];
      unset($element[$key]);
    }

It will be released in Drupal 11.2

Is it compatible?

So, your proposal is:

• On the Component selector and the Library, show only the replaced component ("BaseCard") with its ID
• But, once selected, show the form of the replacement ("SubCard")

What happen if a component is replaced by many others ("SubCard1" and "SubCard2") ? What happen if a replacement is replaced ("SubSubCard") ? I guess we need to follow the SDC rendering logic.

Update slots picture

@alex.skypnyk

The original explanation was streamlined for documentation use.

Thanks. The introduction was kept from the early days of the documentation.

I have been consulting several developers who never used SDC before and they all were confused by this image.

This component is the Card from DaisyUI 4: https://v4.daisyui.com/components/card/ The slots labels and machine names (like title) are taken from the upstream documentation.

I agree the props are confusing wit the empty object ({}). I will replace them by {...} to show something is expected here.

Here is the source file for the image: https://docs.google.com/presentation/d/1WJZ0QpezowNqscGu3MpbneYSk1bXsR8t...

g4mbini → credited pdureau → .

Following @goz ticket ✨ Provide default value option Active , let's also consider a default value mechanism.

Like the other plugins, it will transform from the same type to the same type;

• from attributes to attributes: any attribute source can be a filter, the attributes are merged at each steps with something like AttributeHelper::mergeCollections
• from string to string: trim, upper, replace...
• from boolean to boolean: invert...
• from * to *: default: any source for the same prop type (including slots). So, if the value is empty (and false? let's discuss) we pick the value of the selected and configured source. default is not necessary the last plugin, we can continue chaining others

Let's discuss about that in ✨ Chain prop sources Active

I may add something about that in the doc.

Too late for 2.0.X

There is a PHPMD issue

Mikael forgot to assign the ticket back

It will be possible as a side effect of the new Content context and its related sources plugins for slots: ✨ Add content source Active

ok, i change a little thing and i merge

Oops, it was not something to merge yet. Merge train cancelled.

genklegni

OK for me. I will commit soon.