[2.0.x] Roadmap

Hello Christian,

So many interesting stuff here. So, I will freely brainstorm, just throwing stuff around, without being afraid of saying crap.

1. Make UI Patterns independent of Drupal
From my Point of view, UI Patterns/Templates should be Drupal independent so that Patterns/Templates can be used in all TWIG based CMS/Frameworks. UI Patterns Core could be a composer package with core Logic and a base set of TWIG Functions/Filter.

So, we would need to reconsider the parts which are Drupal related like the libraries definition:

  libraries:
    - MY_MODULE/module_library_one
    - MY_MODULE/module_library_two
    - pattern_library_one:
       css:
         component:
           css/my_component.css: {}
           http://example.com/external.min.css: { type: external, minified: true }
    - pattern_library_two:
       js:
         js/library_two.js: {}
       dependencies:
         - core/jquery

Or the preview using render arrays:

  fields:
    image:
      type: "render"
      label: "Image"
      preview:
        - theme: "image"
          uri: "https://.."
          alt: "© 2017 John Smith photography"

Or, the Twig Print Node which is overriden by Drupal:

    if ($node instanceof PrintNode) {
      $class = get_class($node);
      $line = $node->getTemplateLine();
      return new $class(
        new FunctionExpression('render_var', new Node([$node->getNode('expr')]), $line),
        $line
      );
    }

By the way, Twig Print Nodes are the double curly braces in templates:

{{ ... expression ... }}

This code snippet is where the magic happens. This is the perfect slot system in my opinion. You can inject anything here:

• a string or any renderable scalar
• renderable object like Attributes
• a delcrative render array not yet processed
• an array (list) of renderables

And the template will call the renderer again merging the renderer a the template engine into a single loop which is exploring both the fuil render tree and the templates nodes, with a render flow only going forward:

When I heard discussion about slots in templating languages, I never see this mechanism, but those 2 proposals which look inferior to me:

• Premature rendering the slot content as markup before sending it to the template, which is slow, and not compatible with markup escaping security feature.
• Using blocks tags, which is creating dependencies between component templates, and reversing the flow. I remember this is the way Core SDC was considering.

A big part of what make UI Patterns great is the Drupal layer we are building it on. Sure, the Render API is old, ugly and kind of broken, but this idea of nested declarative renderable must be kept if UI Patterns 2.x is built and available outside of Drupal.

How can we achieve that? Extracting the render API (or cretaing a smiliar API) outside of Drupal (that sounds crazy, but I told you i was freely brainstorming)?

2. New UI Patterns YAML Schema Version
I think fields/props is misleading. Also, UI Patterns Settings is a mix of UI and configuration. We could provide an optional backward compatible Schema version. It could look like: (If no schema provided, the old logic should still work)

It seems we are agreeing on "slots" and "props" since September, considering our fields must be slots, and our setting must be props.

Many of us are successfully moving our non-slots fields to props. Example in UI Suite DSFR: #3341139: [beta1] ⚠️ Fix compatibility with layout builder One of the last pain point is the management of menu and breadcrumbs structures which are props but stay as fields until #3345071: Add links setting type is done.

I agree the strong coupling between props and UI must be removed if we merge it into UI Patterns.

Your proposal looks great! Can we add JSON schema in the mix? SDC is using JSON schema for the props and it sounds like a good idea, so this:

  settings:
    image_position:
      type: "checkbox"
      label: "Image reverse position"
      default: true
    aria_label:
      type: "textfield"
      label: "Aria label"

Could become:

props:
   image_position:
      label: "Image reverse position"
      schema: 
         type: boolean
         default: true
      widget:
         type: checkbox
         config: {}
    aria_label:
      label: "Aria label"
      schema:
         type: string
      widget:
        type: "textfield"

By the way, I am very pleased your example doesn't have typing for slots :)

But I didn't' understand the data: {classes: []} stuff. What is it?

3. Replacements for include/embed/extends.
Right now, we have multiple ways to include patterns. Either the include/embed/extend or the pattern function.
If patterns included by include/embed the TWIG Template is not prepared with UI Patterns variables like settings or data.
Templates needs code to prepare default values if the pattern is loaded by include/embed.

This is a 2 levels issue IMHO.

First, we need to discourage call from patterns to patterns. block, embed, extends, from, include, import, sandbox & use Twig filters must be considered as bad practice. block, include, parent & source Twig functions too.

The recommended way of nesting component is to define them outside the template and to inject them into slots. Hardcoding must be avoided as much as possible to keep the template rock solid and flexible.

Second, when hardcoding is unavoidable (for example, legal expectations for theDSFR consent banner or technical constraint for the Bootstrap navbar), the only recommended function must be pattern().

Because:

• No hardcoding reference to a template file. We are targeting a component.
• As you said, patterns must be prepared and I guess this function do the job.
• It is safer because it never share the template context which the child component.
• Comfortable: one of the parameter is variant selection

5. "Everything" in core should mapped with UI Patterns without ecosystem modules.

This is a controversial take, and I don't have strong opinion about it.

By the way, which way are you suggesting:

• Keeping the ecosystem module, but as sub-modules of UI Patterns?
• Merging everything into a single powerful module. If you don't use the plugins, they are not loaded anyway?

What will be the compatibility breaking strategy ? I think we need to start with that.

Here is my proposal.

We don't break the themer experience:

• We don't break the templates because we introduce strictly no changes about the templates content
• We don't break the definition file. There will be a new format, with renaming and some change, but we offer a "legacy discovery" layer to make the old definition files still working with new definitions

Breaking the themes currently using UI Patterns (the "implementations") is a no-go. We need to be very strict about that.

We freely break the back dev experience :

• New slicker API
• New features not 100% compatible with contrib (ex: the subset of UI Patterns Settings)
• Removal and cleaning of features

Breaking the modules currently using UI Patterns (the "ecosystem") is possible. This is the purpose of a major release.

We kindly break the site builder experience :

• Hook updates
• Explicit warnings
• Fallbacks

Let's be careful.

Hello Nedjo,

Thanks for your message. We know about your work and we are impressed by it. We will be pleased of welcoming you in the UI Patterns 2.x team.

Here is the plan for UI Patterns 2.x

We want to rebuild UI Patterns around SDC (Single Directory Component), which was shipped with Drupal 10.1

SDC provides:

• An overall cleaner implementation
• A clever component inheritance and overriding mechanism
• Props as pure data types (described with JSON schema) insetad of the current UI Patterns Settings which mix data types and form widgets
• A similar asset library management
• Twig templates fully compatible with UI Patterns ones
• ...

SDC lacks:

• components variants
• previews declaration and library pages
• props types "aliases" but there is an SDC issue for that: https://www.drupal.org/project/drupal/issues/3352063 (maybe UI Patterns can offer a reference repo for common prop types)
• site building with configurable plugins, but some works has begun: https://git.drupalcode.org/project/sdc_display

SDC also lacks:

• a Twig function to embed children components into component templates instead of calling the templates, like paterns()
• ability to target a template from another codebase (@use property, some users are heavily using it)
• preprocess hooks but we want to get rid of them

We are still not decided about the way we are extending SDC:

• By introducing a plugin system to SDC, so UI Patterns variant will be a SDC plugin, UI Patterns previews will be a SDC plugin....
• By just extending the PHP class (OO inheritance), the simple way
• By using third_party_settings

Our strategy stay the same:

• We don't break the themer experience: same templates and legacy discovery
• We can break the back dev experience
• We can also break the site builder experience, but gently: hook updates, notices, fallbacks…

See: https://www.drupal.org/project/ui_patterns/issues/3344518#comment-14974878

So, to not break current themes, we will also need:

• A legacy discovery to build our extended SDC plugins from the current UI Patterns YAML format
• Legacy "pattern" render element & "pattern" twig function

We have already started to work on it and it is going well.

I will contact you on MP.

We released alpha3. 2.0.0 is coming in 3 months, this roadmap is outdated.