Add expand/collapse all feature to List View

[getdave]

What problem does this address?

If you are building with the Site Editor it is often nice to hide/expand all the blocks so you can get a sense of the structure of your site. Also it makes it easier to navigation. Currently you have to do this manually. It's laborious!

What is your proposed solution?

Add a UI control to allow auto expand/collapse all sections to the root level.

[ramonjd]

What about showing collapse/expand controls in the header?

Something like this:

[critterverse]

I wonder if we actually need a separate control to expand all/collapse all, especially if we are continuing to iterate on smarter behavior for opening and closing sections.

I think one good option would be for the List View items to always default to collapsed. That combined with the functionality of #35817 (collapsed items expanding automatically when selected on the canvas) would be a big usability improvement without needing to add additional buttons — that way we could keep the List View UI simple/streamlined.

[ramonjd]

I think one good option would be for the List View items to always default to collapsed.

Thanks for this idea @critterverse !

After a very rough test using #35817 as a base, it seems to work well:

Feb-15-2022.09-11-04.mp4

Achieved by setting the default isExpanded state to false here.

const isExpanded = hasNestedBlocks
    ? expandedState[ clientId ] ?? false // Default state is collapsed.
    : undefined;

Dev note: Where there are multiple, very deep trees, some of the collapsed parents do not show. For example, where there are 7 parent nodes with 20 children, only 3 might display.

I think it's related to the logic that hides the lower part of the block list tree until we scroll to it.

It's great for performance, and we should keep it, but it looks like we'd need to tweak the visible block count calculations, which seem to assume that the list is expanded.

cc @gwwar for confidence check.

[gwwar]

I think one good option would be for the List View items to always default to collapsed.

Not sure if I'm misremembering, but I thought folks preferred it open by default to more easily scan the structure of their post/page. cc @jasmussen @talldan do you recall?

If we update the default expand/collapse state that does sound correct that some list virtualization logic assumptions will need to be updated.

[jasmussen]

Not sure if I'm misremembering, but I thought folks preferred it open by default to more easily scan the structure of their post/page.

The archive might betray me (edit: thankfully it doesn't), but my current recollection is wanting these to start collapsed by default ever since the folding was built in. To echo Channing's thought, I think if paried with automatically opening the tree-view to the block selected in the canvas, it might work excellently well for managing the complexity of deeply nested structures.

The addition of buttons is always one of managing interface weight: the amount of buttons present directly translates to the amount of stuff to learn, which is why it's so important to manage the prominence of these controls. One thing we could do as an additional affordance, is to add a keyboard shortcut to folding all trees:

• Figma uses ⌥L
• VSCode doesn't have a shortcut but lets you assign one, and you can also open the command palette using ⌘⇧P then search for "Collapse Folders in Explorer"

[talldan]

Not sure if I'm misremembering, but I thought folks preferred it open by default to more easily scan the structure of their post/page. cc @jasmussen @talldan do you recall?

I can't really recall if I've expressed an opinion on this before, but I don't really mind either way. Probably something I'd have to use before forming an opinion. I suppose it might be frustrating for something like a columns block if it were collapsed by default and the user had to expand every level to see the contents, but it's definitely hard to say without seeing it in action.

[alexstine]

Me personally, I would want to see it collapsed by default but I don't see why adding Expand All/Collapse All would be unreasonable. Could throw it up around the Close button.

[talldan]

It seems like collapsed by default is possible now with @getdave's PR - #39486.

[getdave]

Hmmm...possibly. Except that my PR sets the default state. To reset the state you'd have to reach into the internal state of the component where it tracks what is currently collapsed/expanded 🤔

[getdave]

I'll raise a PR to auto-collapse List View by default and see how folks feel about it.

[getdave]

Ok I've raised an experiment to collapse all nodes by default

#39573

We could add a UI button to toggle to auto expand / collapse all nodes. I experimented with this and it was relatively simple but we'd need to wire up to blockEditor Redux state so that we can trigger the behaviour from outside the component itself.

For now let's decide whether we're happy with defaulting to collapsed.

[jasmussen]

Nice one Dave. It works so well I don't think we need to make this an option. But if we ever need to revisit that, we can put it in preferences.

[Marc-pi]

I don't think we need to make this an option. But if we ever need to revisit that, we can put it in preferences.

i do think an option is needed !!!!

• for everyone working on block template editing (site editor), having a flat view is needed, as explained Site Editor: Always Open List View preference possible regression #47449.
• the current option needs also a wording improvement, to reduce confusion
  • Always open list view > Always open list view sidebar // add sidebar
  • coz not everyone reads the below detailed explanation

[getdave]

I'm just noting that @jasmussen qualified his statement with "I don't think" and "if we ever need to revisit that". Everything is open to change and nothing is set in stone 👍

@Marc-pi It sounds like you have a clear idea of how this should work. Would you be open to considering raising some PRs to:

• update the List View to function as you've suggested?
• revise the wording?

[landwire]

It would be great to have an attribute that you can define in theme.json/block.json to tell a block to be open in the list view. Especially with useRootPaddingAwareAlignments set to false you often need a container block to handle padding etc. where all blocks are inside and are not immediately seen by the person editing the post.
It would also be great to be able to also set this attribute in your innerBlocks template.