[2.0.x] Update ui_patterns_library and rethink patterns previews

Hello Duael,

Thanks for this detailed proposal.

1. previews variations

100% agree with this:

We need many previews of a pattern

• The current situation of adding the previews inside the field definition is limiting us to a single preview per pattern
• So, we need to add a new section in the pattern definition with as many named previews as we need
• We are not removing the existing preview property from the field definition

Some feedbacks:

• What are we doing with the existing field definition preview properties? Maybe we should reserve the keyword "default" for one of the previews which would consist of the agglomeration of the previews of each fields & settings
• It would be nice to create a ComponentPreviewDefinition class like ComponentFieldDefinition and ComponentVariantDefinition, and make it compatible with Drupal\ui_examples\Definition\ExampleDefinition for consistency in the UI Suite ecosystem.

2. previews declarations

We could take advantage of the unused types of the fields to define what's expected and react accordingly.

This is the part I am the least comfortable of, using the field types. Because, fields are slots and slots are not typed. I would prefer to remove the type property than doing magic on it. And are we sure "markup" or "image" keyword are not conflicting with existing or future usage? how many types will become keywords like that in the future?

I understand the big issue is the developer experience related to the Drupal Render API. It drives me nut too. I was so desperate that i worked on this issue: 🌱 Improve DX with render alias Closed: works as designed

Because the existing render elements are not friendly, it may be time to create new render elements, which will be easy to add in UI Patterns previews and be proper render element usable elsewhere. Examples:

I know it is a bold proposal, but at least we are using the existing render API and we can still mix with teh existing render arrays.

Note/warning: each fields could contain multiple elements so we'll need to find a way to handle differently a render array that a render of values that needs to be processed.

Is it related to ✨ Make the Twig loops safer Postponed ?

3. previews usage

First of all, we should allow someone to override preview fields in this call so they can have the more appropriate values for their preview case. Then, we should allow to use the same syntax as seen in the previous point to override these fields. Finally, we might add some extra parameter to allow selecting a specific preview in all available previews declared according to the first point of this plan. Obviously, all these should be usable at the same time

I love that. 100% agreeing I would not change a word :)

As a bonus, it would be really great to have a way to ask for a random preview in the available ones (think about the grid/slideshow pattern in which you'd like to have a few variety).

Indeed. I haven't tried but it seems Wingsuit (which is extending UI Patterns definitions) is doing something this using Faker JS library: https://wingsuit-designsystem.github.io/components/wingsuit/

preview:
      faker:
        token: "{{ name.lastName }} {{ name.firstName }}

We can ask Christian about feedbacks.

Hi,

Thanks both for your thoughts about that.

1. previews variations

Ok

Why not introduce the previews rework in UI Patterns 2.0 so no backward compatibility to maintain?

About Pierre's feedback:
- ComponentPreviewDefinition: Not sure about the need to make it compatible with ui_examples, would this make ui_examples a dependency of UI Patterns or the opposite?
-

those preview must be variant agnostic, in order to loop, in the pattern library, first on each variant ; then, for each variant, on each preview. In order to have a full rendering.

: I see the will for patterns with a lot of variants to have to avoid to declare a lot of previews but there are sometimes patterns with variants where options are useful for some variants in particular. So I would say if a preview do not have a "variant" declared we loop on all, but if the variant is specified no loop on all variants.

2. previews declarations

This should be a dedicated issue and improved in a second time.

Also this will go against the will to use the fields type as documentation. See screenshot

About Pierre's feedback:
10000% agree, I prepared my feedback before reading Pierre's one! :)

3. previews usage

Ok.

A little bit skeptical about the random preview

Why not introduce the previews rework in UI Patterns 2.0 so no backward compatibility to maintain?

In my previous comment I forgot the screenshot.

As far as I remember there was no wide agreement on using fields types like this. That slide was quickly presented to everyone but I don't recall we had the time to think about it and argue for or against. Is there an issue where the typing is discussed?

As far as I remember there was no wide agreement on using fields types like this. That slide was quickly presented to everyone but I don't recall we had the time to think about it and argue for or against. Is there an issue where the typing is discussed?

Indeed, this slide was just an open question during a monthly meeting. Nothing was deeply discussed, nothing was decided.

This is an other subject, not directly related to the current issue. Today, the field typings of our UI Patterns implementations are a mess. Just random keywords put here by the developers, without a consistent nomenclature. I wanted to set a meeting to decide a set of keywords, to share as good practice, for documentation purpose.

Ongoing work in other issues.