Problem/Motivation
Having too many Paragraphs open causes slow loading time and loss of overview.
We therefore have improved the summary so the user is aware of each Paragraph content and added the "Collapse all" button.
1) If a user creates new content, adding 10 paragraphs, all of them remain open, causing to slow down the UI with every paragraph added. (The main component for slow down is client side loading of many WYSIWYG editors.)
2) If a user edits multiple elements, the previous remain open. The Behavior tab is not yet sticky and it's a messy scroll interaction (scroll up, change tab, scroll down and search to find the right para).
Proposed resolution
Autocollapse will help in all situations.
Remaining tasks
If Autocollapse is enabled, the button "Collapse all" seems to be superfluous and should be hidden.
If a user wants to copy content from nest A to nest B, autocollapse might be annoying. However, if full hierarchy drag & drop works, this is no more needed in most of the cases.
So we need to decide if we still want to keep the "Expand all" button...
Also we might treat containers different from regular items.
We could offer an option so that autocollapse does not affect containers ever, but only leaves.
Should we collapse an open leave inside nest A when a leave inside nest B is opened?
This might change strategy for
#2846557: Change "Collapse" button in closed editing mode to "Cancel"
#2748361: Preview / Closed mode and several level of nesting...
#2829677: Implement a new render element for a collapsible button
Check and update them.
User interface changes
The experimental widget settings will change:
- Default mode is just "open" or "closed"
- New Closed mode dropdown "summary" or "preview"
- Autocollapse setting: None, All, Leaves only
The first two settings changes could also be implemented in a separate issue..
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #22 | autocollapse_all-2896115-22.patch | 37.8 KB | VladimirMarko |
| #19 | interdiff-2896115-17-19.txt | 3.79 KB | VladimirMarko |
| #19 | autocollapse_all-2896115-19-test-only.patch | 23.84 KB | VladimirMarko |
Comments
Comment #2
VladimirMarko commentedComment #3
miro_dietikerComment #4
berdirSome thoughts:
Despite what I said, adding it as a separate setting (with a description saying that it only makes sense in combination with edit mode closed/preview) should actually be much easier to implement, as you don't need to touch the dozen existing closed checks.
Might be enough to just implement this in the submit callbacks, similar to colapse all/edit all
Comment #5
VladimirMarko commentedI left out the "Leaves only" option, as traversing the the form looking for leaves is too complicated right now.
This works, but it still needs tests.
Comment #6
miro_dietikerYour autocollapse now also resets paragraphs that are marked as deleted.
Reproduce: Click on deleted of one Paragraph (disappears), then edit on some other. Suddenly, the deleted reappears.
Comment #7
miro_dietikerQuickly tested, seems to work fine.
Let's care about special container treatment in a follow-up. It can start as simple as not collapsing containers (Paragraphs with children).
Once this is in, awareness & UX is still significantly limited by these issues:
#2895565: Add warning message on collapsed container if changed child
#2893470: Collapsible items with WYSIWYG field always show as changed
Comment #8
VladimirMarko commentedFixed the undeleting bug. This is still missing the tests.
Comment #9
miro_dietikerComment #10
miro_dietikerFollow-up: This should interact with "Expand all" / "Collapse all" button.
Specifically, if i click "Expand all", the autocollapsing should be temporarily disabled until i click "Collapse all".
Comment #11
VladimirMarko commentedThat is already implemented here.
I made the
closed_modeandautocollapseproperties belong to the state of the whole widget, instead of its individual items.Duplicating paragraphs or adding new ones now closes all the others.
Fixed the widget configuration schema.
Tests are still missing.
Comment #12
VladimirMarko commentedNow, there should no longer be attempts to access potentially non-existing array keys in the widget.
Comment #13
miro_dietikerOne new problem here is scroll persistency.
Since we change other items, the view port is likely off.
A follow-up should determine the location of the button pressed and scroll to that after ajax completion.
Comment #14
VladimirMarko commentedCreated a helper function
setParagraphsWidgetSettingsit is both inParagraphsTestBaseandParagraphsTestBaseTrait. In contrast toParagraphsTestBase::setParagraphsWidgetMode, it can handle the new settings for experimental widget.Adjusted the tests in
ParagraphsExperimentalAdministrationTest,ParagraphsExperimentalInlineEntityFormTestandParagraphsExperimentalWidgetButtonsTestto work with the new settings.Added tests for the autocollapse functionality using the new
BrowserTestBasebase class.Adjusted
ParagraphsWidget::__constructto accommodate legacy settings.Comment #16
berdirmissing docs.
GetS, but it's not really getting, Returns might be better?
referencing another method needs to use class::method() should also use as much as possible of the 80 characters.
@param should list the support setting names.
missing empty line above @return.
part of those lines can be moved outside of the if now to avoid duplication.
view access check here is interesting, wondering if that should be checked for summary as well, but being able to edit and not view seems like a pretty weird use case anyway?
this snippet exists in 3, slightly different variations, can we define a helper method for it?
I think it's more common to refer to this just as $entity_type_id. And not sure that we need that extensive documentation on it, anoyne who uses this should know what an entity type is. Also the defaults is a bit confusing, Defaults to node is clearer than an indirect/implicit reference to content _type (which should be node_type in code).
same for the one on the rait.
Also, do we really need this on the base class, can't we use the trait if we have a method that needs it?
should also assert that the preview closed mode is selected in that case.
that looks like an unrelated behavior change?
do we really need administer nodes for this this? The trickery with ParagraphsCoreVersionUiTestTrait is only needed in case the user has this permission, otherwise it is always "Save". The permission is only needed to control status, revision, author, .. of the node.
strange position for a todo, should instead be on the class doc.
What exactly is the other on testing that this doesn't cover yet? @todo could maybe be a bit more specific. And we should create a follow-up issue and reference it.
;;
seems like a cood case for a switch statement, would be easier to read.
Comment #17
VladimirMarko commented@Berdir:
1.
That variable was unused. I removed it.
4.
Added a view access check to the summary as well.
8.
Kept the behavior change, as discussed.
10.
Deleted the
@todoannotation for now.I resolved the other points.
Comment #19
VladimirMarko commentedFixed the tests and simplified
ParagraphsWidget::autocollapse.Comment #22
VladimirMarko commentedRe-roll.
Comment #24
miro_dietikerSo yeah, committed this... Lots of changes, great work! :-)
Created follow-ups:
#2901994: Add edit mode option to expand only paragraph types with paragraph field
#2901995: Scroll to the right position after edit / collapse
All other items seem to be processed already.
Additionally identified this consistency issue about Paragragraph UI text:
#2901996: Capitalise Paragraph(s) in the UI text