[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 defined outside of Drupal.

How can we achieve that? Extracting the render 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: 🐛 [beta1] ⚠️ Fix compatibility with layout builder Fixed One of the last pain point is the management of menu and breadcrumbs structures which are props but stay as fields until ✨ Add links setting type Needs review is done.

I agree the string 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, 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 string 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?

Hi,

Thanks both for your thoughts.

Adopt semantic versioning

Yes, automatic with new branch.

Rebuild on top of Drupal Core SDC

Depending of the progression of this core initiative, we may want to do that in 2.1.x or 3.0.x, to not block UI Patterns enhancements.

Integrate a subset of ui_patterns_settings

Yes! I want to get rid of ✨ [2.0.x] UI Patterns Library: support UI Patterns Settings Fixed

Remove of DS & Field Groups sub-modules

Issues created:
- 📌 [2.0.x] Move ui_patterns_ds into a dedicated project Fixed
- 📌 [2.0.x] Move ui_patterns_field_group into a dedicated project Fixed

Move YAML discovery from library module to main module

Issue created: 📌 [2.0.x] Move YAML discovery from ui_patterns_library to ui_patterns Fixed

I don't know if this has to wait for 2.0.x or can be done in 8.x-1.x?

Remove unused or rarely used features or properties

Agreed but not urgent.

Make UI Patterns independent of Drupal

Wow, this would be huge but not urgent, I think that's in the direction of a lot of Pierre's issue about removing drupalism and PHP.

But I think not all drupalism will be able to be removed.

New UI Patterns YAML Schema Version

No opinion. It may join the point "Rebuild on top of Drupal Core SDC"?

Replacements for include/embed/extends

Same as Pierre's response.

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

Agreed. Ecosystem reorganization issues had been created, if it is the idea behind this sentence.

Videos.

Why not :)

A new platform to share components.

???

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.

Hi,

I am ok with this proposal of upgrade strategy.

Hi,

sounds good!

Starting in 2020, I developed the Component Schema module → as a fresh start on the problem set addressed by UI Patterns, UI Patterns Settings and related modules. I did so after working extensively with UI Patterns, UI Patterns Settings, and other similar efforts. I drew a lot on the work done in this module set. I found UI Patterns Settings in particular to be an innovative layer on top of UI Patterns. However, in working with the module set, I kept hitting basic limitations that seemed to me to derive from basic architectural decisions. I decided there was a need to start fresh to meet several key principles.

• Schema-first.
• Typed data built in.
• Inheritance.
• Dedicated classes.

I modelled Component Schema on the configuration schema API from Drupal core, in many cases directly leveraging that API. As a demonstration of how the module works, I coded up a Bulma Components → module that provides a set of components based on the Bulma CSS framework. Using Component Schema, a module or theme may provide a component schema in a .yml file in a component/schema directory, directly parallel to the way modules provide configuration schemas in config/schema .yml files. The Component Schema module itself provides all the basic types that should cover the vast majority of cases. Bulma Components provides a set of reusable types such as bulma_alignment in its own *.yml file. See the Component Schema → documentation for more detail.

I mention this work now because, as a considerable effort is considered towards reworking UI Patterns, there may be an opportunity to leverage the significant work that has already been completed in Component Schema. Specifically, Component Schema could be introduced as a dependency for UI Patterns 2.x, allowing the new branch to take full advantage of the foundational work already complete in Component Schema and freeing up new work to focus explicitly on UI rather than data modelling. As an initial pointer, a sub-module integrating with UI Patterns 1.x, Component Schema UI Patterns, provides pointers on how component schema could provide the data needed for the UI integration in UI Patterns and UI Patterns Settings.

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 and overrides mechanism
• Props as pure data types (described with JSOn schema) isnetad 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 ✨ [PP-1] Allow schema references in Single Directory Component prop schemas Postponed (maybe UI Patterns can offer a reference repo for common prop types)
• a Twig function to embed children components into component templates instead of calling the templates, like paterns()
• site building with configurable plugins, but some works has begun: https://git.drupalcode.org/project/sdc_display

SDC also lacks:

• 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

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 🌱 [2.0.x] Roadmap Active

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.

@pdureau sounds good and makes sense. I'm in any case moving on from Drupal and have already passed on maintainership of Component Schema as well as almost all my other modules. All the best with this initiative.

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