Should we only have if ( isNavMode ) here so it will return contentOnly as a fallback if state.derivedNavModeBlockEditingModes?.has( clientId ) is false? I'm concerned about edge cases where an item isn't in the derivedNavModeBlockEditingModes for some reason, and this ends up returning default.

I guess there are no cases where default is used in Write Mode?

If so, I think what you suggest is probably a good idea, though perhaps disabled as the fallback instead of contentOnly.

Lets handle it in a separate PR given the code for this is already in trunk.

I really like the refactor to move this logic to the reducer rather than spreading it out within the getter.

Just so I understand, is the selling point that previously, every call to getBlockEditingMode would traverse the entire block tree and recalculate. Now it's computed once per state change?

The history is that some time ago Synced Patterns didn't work properly in Write Mode.

I tried fixing that by adding extra code to the getBlockEditingMode selector, but it caused a huge performance regression (#65408 (comment)).

I had to buy some more performance in order to be able to fix that bug, and so I've done that by moving code from the selector.

I think the code is still far from good, but it's a tough problem to solve, and I think it's reflective of how complicated the features that use blockEditingModes are. We should try to simplify both the features and the code where we can.

Can you refresh my memory... is navigation flow related to the former block interaction tool?

Is this for backwards compat?

It is related and not. Write Mode has now taken that tool's place, but the API used is still the same. So navigation mode === write mode.

My brain hurts.

Just so I understand, is the selling point that previously, every call to getBlockEditingMode would traverse the entire block tree and recalculate. Now it's computed once per state change?

Do you think it's worth adding performance tests later?

I could be totally barking up the wrong tree, but let's say we have a document with 10,000 blocks, does this mean we're storing 10,000 block editing modes entries in memory?

I did a very crude js heap comparision using window.performance.memory and I couldn't see any memory degradation comparing trunk with this PR based on a derivedNavModeBlockEditingModes count of 40. Total heap size hovered around 200-280 MB

We do already have performance tests in CI, but then I don't think they test these modes.

I could be totally barking up the wrong tree, but let's say we have a document with 10,000 blocks, does this mean we're storing 10,000 block editing modes entries in memory?

Not really, not every block gets a block editing mode. Only contentOnly or disabled blocks are given one. Most of the time blocks will just be default and then they have no mode set.

But anyway, if we have 10,000 blocks in the post, we'd be storing other state for those blocks, so why not a block editing mode? It is only a short string.

I think the issue is more about whether we update 10,000 blocks on every state change, and we don't.

Here's some of the performance related checks the reducer does:

• Only updates subtrees of blocks - e.g. if a synced pattern is inserted only that pattern and its children have block editing modes recomputed
• Takes care to only update on particular actions - e.g. insert blocks, remove blocks, changing templateLock and others
• Avoids unnecessary store updates as much as possible - e.g. don't replace objects with new references if the data in those objects hasn't changed. This will prevent react renders that don't do anything.

Thanks for the explainer! 🙇🏻