Problem/Motivation
Sources don't add '#required' if the required property is configured inside the yml. We also need a #title field to render a error message.
Proposed resolution
Ensure that every source should handle this.
Issue fork ui_patterns-3461277
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
pdureau commentedIs it a beta1 issue?
Comment #3
pdureau commentedComment #4
pdureau commentedUnderstood now. I will share my thoughts.
Comment #5
pdureau commentedDon't implement "required" property
SDC is supporting "required" for both slots and props:
In my humble opinion, this is not a feature but an issue I was very vocal against. Required data is best fitting with business modelling, content management and data storage. UI artefacts, including components, must be the more loose possible. It is better to rely on default values.
Also, it is very hard to enforce required data. With the form builder, it is possible, by checking the filled data. But only for "widget" sources (textfield, URL, number...), not for "data from Drupal" sources (menu, field property...).
Moreover, it is not possible to enforce it for
component()twig function or render element. Oh indeed, SDC do it, by raising a fatal error. Not the right way.Or, maybe, only for props, sometimes
However, UI Patterns Settings 2.x is also proposing such a feature:
And we want to cover the full scope of UI Patterns Settings (not all the setting types, but all the mechanisms).
So, let's implement required for props, and props only, for some widgets. While keeping a warning in
ui_patterns_devel's Component validator telling using a default() Twig filter would be better.Implementation proposal
On PropTypePluginBase::getSummary(), add a message telling the prop is mandatory (only for props). Careful, the information is outside the prop definition.
On source widgets (only for props), add the Form API #required property (default value: FALSE, of course):
CheckboxWidget: no, it would not make senseDon't forget to add the migration of this property in ComponentConverter::getPropsFromSettings()
So...
OK with that?
Comment #6
pdureau commentedComment #7
pdureau commentedI will give a try
Comment #9
pdureau commentedOnly legacy migration left
Comment #10
pdureau commentedComment #11
christian.wiedemann commentedMy findings:
* We have double titles now if the field is required.
To solve this I think we have two options.
I would prefer 1 because it is straight forward.
Right now the source must call addRequired. Maybe there is a better way to implement that.
No hard opinion about that.
We should move this to beta2.
Comment #12
christian.wiedemann commentedComment #13
christian.wiedemann commented@just_like_good_vibes what do you think?
Comment #14
pdureau commentedThanks for your review, Christian.. We keep it in beta1
Comment #15
just_like_good_vibesHello,
globally that sounds ok for me.
A little remark about the implementation : the method name "addRequired" is not totally helpful in my opinion. handleRequiredProp or something like that ? and why not passing by reference the form object instead of returing it?
Also, we have like an UI issue about the title. When it is required, we add a title if not present to the form element. but indeed that could produce a duplicate title, because typically the source form is already in a propform or slotform where a title is already provided.
why not putting "Required" as a title when no title is found?
Comment #16
pdureau commentedComment #17
pdureau commentedIndeed.
I was thinking about that too, but I am not comfortable about "hijacking" the title and I am wandering about potential accessibility issues.
About Christian's proposals:
I find the first one interesting but the fieldset also include the prop selector, so it is always expected to be there.
Maybe, we can keep the "required" management in the source form,a s already done in the MR, but move the "visual clue" to the fieldset management in the Form builder, I will do a proposal
Comment #18
pdureau commentedWhat do you think about this proposal: https://git.drupalcode.org/project/ui_patterns/-/merge_requests/164/diff... ?
Comment #19
just_like_good_vibesi checked it. ok let's merge ?
Comment #20
just_like_good_vibesrebased and completed thanks to Christian remarks
Comment #22
just_like_good_vibesComment #23
pdureau commentedComment #24
christian.wiedemann commented