🇫🇷France @just_like_good_vibes

Hello,
thank you for your message.
I understand your point, but currently all efforts go on with the current versions.
we can assist you in reviewing and publishing your efforts on this project, so we invite you to do the mentionned work on the 1.0.x branch and propose merge requests.
thank you

i am trying to understand here
before closing the ticket.
first remark : why checking “force using fields” when you don’t need it? so better uncheck if you want a row to be treated with ui patterns row style for example, or check it to force a row to be composed of fields.
in other words,
if you check that option, it will activate a special behavior in ui patterns views where rows are really arrays of fields.
we had an internal discussion about adding a new option for that, but we finally decided to use that already existing option to activate that mode.
treating rows as arrays of fields, can be critical and really required by some sdc components (slots), let’s say tables and row components..
sorry tregonia, i don’t see your point.
in my understanding, the ticket can be closed :)

just_like_good_vibes → created an issue.

ok let's merge that

Super.

we need this :
- update the companion module to remove the JS
- mark the prop "themes" as deprecated, which means basically update the title / desc of the prop

just_like_good_vibes → changed the visibility of the branch 3550802-undefined-array-key to hidden.

Dear andyg5000,
thank you for reporting.
As already mentioned in the code, sdc component definitions without names is not a good practice, and those changes would rather being made directly to the mentioned themes.
But to support those practices in the wild, i have just updated the code :)
Note that there was already a line of code to cope with definition's names missing , but it seems that in your use case processDefinitionCategory was called without a prior call to processDefinition, seems strange to me but anyway i have added this new check and factorize the existing behavior inside a new protected method "cleanDefinition" instead of duplicating it in processDefinition and processDefinitionCategory.
MR to review is [!448]

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

Hello,
would you please be more specific?
you used a views row plugin from UI patterns, or a views style ? or both?
maybe would you share the config of your view please?
also, did you check somewhere "force using fields"?
thank you in advance

would you share a simple usecase please that is not working with extra fields?
thank you

Hello,
thank you for for your time.
about your remark " but I still believe that something should be done to further improve this", this will be addressed later.

Hello, would you try this version please ?

Thank you very much for taking the time to check. we will fix asap.

Hello,
thank you for reporting. it seems we have an unfortunate side effect of a recent new feature.
we will fix that soon.
if you rollback to a version like 2.0.6 or before, would you confirm that slowness disappears please?
thank you

good for merge

just_like_good_vibes → created an issue.

hello, i am still a bit afraid to merge, let's do more checks just to secure this change is not introducing a regression with the arrival of defaultSettings implemented.

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.