[2.0.0-beta4] Normalize attributes values.

This is a core issue. The component is rendered inside a form field which is not mapped by ui patterns.

Or I am wrong?

Indeed, it doesn't look like an UI Patterns issue, because this snippet uses stuff we are trying to avoid with UI Patterns 2:

• Twig blocks and embeds, especially when used without "only" keyword (but we may address this later: #3449653: [2.0.0-beta5] Replace component() function by native include() function)
• |raw() filter

{% embed 'careerforce_skin:sdc-button' with { text: attributes.value|raw, variant: variant} %}
  {% block children %}
    {{ children }}
  {% endblock %}
{% endembed %}

So this may be a "support request".

What are the careerforce_skin:sdc-button component definition & template?

You are getting an error which was "fixed" by #3470231: [2.0.0-beta2] Attributes normalization

The root cause is triggered SDC's ComponentValidator::validateProps() which is calling a dependency method which is executing json_encode() which is casting the attribute object into a string.

So, this issue is fixed with a SDC render element alteration by UI Patterns 2, but you are still getting it. Why?

Maybe because you are using {% embed 'careerforce_skin:sdc-button' with { text: attributes.value|raw, variant: variant} %} which is not triggering the SDC render element.

In this order:

1. Because you are not passing attributes, you can start by adding the only keyword. Non tested proposal: {% embed 'careerforce_skin:sdc-button' with { text: attributes.value|raw, variant: variant} only %} . See: https://twig.symfony.com/doc/3.x/tags/embed.html

2. If you still have the issue or if you want to pass attributes to the component, make it explicit and convert to array. Non tested proposal: {% embed 'careerforce_skin:sdc-button' with { attributes: attributes.toArray(), text: attributes.value|raw, variant: variant} only %}

3. If you still have the issue, replace Twig embed and block by a component() function. Non tested proposal:

{{ component( 'careerforce_skin:sdc-button', 
   {
     text: attributes.value|raw,
     variant: variant
   },
  {
    children: children
  }
) }}

Is it helping?

So I'm reopening this one as I'm noticing this when using patterns from a view

Using ui_suite_uswds 4.0.x branch
ui_patterns latest beta.
For ease I duplicated the admin content view and removed the admin part from the new url so it uses the front end theme.
ui_pattern-devel must be uninstalled.

I now get a fatal error

The error I believe is because the #value key is an attribute object now.

Let's target the next beta

However, I am still not reproducing the issue.

• ui_suite_uswds 4.0.x branch >> OK, i am at commit 544dfaa4704bf2b3dca5faeb794277777264dee1 (HEAD -> 4.0.x, origin/HEAD, origin/4.0.x)
• duplicated the admin content view and removed the admin part from the new url so it uses the front end theme. >> OK, I have duplicate_of_content view with /content page display
• ui_pattern-devel must be uninstalled >> OK, ui_pattern_devel is not installed

Other information about my environment:

• Drupal version : 11.0.4
• PHP version : 8.3.12
• DB driver : sqlite
• Drush version : 13.2.0.0
• Web server: PHP Built-in web server

Will try and gather additional steps but it's reproducible for me 100% of the time.

Though I believe the bug lies with core or views

Fresh install

Drupal 11.0.5
Drush 13
Php 8.3
Ui suite uswds 4.0.x
Ui patterns beta3

Install all needed files
Leave ui patterns devel off

Enable theme, using CDN to pull USWDS library in
Go to admin/structure/views/view/content
Duplicate the page
Change URL from admin/content/node to content/node

Need to have at least 1 piece of content

Go to the page and see the errors.

hello,
i am debugging your problem,
first thing i found, in file form-element-label.html.twig,

 {%- set attributes = attributes.setAttribute('title', title) -%}

the title is provoking a bug on my instance. if you replace "title" by "title|render", it works.

Second thing i found, in file views-view-table.html.twig,
line 140

{% set prepared_columns = prepared_columns|merge([
      pattern('table_cell', {
        'attributes': column.attributes.addClass(column_classes),
        'content': {
          '#markup': column_content
        },
        'active': active
      })
    ]) %}
  {% endfor %}

the attributes injected are containing (at twig render time), an invalida value at key "headers".
add .removeAttribute('headers') at line 142, after .addClass(column_classes) and it will work.

Let's discuss this after beta4.

We will:

• Merge LinksPropType::normalizeAttributes() in AttributePropType::normalize()
• Call AttributePropType::normalize() from LinksPropType::normalize()
• Add to AttributePropType::normalize() some logic about attribute value being list and not associative array
• Add to AttributePropType::normalize() some logic about renderable interface & stringable interface inspired by SlotPropType::convertObject() (if possible, implement this in StringPropType:normalize() and call it)

So:

DONE in commit b32351950f6:

• Merge LinksPropType::normalizeAttributes() in AttributePropType::normalize() >>
• Call AttributePropType::normalize() from LinksPropType::normalize()

DONE in commit 4ed020f26eda:

• Add to AttributePropType::normalize() some logic about attribute value being list and not associative array
• Add to AttributePropType::normalize() some logic about renderable interface & stringable interface inspired by SlotPropType::convertObject()

So, I hope we addressing the 2 issues met by Steven from this ticket:

• the error because of the 3 levels attributes object structure (coming from Views I guess), it will be normalized according to Drupal attribute object normalization OR as a JSON value
• the error because of a render array as attribute value, it will be normalize also be normalized as a JSON value (

(JSON encoding is only for extreme use case, most iof the normalization do'nt rely on this workaround)

About Dang Tran feedback:

Not sure if it's helpful. In my case, I noticed that the component SDC-button I created hasn't been processed by the function "processAttributesProp" in ComponentElementAlter.php to convert the attributes object type '\Drupal\Core\Template\Attribute' into an array, while the other components have. I only see only button component encounters this issue. In my case, I don't think it's because of views, will share more information when I figure out something!

Interesting, maybe the logic of ComponentElementAlter::processAttributesProp() can also move to AttributePropType::normalize().

Anyway, I don't know what is happening with those {% embed %} thingy. Maybe we will need to revamp this hacky part of the SDC API next year, moving some logic from the TwigNodeVisitor to the Render Element.

super nice job ! i like the treatment attribute is receiving, because we know it will receives a lot of weird data over time,
mainly calls from twig with variables having values not trivial.
i just have a few remarks to help finish the attribute normalization/sanitization.

when you normalize a list of values in normalizeList, only the case of an array is covered.
i would add maybe two cases :
- important : a is_object test inside this function to call normalizeObject
- less important : when the value inside a list is an array, imagine this is render array. the caller intuitively would like it to be rendered. this may never happens :) why not try to trigger a rendering ?

sometimes json_encode may produce unexpected results (memory error or ?), for example if there are objects inside the values we are trying to json_encode. This is maybe too much good attention and intentions to the persons which are adding bad values inside attributes.

Why censuring the code to call "render" inside the normalizeMapping function ?

Why censuring the code to call "render" inside the normalizeMapping function ?

Because I don't know how to test it in AttributesPropTypeNormalizationTest :)

Sometimes json_encode may produce unexpected results (memory error or ?), for example if there are objects inside the values we are trying to json_encode. This is maybe too much good attention and intentions to the persons which are adding bad values inside attributes.

Yes, I am nice guy here :) I add a depth limit?

json_encode(mixed $value, int $flags = 0, int $depth = 512): string|false

when you normalize a list of values in normalizeList, only the case of an array is covered.
i would add maybe two cases :
- important : a is_object test inside this function to call normalizeObject

Great idea.

- less important : when the value inside a list is an array, imagine this is render array. the caller intuitively would like it to be rendered. this may never happens :) why not try to trigger a rendering ?

So, related to my issue with AttributesPropTypeNormalizationTest. I don't know how to mock a service.

Sometimes json_encode may produce unexpected results (memory error or ?), for example if there are objects inside the values we are trying to json_encode. This is maybe too much good attention and intentions to the persons which are adding bad values inside attributes.

✅ Depth limit added.

when you normalize a list of values in normalizeList, only the case of an array is covered.
i would add maybe two cases :
- important : a is_object test inside this function to call normalizeObject

✅ Test added.

Why censuring the code to call "render" inside the normalizeMapping function ?

- less important : when the value inside a list is an array, imagine this is render array. the caller intuitively would like it to be rendered. this may never happens :) why not try to trigger a rendering ?

Because I don't know how to test it in AttributesPropTypeNormalizationTest :)

So I switch to this branch on 4.0.x branch of USWDS same scenario in #15 and no fatal error!

Twig's include & embed are not currently a good way to embed components, because they don't trigger the SDC render element. Passing through the render element is an important par of the rendering pipeline.

So, we have 2 possibilities:

• right now, using the UI Patterns 2.x specific component(string $component_id, array $slots = [], array $props = []) function
• later, enjoying a fix in SDC Core implementation in order to make include & embed trigger the render element. We will first experiment this solution in UI Patterns 2.x ( #3449653: [2.0.0-beta5] Replace component() function by native include() function ) and we plan to move the fix to Core: #3484580: Trigger SDC render element when using Twig include or embed