Problem/Motivation
In #3528205: Performance: On-demand lazy-loading source selector & #3478643: UX of source selector for slots, we focused on asynchronous load for better performance (no need to create a plugin instance of each source when we are not using the selector).
But we also introduced some UX changes:
- some already discussed for long and warmly welcomed, like displaying only the default source form when it is a "widget" or the settings summary
- some with more improvisation, so to be challenged, like the modal system
We need to address those UX topics before releasing 2.0.22.
Proposed resolution
Let's talk about...
1. Replace details element by a simple "flow" of props ?
Moved to its own issue: #3622982: Remove details element in component form?
2. Open the AJAX inline instead of in modal?
Also discussed in #3622509: Let hosts open the source selector inline instead of in a dialog.
Can we keep the full AJAX logic but load the modal content inside the prop form? As a replacement of the widget form, hiding the "settings" button while we are configuring the sources:

If we keep the settings button in the details summary, let's not forget this in order to avoid some misalignment:
:is(.uip-prop-box,
#drupal-off-canvas-wrapper .uip-prop-box) summary .uip-source-selector-toggle--open {
height: auto;
}3. How to format PluginSettingsInterface::settingsSummary() ?
(Investigation in progress)
What about slot forms?
Those proposals are bout prop forms, but we have also moved to asynchronous loading for slots. Are those proposals also applicable for slot forms? Is there something to be careful about?
For information, Display Builder don't use the slot forms, so it may be addressed in a later follow-up.
Issue fork ui_patterns-3622928
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 #3
just_like_good_vibesComment #5
pdureau commentedComment #6
pdureau commentedReview of the current state of the MR. Commit: 13d47b60e8b1c4b7c774695a9f5a88205262efe5
1. Replace details element by a simple "flow" of props ?
Moved to its own issue: #3622982: Remove details element in component form?
2. Open the AJAX inline instead of in modal?
UI feedback
We lost the little "settings" icon in the details summary. It is cool to have a (way) simpler JS & CSS code, and we may decide it is OK like that.
But this icon has 3 advantages:
Can we restore it with not too much code?
Test with UI Patterns Field Formatters
✅ OK, works well.
Test with UI Patterns Layout Builder
✅ OK, works well. Also with blocks embedding field formatters (the tricky use case from #3528205: Performance: On-demand lazy-loading source selector)
Test with Display Builder
Tested with #3622023: Behaviors are not attached on htmx swaps outside the builder root (side panels).
⚠️ I got an a new page instead of a the inline AJAX once, but it may be a cache issue from before I switch to the new branch. Let's be careful anyway.
❌ I need to explicitly click on "Update" button (the one we may remove #3554416: Remove Update button from ContextualFormPanel before 1.0.0).
To reproduce:
It is a bit tricky, because it works sometimes, maybe the first time only. It is hard to identify the exact cause.
Test with UI Patterns UI
To check.
3. How to format PluginSettingsInterface::settingsSummary() ?
Not done in the MR yet, because we didn't define the expectations yet.
Comment #7
pdureau commentedComment #8
mogtofu33 commentedFeedback from Display Builder, tested with !564 at 757705b8, in the Config drawer (about 270px wide), with UI Suite Bootstrap as the front theme.
About the Display Builder results in #6
The full page reloads, the need to click Update, and the inconsistency were one cause, now fixed in Display Builder 1.0.x #3622023: Behaviors are not attached on htmx swaps outside the builder root (side panels). On core 11.x, the htmx asset loader attaches behaviors before the scripts it just loaded have run. So the first component form's
#ajaxbuttons were not bound, and they submitted the page. Later forms worked because the script was already there. Display Builder now loadscore/drupal.ajaxup front. Core's main branch fixes the loader itself with htmx 4.Works well
FocusFirstCommand): into the row on open, back to Configure on close. It works with the keyboard since the toggles bind onclick.data-uip-announcechange event. Display Builder saves on change, so Cancel now works as a real revert: the restored values are saved back.Could be better for a side panel
aria-label="Configure source of …", would save that space. It's in the same place on every prop, right next to its label. Outside anysummary, so no JS is needed.Comment #10
pdureau commentedReview of the current state of the MR 565. Commit: cd9d7dd5fcf36a0463ef3443ed7a891aef45a442
1. Replace details element by a simple "flow" of props ?
Moved to its own issue: #3622982: Remove details element in component form?
2. Open the AJAX inline instead of in modal?
UI/UX feedback
Icon in the details summary VS button in the inline modal ? It may be better to talk about that in an immediate follow-up issue. The priority here is to have something working.
Test with UI Patterns Field Formatters
✅ Still OK.
Test with UI Patterns Layout Builder
✅ Still OK.
Test with Display Builder
Tested with #3622023: Behaviors are not attached on htmx swaps outside the builder root (side panels).
✅ No need to explicitly click on "Update" button anymore. (⚠️ I got the reverse of the previous bug: some checkboxes widget, directly in the prop form, not in the inline modal, were not triggering update event, but it was seen only for a few seconds, in only a few props, and never again).
❌ I still get an a new page instead of a the inline AJAX sometimes. It is hard to identify the exact cause and give instructions to reproduce. but it never happens in PageLayout, it was only seen in EntityViewDisplay.
Test with UI Patterns UI
To check.
3. How to format PluginSettingsInterface::settingsSummary() ?
Not done in the MR yet, because we didn't define the expectations yet.
Comment #11
pdureau commentedTested with 1.0.x branch of Display Builder (188c2803f61e1df77b03d9596714fdb086fa807a)
Tested with EntityView buildable (/admin/structure/types/manage/article/display/default/display-builder)
Test 1: inline AJAX first
Same results after rebuilding the cache and not:
Test 2: default widget first:
Same results after rebuilding the cache and not:- I refresh the page
- I click on a Daisy UI Card to open the contextual form
- I click on URL prop to open the detail
- I set
- I click on an other form widget to be sure I am switching focus
- ❌ the value is not updated in Preview Panel
/nodevalue in the URL input widgetMaybe it is because
/nodeis not a "good" value for URL widget:http://example.orgvalue in the URL input widgetSo, we may need to print the AJAX form errors here.
Also, this error seems to break other widgets:
/nodein URL input widgethttp://example.orgin URL input widgetTest 3
Still investigating "I still get an a new page instead of a the inline AJAX sometimes."
Comment #12
pdureau commentedTest again with 3 changes:
Same results so far.
Test 1: inline AJAX
Test 2: default widget
/nodevalue in the URL input widgethttp://example.orgin URL input widgetTest 3
Still investigating "I still get an a new page instead of a the inline AJAX sometimes."
Comment #13
pdureau commentedTest 1: inline AJAX
Fix found by Mikael:
Test 2: default widget
Investigation in progress
Test 3
Investigation in progress
Comment #14
mogtofu33 commentedIssue on Display Builder after investigation for partial possible fixes: #3623623: Contextual form loses clicks and invalid values silently
Comment #15
mogtofu33 commentedComment #16
mogtofu33 commentedIt's the same fix as the one suggested in #3622928-13: UX of the asynchronous component form, with a possible fix for test 2 as well.
Comment #17
pdureau commentedTested with #3623623: Contextual form loses clicks and invalid values silently. It works
Comment #19
just_like_good_vibes