Figure out a solution for rendering lists

This kind of code must be avoided because it is inspecting the structure of a render array in a slot:

{% for key, item in message|filter((item, key) => key|first != '#') %}

Slots content must not be inspected. They are opaque. Slots are not always render arrays.

This was found in two components alert and collection_item.

Proposed resolution for alert

This one is easy to fix because there is no need of such inspection if we follow the upstream documentation instead of managing the complexity of statys-message.html?tiwg inside the component template.

Let's keep the component template simple:

<div{{ attributes.addClass('usa-alert').setAttribute('role', role) }}>
  <div class="usa-alert__body">
    {% if heading %}
      <h4 class="usa-alert__heading">{{ heading }}</h4>
    {% endif %}
    {% if message %}
      <div class="usa-alert__text">
        {{ message }}
      </div>
    {% endif %}
  </div>
</div>

And move the loop in the presenter template:

  {% for type, messages in message_list %}
    {% for message in messages %}
      {{ pattern('alert', {
        'variant': type == 'status' ? 'info' : type,
        'message': messages,
        'attributes': attributes.addClass('margin-y-2')
      }) }}
    {% endfor %}
  {% endfor %}

By doing that, we are more compliant with upstream USWDS and we are avoiding 2 other risks: the use of merge filter and the alteration messages variable from inside a loop.

Proposed resolution for collection_item

This component is only called from search-result.html.twig which is sending a list of plain strings, so why inspecting the renderable?

Maybe because you want to be extra careful while waiting for ✨ Make the Twig loops safer Postponed , but I don't believe introducing this complexity will help.

I can obviously do this logic in the main twig file before calling the pattern but then I feel I can't use the pattern from the UI.

Hmmm.. Indeed we need to check that. Can you tell me more?

I have opened a MR: https://git.drupalcode.org/project/ui_suite_uswds/-/merge_requests/59

Let's discuss

So removing ((meta_item, key) => key|first != '#') this kind of stuff means (least I can't find a way) that patterns can be used outside twig. So if I tried to use in layout builder, field group, or views and I assign a Drupal list field to this slot it won't work.

So if I tried to use in layout builder, field group, or views and I assign a Drupal list field to this slot it won't work.

I guess you have this issue with collection_item because my proposal about alert looks compatible with site building.

Proposal: instead of doing this stuff with the filter() filter:
{% for key, meta_item in meta_items_list|filter((meta_item, key) => key|first != '#') -%}

We can do something like that:

{% set meta_items_list = (meta_items_list is iterable and (meta_items_list|keys[0] == 0)) ? meta_items_list : [meta_items_list] %} 
{% for meta_item in meta_items_list %}

So, when Twig will be ready, it will be easy to switch to the expected mechanism:

{% set meta_items_list = (meta_items_list is sequence) ? meta_items_list : [meta_items_list] %} 
{% for meta_item in meta_items_list %}

Tested the MR and the solution in #6 but unfortunately causes infinite loops or empty tags.

I will test on my side

New commit. Is it better?

Cleared cached and the alert message isn't appearing.

OOps, there was a typo in templates/base/misc/status-messages.html.twig

     {% for message in messages %}
       {{ pattern('alert', {
         'variant': type == 'status' ? 'info' : type,
-        'message': messages,
+        'message': message,
         'attributes': attributes.addClass('margin-y-2')
       }) }}
     {% endfor %}

I will push the tiny fix as soon as i can.

Pushed. Not fully tested. I hope it is OK.

FYI, Florent is working on ✨ Make the Twig loops safer Postponed for UI Patterns 1.x

Once done, my current proposal:

      {% set is_list = meta_items_list is iterable and meta_items_list|keys|first == 0 %}
      {% set is_children = meta_items_list is iterable and meta_items_list|keys|first|first != "#" %}
      {% set meta_items_list = is_list or is_children ? meta_items_list : [meta_items_list] %}
      {% for meta_item in meta_items_list -%}

Can be replaced by:

      {% set meta_items_list = meta_items_list is sequence ? meta_items_list : [meta_items_list] %}
      {% for meta_item in meta_items_list -%}

Should this postponed then?

So this does work with the twig block of alerts and patterns but when using with views it doesn't work due to {% if meta_items_tags %}
always returning true.

Pushed up a fix for that but still doesn't work great in views because of how views returns the string.

Really need to think about this more

|render|striptags|trim breaks the pattern display but works with things like views.

Removing it fixes the pattern but breaks views and shows empty divs.

Want to make sure we aren't moving away from having this work in the UI and not being just twig based.

Reverted my change and will think about that later.

Will use the other changes.

Automatically closed - issue fixed for 2 weeks with no activity.