Create new List component for Umami

Same deal could this be an array vs needing a new template?

Rebase seems fine.

For reviewing in MR.

https://git.drupalcode.org/project/drupal/-/merge_requests/4897#note_223056 needs FEFM review.

Is there an alternative we can use in that one thread? Issue seems to have stalled

Left 1 comment on the MR.

Probably would be a good follow up. Definitely not here.

Believe feedback has been addressed

Also acknowledging the frontend manager tag and I’m not one of them. But been 2 years so still marking

There are conflicts for the performance tests, but perhaps resolving those can be put aside for a bit while frontend framework manager review is outstanding. But there's also a conflct in umami.theme, so NW for that.

Left 1 comment on the MR. I'm going to mark and hope someone can get a frontend manager (I've posted a few times but everyone is busy).

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

For the meta:enums based on other components in umami, then I think we are good to go here @finnsky

Believe this one is good to go.

Hello,

Sorry to share this feedback that late 🙇‍♂️ items property definition seems incomplete. What is inside the array?

items:
  type: array

Looking in the MR, the answer is: the data structure of items in field.html.twig:

 * - items: List of all the field items. Each item contains:
 *   - attributes: List of HTML attributes for each item.
 *   - content: The field item's content.

It was already the case in #3365389: Convert tags to use single directory components, but we were OK because the component was not exposed to visual builders (like Canvas or Display Builder), so no expectation for schema "shape" matching related to UI forms and data retrieval from Drupal API.

So, 2 proposals for this MR:

• the quick-win: just add a noUi: true: true property at the root of the definition to hide and forget the component
• the "real" fix: I believe we don't need attributes here because classes like field__item don't belong to the markup of an UI component, so we can remove it and items become a list of renderable (because they are, they come from a field formatter) in a slot (where renderables belongs

In field--node--field-ingredients--recipe--full.html.twig:

  {% include "umami:list" with {
    items: items|map(item => item.content),
  } only %}

In list.component.yml:

slots:
 items:
   title: Item

In list.twig:

 {% set items = items and items is not sequence ? [items] : items %}
    {% for item in items %}
      <li class="'umami-list__item'">
        {{ item }}
      </li>
    {% endfor %}

Oh! You follow the the "real" fix instead of the quick-win 🥰

I didn't test the MR locally to check if it works technically ('but I guess you did it while doing the change) but the SDC part of the MR is OK for me now. Thanks a lot for your quick action.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.