Hello, after some digging finally found what was killing our website render when using the dsfr4drupal components.
Problem/Motivation
When we are using a component in a render array (leveraging core/lib/Drupal/Core/Render/Element/ComponentElement.php) if our SDC as a prop named "variant" it will conflict with global variants implemented in 11.2.0 https://www.drupal.org/node/3517062.
To be specific, this particular piece of code introduce an unwated behaviour (L53-56) :
$props = $element['#props'];
if (isset($element["#variant"]) && !isset($props['variant'])) {
$props['variant'] = $element["#variant"];
}
Moreover, if no variants are defined #variant default to empty string "", meaning that our prop will get "" as prop value. Which breaks our DSFR4Drupal components (and crash the website, as "" is not a valid variant).
Steps to reproduce
Create a renderable array of a dsfr4drupal sdc component with a "variant" prop (like card component) and omit the enum prop "variant" (sm/lg).
Proposed resolution
Rename all variant props as "cardVariant"/"buttonVariant" etc... Which will needs refactoring :(
Regards,
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | component_debug.zip | 2.07 KB | plits |
Comments
Comment #2
s3b0un3tHello,
This behavior change was specifically planned for 1.4.4 by systematically defining a default value for each "variant" property. To reproduce this bug, could you provide a concrete example (with the values for the props used)?
Regards
Comment #3
plits commentedSalut s3b0un3t :)
Attached module to reproduce issue against 1.4.4
drush en component_debug -yNavigate to /component-debug/button =>
Thanks !
Comment #4
s3b0un3tThanks for your feedback. I’m currently in vacation without computer.
I have forwarded the issue to the other maintainers to look it soon.
Comment #5
s3b0un3tComment #6
benjy44Comment #8
s3b0un3tComment #9
s3b0un3tAfter changes, the following behaviors can be noted:
It seems OK!
Comment #11
s3b0un3tFixed into release 1.5.0
Comment #12
plits commentedThanks :)