I refreshed this and updated unit tests using a pattern for mocking requestIdleCallback that I implemented in #19282. The tests should now pass again.

However, I'm going to close this out for the following reasons:

• I was unable to demonstrate a compelling performance benefit. I've had difficulty with testing performance in the past, but at least my attempts to measure change via npm run test-performance yields little-to-no-difference.
  • Conceptually, I still feel that this should have a pretty noticeable difference, given that the logic within the callback is called for every state change to every store (every keystroke when typing within a paragraph).
• The implications of asynchronous/eventual persistence may be undesirable, since it runs the risk that persistence may not actually happen if the user closes the page before the idle callback is invoked. For something like a change in a user's preference, the user would expect that if the UI is updated to reflect their new preference, it will have been guaranteed to have been committed.

@ellatrix I know you've been thinking about performance quite a bit lately, so while I don't know that there's anything else to be done around this, I wanted to get it on your radar in case it might strike any inspiration or if you have any thoughts.

Thanks for sharing! I've not really looked at this side of performance so much yet. I do know that @youknowriad recently had the idea to allow batching dispatching actions, which would allow us to batch onChange and onSelectionChange from RichText. Perhaps this is slightly related.

had the idea to allow batching dispatching actions, which would allow us to batch onChange and onSelectionChange from RichText. Perhaps this is slightly related.

I actually tried this, it was super easy to implement. I didn't notice a big difference in performance (probably due to all the recent refactors), so I though it was not worth it for now.