Size Change: +665 B (0%)

Total Size: 1.04 MB

_{compressed-size-action}

I know @youknowriad has been making some changes to the block editor store of late, so might have some insights into what can be done to improve List View. I noticed the work in #34241 builds a block tree in the reducer, so I'd be curious if List View could now use that instead of assembling a tree in the selector.

It might be possible to drive the whole of list view from that data, which should avoid those rendering glitches. (edit: although having said that, I think the code currently tries to avoid an entire re-render when only attributes change, might have to test if that's still possible).

I also memo'd ListViewSidebar to avoid unnecessary re-renders while typing.

Just noticed that's looks like that's only for the site editor. From what I understand ListView already uses AsyncModeProvider to help already with typing performance.

Do we already use AsyncModeProvider in the list view or not? Did we try to wrap it in <AsyncModeProvider value={true}> to see the impact? We could use a similar technique to the actual block list, where only the visible items are sync and the hidden ones async.

Yep, ListViewSidebar is currently wrapped in AsyncModeProvider in the editor layouts.

@talldan that's probably the reason the updates seem to happen a bit later after addition, removals... is because it's async rendered entirely, maybe if we try sync rendering around the visible items it will be better.

I noticed the work in #34241 builds a block tree in the reducer, so I'd be curious if List View could now use that instead of assembling a tree in the selector.

ListView when used in the sidebar is a little different in that the backing tree really only needs to know when clientIds change rather than when block properties update. I assume this is part of why we try and return a stripped down block tree representation in the first place.

Happy to try out alternatives, but I suspect If we recalculate the backing tree on every block update, all child items will re-render.

Ideally we should aim to not re-render the ListView component while typing (which will trigger all child items to update). This is necessary if we're interested in using framer motion for dragging. Without it or some way to limit the number of child blocks drawn (eg windowing), performance will be a blocker for that one. #34022

Did folks want to spin up an alternative PR? I'd be happy to help profile/test it.

@talldan that's probably the reason the updates seem to happen a bit later after addition, removals... is because it's async rendered entirely, maybe if we try sync rendering around the visible items it will be better.

@youknowriad I tested removing the AsyncModeProvider and you're right, the slow updates go away.

I tried the suggestion of making the selected block update synchronously in #34519, but it doesn't seem to solve the issue. Even hard-coding it to false doesn't work. (See comment below)

Thinking about it some more, the problem isn't that the individual block data is slow to update, its the other way around, instead it's the data at the root of ListView that's wrapped in AsyncModeProvider- the tree of client ids. I think this needs to update synchronously.

Perhaps we can be a little bit more selective about what data is used inside and outside of AsyncModeProvider for ListView. It'd still be a great optimisation to make off-screen blocks and blocks that aren't being interacted with async.

ListView when used in the sidebar is a little different in that the backing tree really only needs to know when clientIds change rather than when block properties update. I assume this is part of why we try and return a stripped down block tree representation in the first place.

Yep, I realised that and updated the comment. I still think there might be a better approach than using a UUID as that's somewhat similar to the cache keys that were just removed.

Ideally we should aim to not re-render the ListView component while typing (which will trigger all child items to update).

It does need to update at some point, some blocks use block attribute for the name shown in List View (Navigation Link, Template Parts), and this can be changed by typing.

Ok, I did manage to iterate on #34519 and get it working. Once I typed out the above comment things became a bit clearer.

Closing this one in favor of #34519. Thanks for taking a look @talldan!

It does need to update at some point, some blocks use block attribute for the name shown in List View (Navigation Link, Template Parts), and this can be changed by typing.

Child components appear to update just fine when backed by global state, but I'm fine with leaving the potential memo for another PR. ( I really only need the performance boost if we switch over to framer motion for drag/animation). You can see this typing updating list view children in the after video at around the 40 second mark.