Expose Twig function for rendering a pattern with settings support

Created on 10 May 2023, over 1 year ago
Updated 1 November 2023, about 1 year ago

Problem/Motivation

UI Patterns exposes a twig function (pattern) which allows you to render a pattern directly in a template. This is super handy when theming, however it does not support passing settings to the pattern so you're stuck with whatever the defaults for the variant are.

Proposed resolution

Create a new twig function called "pattern_with_settings" which does the exact same thing as the default "pattern" function, but supports settings.

This would have the same arguments as the UI Patterns function plus settings: pattern_with_settings($id, $fields, $variant, $settings)

Feature request
Status

Closed: outdated

Version

2.0

Component

Code

Created by

🇨🇦Canada nickdjm

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @nickdjm
  • 🇨🇦Canada nickdjm

    Here is a patch with the functionality added.

  • 🇦🇺Australia NicolasH

    Yes please, this makes perfect sense. I wouldn't use UI Patterns at all if it wouldn't have the option to use it in render arrays and twig files apart from the UI options...as this allows to use the same patterns in more complex scenarios as well and still keeps it consistent.

    I actually thought this was already built in here and was looking for documentation on it.

    I've tested the patch on only one scenario for now and it works well. Will update if I find anything with more scenarios.

  • Status changed to Postponed about 1 year ago
  • 🇫🇷France pdureau Paris

    The current pattern() function already allow to inject a mix of fields ("slots") and settings ("props") in its second parameter :

          new TwigFunction('pattern', [
            $this,
            'renderPattern',
          ]),
        ];
      }
    
      public function renderPattern($id, array $fields = [], $variant = "") {
        return [
          '#type' => 'pattern',
          '#id' => $id,
          '#fields' => $fields,
          '#variant' => $variant,
        ];
      }

    We don't need to use the specific #settings property because at the end the #fields and #settings are flattened and merged before being rendered with the template : https://git.drupalcode.org/project/ui_patterns/-/blob/8.x-1.x/src/Elemen...

    For example, in https://git.drupalcode.org/project/ui_suite_dsfr/-/blob/1.0.x/templates/...

    pattern('modal', {
      modal_id: modal_id,
      title: modal_title,
      ...
    })

    Where modal_id is a setting ("prop") and title is a field ("slot") : https://git.drupalcode.org/project/ui_suite_dsfr/-/blob/1.0.x/templates/...

    Are you OK with that?

  • Status changed to Closed: outdated about 1 year ago
  • 🇫🇷France pdureau Paris

    No answer. Closed.

  • 🇦🇺Australia NicolasH

    Right, I see, thanks for that. I stumbled across this by accident myself when putting in some settings like any other field and it just worked.

    My only comment would be that the twig function reads a bit nicer with the settings in their own array, especially is there are a large number of fields and settings. It also makes more sense when using it both in the UI as well as twig.

    Also, I've been using a separate #settings array key in render arrays and it works fine. I can't remember whether I just tried it out or whether it's somewhere in the documentation. After reading your comment I tried to just move them into the #fields array and yes, works just the same. Again, the readability will have me probably leaving them separate.

    $build[['register_link'] = [
          '#type' => 'pattern',
          '#id' => 'dialog_button',
          '#fields' => [
            'url' => $create_account_url,
            'text' => t('No account? Sign up'),
          ],
          '#settings' => [
            'link_type' => 'button_primary',
            'size' => 'm',
            'icon_classes' => 'fa-solid fa-user-plus',
          ],
        ];
    
Production build 0.71.5 2024