Fix [attributes] String value found, but an object is required error when a component has no attributes

Hello @rajab, thanks for submitting an issue.

did you try to put

$ref: 'ui-patterns://attributes'

instead of

type: Drupal\Core\Template\Attribute

in your sdc component definition ?

Also, this kind of error you are showing here, usually happen when using twig to manipulate what is injected into components, and especially component attributes.

Would you show us where and how you use the component which is triggering the error please?
i see in your stack trace, no trace of ui patterns.

In the meantime, you may also try to activate ui_patterns_devel module, it may catch that exception meanwhile.

thank you

Thanks, Mikael, for following up
While troubleshooting when I enable the ui_patterns_devel module the [attributes] String value found error hides out.

• The component Page Title
• Using the component in a Drupal twig template in a theme page-title.html.twig
• In Drupal Core page-title.html.twig
• ... preprocess_page_title
• page_title in drupal_common_theme

i would let @Pierre answer in more details the question, but i think "include" mechanisms are to blame here in twig.
It is not appropriate to correctly trigger the rendering.

i will have a look

Attributes typing

So, page-title.component.yml is defining both:

    attributes:
      type: Drupal\Core\Template\Attribute
    title_attributes:
      type: Drupal\Core\Template\Attribute

There are some issue with using PHP namespaces as JSON schema types:

• it is not compliant with JSON schema
• in order to avoid a fatal error from the JSON schema validator, SDC skip the prop validation when it finds a PHP namespace (I hope we will remove this behaviour it one day)

UI Patterns 2 is trying to tidy this mess by replacing the weird and invalid type: Drupal\Core\Template\Attribute by a prop JSON schema which can be properly processed and validated:

type: object
patternProperties:
  ".+":
    anyOf:
    - type:
      - string
      - number
    - type: array
      items:
        anyOf:
        - type: number
        - type: string

($ref: 'ui-patterns://attributes' is just a shortcut for this JSON schema)

Component use and explanation

In page-title.html.twig, you are using this component like that: {% include 'varbase_components:page-title' %}

So, you are injecting all variables from the presenter template to the component, including attributes and title_attributes as PHP objects.

So, you get this situation:

1. your attributes values are now going through the validator
2. but the validator receive a PHP object which is casted as a string and raise an error because it doesn't expects a string

Proposals

Because this is not an issue from UI Patterns 2, in my opinion (by triggering the validator, we are just showing up an already existing issue), the "obvious" solution will be to reconsider the way you are using the component in a presenter template, but:

• I feel bad to ask you to adapt your vartheme_bs5 → codebase to accommodate UI Patterns 2
• You are not the only one doing this kind of stuff in SDC themes

The "best" solution will be to fix SDC itself, in Core: 📌 Trigger SDC render element when using Twig include or embed Active but it may take time.

So, let's try to this ASAP: 📌 [2.0.0-alpha3] Replace component() function by native Twig mechanisms? Active

Rajab, are you OK with the analysis ? Do you want to help with 📌 [2.0.0-alpha3] Replace component() function by native Twig mechanisms? Active ?

Got that, thanks, Pierre, for the direction.

📌 Start a 3.0.x branch for Varbase Components to support UI Patterns ~2.0 and Storybook and pave the way for supporting Drupal 11 Active
📌 Start a 4.0.x branch for Vartheme BS5 to support UI Patterns ~2.0 and Storybook and pave the way for supporting Drupal 11 Active

I had a commit yesterday to add the following

    attributes:
      type: Drupal\Core\Template\Attribute
      title: Attributes
      description: Wrapper attributes.

I noticed the Always use the attribute object → section in Best Practices →

An ‘attributes’ variable is automatically injected in every component template, it is a Drupal Attribute object: https://www.drupal.org/docs/8/theming-drupal-8/using-attributes-in-templ... →

It is useful for Drupal render API.

Doing more experimentation

Hello @Rajab, i wanted to add the following :
- yes the attributes variable should be used inside the twig template of a component.
- but an attribute, if declared in the component definition, should not be declared as a PHP object namespace (this is an invalid definition). i When declared, as shown by Pierre, it should be a valid piece of JSON-scheme . There is a code which is converting the array (valid in the json-schema component definition) to the attributes objects along the way.

If i am not wrong, when SDC has been introduced, the idea was not to have the twig files of components directly embedded or included by other twig presenter templates. because in that low level usage, the component part is not used, only the twig part. It is currently by passing the rendering phase of SDC, which would be normally required to used the twig file.

If i am not wrong, when SDC has been introduced, the idea was not to have the twig files of components directly embedded or included by other twig presenter templates. because in that low level usage, the component part is not used, only the twig part. It is currently bypassing the rendering phase of SDC, which would be normally required to use the twig file.

Yes, until late in the SDC development, the primary target usage was template to template calls. Using the components from Drupal API was an afterthought. For example, the render element was not handling slots until a few weeks before the merge. Because of this, there are still weird stuff in SDC implementation.

When using Twig include or embed, there is a little hack to load attached asset libraries and do some validation, but we don't really load the UI component as a proper plugin, and we don't run the associated render element.

So, today, most of the SDC themes are using SDC as a simple Twig templates repository, enjoying a nicer way of organizing the templates (in a components/ folder, one folder by component) and calling them with include or embed (automatic resolution of provider:component_id naming), but that's all. Without leveraging the full power of using components as first class UI objects. The component definition YAML file is barely used.

I hope UI Patterns 2 and some improvement in Core will fix that.

I spotted the following issue.
📌 Allow parsing and writing PHP constants and enums in YAML files Needs work

Pierre, I totally agree with you.
Clean work should have clear logic in the code and in the right order.

I'm with custom 'com-include' and 'com-embed' "not the exact name".

"component" or "pattern"

• JSON - for component standard metadata.schema.json and https://json-schema.org/draft-04/schema#
• TWIG
• YAML
• PHP

New developers will need to have basic quick logic to get it.

The component level is in which level .. the .component.yml or twig
Or both are at the SDC level

Oh, I see the logic in Before SDC and After SDC.
Maybe your new plan to process the same includes or embeds.

https://git.drupalcode.org/project/ui_patterns/-/merge_requests/267/diff...

      new ModuleNodeVisitorBeforeSdc($this->componentManager),
      new ModuleNodeVisitorAfterSdc($this->componentManager),

📌 [2.0.0-alpha3] Replace component() function by native Twig mechanisms? Active

this clearly sounds a duplicate of 📌 [2.0.0-alpha3] Replace component() function by native Twig mechanisms? Active . i close the issue if you don't mind