Skip to content

Conversation

@JosVelasco
Copy link
Contributor

@JosVelasco JosVelasco commented Jan 1, 2026

Closes #53004

What?

Adds a Gutenberg experiment that implements dynamic expansion depth adjustment for the List View. When enabled, the List View automatically collapses deeper nesting levels to maintain optimal performance and usability.

Why?

The List View can become difficult to navigate and slow to render when dealing with deeply nested block structures (issue #53004). Users need a way to work with complex page hierarchies without performance degradation or overwhelming visual clutter.

How?

  • Implements dynamic expansion as a Gutenberg experiment (off by default)
  • Adds experiment toggle in WordPress Admin → Gutenberg → Experiments
  • Exposes user-configurable "Maximum auto-expanded blocks" setting in Editor Preferences → General → List View (default: 20, range: 5-200)
  • Uses performance optimizations: early exits when block count is within threshold, leverages Core's cached getGlobalBlockCount() selector
  • Includes debug mode for development (DEBUG_DYNAMIC_EXPANSION flag in code)

Testing Instructions

Test Case 1: Enable Experiment and Basic Functionality

  1. Go to WordPress Admin → Gutenberg → Experiments
  2. Enable "List View: Dynamic expansion"
  3. Create a post with nested blocks (e.g., Group → Columns → Group → Paragraph)
  4. Add enough nested blocks to exceed 20 total visible items
  5. Open List View
  6. Expected: Deeper levels are automatically collapsed to keep visible count ≤ 20
  7. You can manually expand/collapse as needed

Test Case 2: Settings Panel

  1. Open Editor Preferences (⋮ menu → Preferences)
  2. Go to General tab
  3. Look for "Maximum auto-expanded blocks" section under List View
  4. Expected: Number input field visible (range 5-200, default 20)
  5. Change value to 10
  6. Refresh page and open List View
  7. Expected: Expansion behavior now uses the new threshold of 10 blocks

Test Case 3: Small Pages

  1. Create a simple post with < 20 blocks
  2. Open List View
  3. Expected: All blocks fully expanded (no collapsing needed)

Video

expand-nesting.mp4

@github-actions github-actions bot added [Package] Block editor /packages/block-editor First-time Contributor Pull request opened by a first-time contributor to Gutenberg repository labels Jan 1, 2026
@github-actions
Copy link

github-actions bot commented Jan 1, 2026

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @JosVelasco! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

Implements automatic depth adjustment for List View based on block count
as a Gutenberg experiment. When enabled, the List View will automatically
collapse deeper levels when the visible block count exceeds a configurable
threshold (default: 20 blocks).

Key features:
- Gutenberg experiment with admin toggle
- User-configurable max visible blocks setting (5-200, default 20)
- Performance optimizations with early exits and Core selector integration
- Settings panel in Editor Preferences > General > List View
- Debug mode for development (DEBUG_DYNAMIC_EXPANSION flag)

The feature improves performance and usability for sites with deeply
nested block structures while maintaining full expansion for simpler pages.

Fixes WordPress#53004.
@github-actions github-actions bot added the [Package] Edit Post /packages/edit-post label Jan 6, 2026
@JosVelasco JosVelasco marked this pull request as ready for review January 6, 2026 23:57
@github-actions
Copy link

github-actions bot commented Jan 6, 2026

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

  • Required label: Any label starting with [Type].
  • Labels found: [Package] Block editor, [Package] Edit Post, First-time Contributor.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

@github-actions
Copy link

github-actions bot commented Jan 6, 2026

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: JosVelasco <josvelasco@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: andrewserong <andrewserong@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@Mamaduka Mamaduka added [Type] Enhancement A suggestion for improvement. [Feature] List View Menu item in the top toolbar to select blocks from a list of links. labels Jan 8, 2026
@Mamaduka
Copy link
Member

Mamaduka commented Jan 8, 2026

Thank you, @JosVelasco! This is an interesting experiment.

The List View renders a fixed number of items initially, using virtualization for large lists. I'm not sure if providing a way to set a threshold above this number would be beneficial. Maybe instead of providing this option, we use a smart default that matches the maximum number of initial items.

Here's the code responsible for this logic:

// List View renders a fixed number of items and relies on each having a fixed item height of 36px.
// If this value changes, we should also change the itemHeight value set in useFixedWindowList.
// See: https://github.com/WordPress/gutenberg/pull/35230 for additional context.
const [ fixedListWindow ] = useFixedWindowList(
elementRef,
BLOCK_LIST_ITEM_HEIGHT,
visibleBlockCount,
{
// Ensure that the windowing logic is recalculated when the expanded state changes.
// This is necessary because expanding a collapsed block in a short list view can
// switch the list view to a tall list view with a scrollbar, and vice versa.
// When this happens, the windowing logic needs to be recalculated to ensure that
// the correct number of blocks are rendered, by rechecking for a scroll container.
expandedState,
useWindowing: true,
windowOverscan: 40,
}
);

cc @andrewserong

@andrewserong
Copy link
Contributor

+1 this is an impressive exploration. It'd be good to loop in some designers for feedback when you're ready as the behaviour in the list view can be quite challenging to get intuitive, but I appreciate that a lot of thought has gone into this one!

Something I'm wondering from looking at the code change — is there a way to simplify this, i.e. for it to be a binary "expand all if less total blocks than a threshold" rather than figuring out the exact level of depth to expand to? Or does it feel key that it should take care to handle particular levels of depth? My main concern is about whether the additional complexity is worth the benefit, though the logic here is quite clever.

@JosVelasco
Copy link
Contributor Author

Hi @andrewfleming and @Mamaduka. Thanks for your comments! Before experimenting further, please take a look at this simpler alternative.
#74507

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

[Feature] List View Menu item in the top toolbar to select blocks from a list of links. First-time Contributor Pull request opened by a first-time contributor to Gutenberg repository [Package] Block editor /packages/block-editor [Package] Edit Post /packages/edit-post [Type] Enhancement A suggestion for improvement.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

List View: Smartly expand the nested blocks

3 participants