🇫🇷France @just_like_good_vibes

ready ;)

i gave it a try

just_like_good_vibes → made their first commit to this issue’s fork.

just_like_good_vibes → made their first commit to this issue’s fork.

Ok, 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)

just_like_good_vibes → made their first commit to this issue’s fork.

just_like_good_vibes → created an issue.

just_like_good_vibes → created an issue.

new in v1.14.1 :

Table - Tableau

✨ Ajout du modificateur fr-table--multiline équivalent à fr-cell--multiline mais s'appliquant à tout le tableau #1233

just_like_good_vibes → created an issue.

and, 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; from PropTypeInterface.

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 :) ?

hello,
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".

When the ui patterns component form is used by display builder, the Remove button introduces some problems because of the drupal core FormBuilder.
Drupal core is trying to automatically identify a triggering element, and in some cases the Remove button of a slot is identified as triggering element and its submit callback is used. Awful edge case.

Let's note also the remove button was not working... fixed in 📌 [2.0.9] Component form : update behavior of remove slot source button Active

In this issue i also fix missing injected contexts in the builder panel.

just_like_good_vibes → created an issue.

just_like_good_vibes → created an issue. See original summary → .

just_like_good_vibes → made their first commit to this issue’s fork.

just_like_good_vibes → created an issue.

Christian, would you like to review please?

The support of attributes will be made in ✨ Attributs prop type source replaces token Active , but that issue would need a little refactor and simplification when the current issue would be merged.

If you intend to simplify the default component form and propose simpler prop forms for the users, you can try our experimental sub-module "ui_patterns_ui", it allows to define simpler forms for each component.

Dear juc1,
to answer your question in comment #10,
those other sources make perfect sense for the checkbox.
Some people will for example map a field value to the value of the prop.

Hello, i suggest the svg tag should be allowed too.

i want to add also this : if we take care of the active status of links here, then the data has some cache metadata,
to simplify we could say the data would depend on the current url ?
that part was not added in my MR. it brings some complexity right? that part comes at a cost :)
let's discuss this in the next weekly?

Hello guys,
i rebased the MR and added some modifications.
still no time to add some tests about that.

so i am asking, what kind of minimal tests do we here to test that feature?
i guess that should be functional tests to have the ability to have the active trail context.

i was tempted to merge, but i put it for review right now, unassigned, someone can take it and review please :)

just_like_good_vibes → made their first commit to this issue’s fork.

just_like_good_vibes → created an issue.

pdureau → credited just_like_good_vibes → .

let's try to write also the presenter templates for tables in views, like it is done in ui_suite_bootstrap.

just_like_good_vibes → created an issue.

this fix has been pushed and re-pushed again until we finally have it now with a clean dependency to a required ui_patterns min version.
finally... but this is not finished, we will follow-up - in that issue or not? - performances issues introduced now.

and finally :)

Hello rajab natshah,
thanks to your issue, we though to introduce a more deeper support for tokens in ui patterns sources.
so we will introduce a shared code to deal with tokens here : https://www.drupal.org/project/ui_patterns/issues/3540970 📌 [2.0.8] Enlarge the support of tokens in sources Active

just_like_good_vibes → created an issue.

thanks

just_like_good_vibes → made their first commit to this issue’s fork.

hello,
thank you for your work, indeed this is a nice usecase :)
Today we have some code in Token source, if we plan to generalize it in other sources like Attributes, it would be good to rely on the same code in those sources.
i suggest that factorize some appropriate code about tokens, somewhere.
In a trait or directly in the SourcePluginBase ? @Christian, others, what do you think ?

do we need tokens elsewhere? maybe yes.

i posted an update of the code which seems to correct the issue,
but this issue in ui_patterns is needed : https://www.drupal.org/project/ui_patterns/issues/3540835 🐛 [2.0.8] correct ChoiceSettings for Component source Active

just_like_good_vibes → created an issue.

here we are, ready for review :

- we have a new interface for those sources with a choice. It allows them to expose those choices to the outside world.
- we have improved the returned label of sources, in those particular cases of sources with choice.

just_like_good_vibes → changed the visibility of the branch 3513568-2.0.3-source-usability to hidden.

hello,
sorry trimming here is not appropriate :)
we need to cope with this edge case in a better way.

just_like_good_vibes → made their first commit to this issue’s fork.

just_like_good_vibes → made their first commit to this issue’s fork.

i found this line in ui_patterns_ui (UiPComponentFormDisplaysForm)

$component_id = $element['#component_id'] ?? $element['#default_value']['component_id'] ?? NULL;

and we have this line in ui_patterns (ComponentFormBase)

$component_id = $element['#default_value']['component_id'] ?? $element['#component_id'] ?? NULL;

we need to sort this out

ready for merge

just_like_good_vibes → made their first commit to this issue’s fork.

Hello,
we are still discussing again and again ( ;) ) the model for this component.

- do we introduce a Row component or not ?

We vote for yes, because it will be more obvious for users,
and easier to use in views.

But, we notice this is not technically required !

let's add table_row and finish this work :)

just_like_good_vibes → made their first commit to this issue’s fork.

just_like_good_vibes → made their first commit to this issue’s fork.

just_like_good_vibes → made their first commit to this issue’s fork.