Add prop to control default expand/collapse state of ListView nodes #39486
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Size Change: +45 B (0%) Total Size: 1.16 MB
ℹ️ View Unchanged
|
getdave
requested review from
gwwar,
talldan,
adamziel,
scruffian and
draganescu
5 tasks
getdave
force-pushed
the
add/list-view-collapse-control-prop
branch
from
d833105
to
9579ed9
Compare
scruffian
reviewed
Mar 17, 2022
packages/edit-site/src/components/secondary-sidebar/list-view-sidebar.js
Outdated
Show resolved
Hide resolved
getdave
force-pushed
the
add/list-view-collapse-control-prop
branch
from
318058a
to
4bb9cdf
Compare
|
Size Change: +43 B (0%) Total Size: 1.16 MB
ℹ️ View Unchanged
|
jostnes
pushed a commit
to jostnes/gutenberg
that referenced
this pull request
Mar 23, 2022
…ordPress#39486) * Add prop to control default expand/collapse state * Update windowing to account for default expanded state * Remove implementation
draganescu
reviewed
Mar 23, 2022
mtias
reviewed
Mar 29, 2022
| block, | ||
| expandedState, | ||
| draggedClientIds, | ||
| isExpandedByDefault |
There was a problem hiding this comment.
Wonder if this prop should instead be called initial and accept collapsed, expanded, or undefined.
There was a problem hiding this comment.
Right so an enum approach. 🤔
There was a problem hiding this comment.
If this is always going to be a binary status (e.g. collapsed or expanded), a non-required boolean with a default value (e.g false) should be fine.
If, instead, there's the chance for this to assume more states, an "enum" (i.e. a list of allowed values) is a better idea.
The variant prop of a Button is a great example of a
"enum"-like prop. This prop was introduced to replace many boolean props (like isPrimary, isSecondary, isTertiary, isLink...)
There was a problem hiding this comment.
This isn't the main List View component, just an internal branch component. On the main component it seems to be called expandNested. I'm not sure why it has a different name when it seems to mean the same thing. I think List View is still exported as experimental, so the API is open to change. It could do with some tidy up as there are lots of __experimental props that should just be removed and treated as the default.
I personally think the expand/collapse feature should be implemented on the TreeGrid component, TreeGrids are supposed to support that natively. Though even then it could still be configurable through ListView.
There was a problem hiding this comment.
Good point! I believe the TreeGrid already has a prop called isExpanded — I believe @andrewserong worked on it recently, so he may be able to confirm if the component is already good as-is, or if we're missing any features.
There was a problem hiding this comment.
I'm not sure why it has a different name when it seems to mean the same thing
Probably a good point. One is more a "status" of a current node, the other is a state for an entire tree.
Let's rename as we see fit to make this clearer.
There was a problem hiding this comment.
So many names :) It feels like isExpanded would be the best to coalesce into.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
This PR adds a new prop (only) to control the default expanded/collapsed state of nodes with the ListView component.
Why?
This PR has been extracted from #39290 where it is required to improve the initial UX of the Navigation Menus in the sidebar. Heavily nested menus make for a poor initial experience and this prop affords the ability to initially show only the top level menu items.
How?
A new prop has been added to
<ListView>calledexpandNested. By default this is set totruein order to match the current default behaviour whereby all nodes are expanded. However by setting tofalseall nodes are be collapsed by default.Note that the windowing algorithm had to be tweaked to account for the default expanded state. It previously defaulted to
true(assumed expanded) which meant it included sub trees in the windowing calculation even if they weren't actually visible. This meant blocks would disappear from the sidebar if you had a large number of subtrees high up in the block list.Testing Instructions
These instructions assume you are tested on a template which has multiple nested blocks. An easy way to do this is to use the Site Editor and the default TT2 block theme.
npm run devon this branch.expandNested=falseprop:gutenberg/packages/edit-site/src/components/secondary-sidebar/list-view-sidebar.js
Lines 62 to 66 in 5c39cdb
It should look like this:
<ListView showNestedBlocks __experimentalFeatures __experimentalPersistentListViewFeatures + expandNested={false} />Screenshots or screencast
Screen.Capture.on.2022-03-16.at.09-31-55.mov