🇫🇷France @just_like_good_vibes

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.

hello :)
i just rebased the MR with the right branch 1.x

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

Hello guys,
this introduces a breaking change in the config structure.
you will answer me that there is an update hook and i would agree.
But also, this does not introduce anything new or urgent, just a nice to have.
let's wait the next weekly to vote if we merge that now or keep it for later :)

require 📌 Future proofing views source plugin Active

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

hello, thank you for your issue. please share a more detailed explanation and use case.

the ui_patterns module will not store any information related to DS. this may exist for example in ui_patterns_ds

in your MR, i see ds.layout_plugin.settings.default, which would not be permitted by design.
did you get a chance to check ui_patterns_ds?

hello, thank you for reporting the issue.
the behavior can already be made with an injection of the correct class into attributes, but yes, let's introduce variants to be able to do this.

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.

sorry i move back, layout will disappear from drupal soon, so i let someone more concerned about this to take it and propose something :)

i give a try on this one

hello, sorry to come late on that one, but testing for '0' seems not appropriate neither.
it doesn't make sense on the PHP side. any other thoughts, like pdureau?

is this issue still up-to-date, or should we close it ?

Hello, i couldn't really reproduce on my side, when i tested it with the mentioned modules.
@yannickoo, would you share the exact manipulations that trigger the errors please?
thank you

Is it still up-to-date or should we close it?

i have updated the source, to do it the proper way. the textfield source was already compatible and available for splots, except that is was tagged as widget:dismissible which was the reason why it did not appear for splot. i removed that tag and now it appears.

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.