Closed (fixed)
Project:
UI Patterns (SDC in Drupal UI)
Version:
2.0.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
12 Aug 2025 at 14:18 UTC
Updated:
2 Oct 2025 at 10:34 UTC
Jump to comment: Most recent
Comments
Comment #2
just_like_good_vibesComment #4
just_like_good_vibesChristian, would you like to review please?
The support of attributes will be made in #3496209: Add token replacement support to AttributesWidget using new centralized token and normalizer services from SourcePluginBase, but that issue would need a little refactor and simplification when the current issue would be merged.
Comment #5
pdureau commentedComment #6
christian.wiedemann commented1. From my point of view the PropTypeConversionTrait should be a service (PropTypeConverter). And the base class should simple provide the service for easy access.
2. We should avoid renderInIsolation. What is the use case behind. Can we check for '#markup' or #plain_text'?
Comment #7
christian.wiedemann commentedComment #8
christian.wiedemann commentedComment #9
just_like_good_vibeshello,
renderInIsolation was already there. it is used, when component props are receiving render arrays instead of the type expected by the props. this is the usual case when people are using twig to pass data from twig to props.
in those case, we always render the data to cast it to the right format. And we render with "renderInIsolation".
Comment #10
just_like_good_vibesand, unfortunately, no we can't make a service out of prop type normalization, because basically we need static methods to use those "helper functions" in the trait. let's take as an example
public static function normalize(mixed $value, ?array $definition = NULL): mixed;fromPropTypeInterface.I started the conversion to a service and i was then faced by this wall.
so, given my two answers, should we have a consensus for merge :) ?
Comment #11
just_like_good_vibesOk, discussed during weekly :
- let's be careful about changing methods inside EnumTrait or PropTypeConversionTrait, and deprecate them, not remove them (thanks Florent for the suggestion)
- we will introduce classes instead of a traits. But,
-- option a) "no service" : our static methods from traits are static methods in a class, and those static methods are called directly from static method or normal methods
-- option b) "with service" : our static methods from traits are now normal methods in a class that is a well-identified new service, those methods (in the service instance) are called in normal methods thanks to service injection, and called from static methods with a static instanciation of the service first
between a) and b), performance was a question.
we did not decide yet if b) or a), probably it will be b)
Comment #12
just_like_good_vibesComment #13
just_like_good_vibesready ;)
Comment #15
just_like_good_vibes