What's the use case of nested updates?

[yf-yang]

I notice that Lexical would move update callback to editor._update if an update is proceeding (see code here) and resolve them later. This patterns appears 3 times during an update:

• After updateFn(), call processNestedUpdates here.
• After transformations, call processNestedUpdates here.
• After update listeners are called, call triggerEnqueuedUpdates here.

I don't quite understand what the use case is. There are three hypotheses:

1. update nested editors during the parent editor update. However, it doesn't make sense because nested editor is not the same editor instance.
2. directly call another editor.update
   • in updateFn() or onUpdate(), I believe it's a bad idea to do so.
   • in transformers. The only scenario I think that is reasonable is a transformation related to more than one nodes, so I have to start another update to modify other related nodes. However, I am not sure if this scenario really exists.
   • in listeners, call updates. The doc mentions a bad design here. Not sure if other scenarios exists.
3. dispatch a command during an update, which triggers another update. It makes some sense, but I still don't think it is a good design. In my understanding, commands should be synchronization events originated from a controller outside of Lexical Editor, such as browser events or command chains. Still I can't find a use case.

So my question is:
Did you allow nested updates just to make some bad designs functionally valid, or are there any specific use cases that a nested update is necessary? If so, what are the cases?

[trueadm]

Nested updates get queued to the end of the existing update. This ensures they run in a deterministic order and ensures update callbacks fire in the correct order too. This is really important, as early on we noticed that updates were being run within an update and all sorts of assumptions would break down. This is especially important as Lexical handles the batching of updates and typically tries to flush and commit changes async, but can also do this sync too depending on certain heuristics.

Either way, this shouldn't really be an observable problem to the developer using Lexical and if it is, I'd like to understand why they're affecting you working the way they currently are.

[yf-yang]

I'm also curious why nested update are not handled instantly, like write a helper function which resembles top several lines of beginUpdate and keeps using pendingEditorState (it involves lots of refactoring, indeed).

[trueadm]

It does handle the update instantly (well sync). It gets batched as part of the same update, it just happens in a difference sequencing order to ensure consistency.

[yf-yang]

Yep, I know what you mean. However, it is possible that someone implements something that hides a nested update inside complicated function call stacks and leads to obscure state dependency of the nested update. For example:

editor.update(() => {
  const root = $getRoot();
  const paragraph = root.getFirstChild()!;
  paragraph.append($createTextNode('First Line'), $createLineBreakNode());
  editor.update(() => {
    const root = $getRoot();
    const paragraph = root.getFirstChild()!;
    paragraph.append(
      $createTextNode('Second Line'), // wrong order!
      $createLineBreakNode()
    );
  });
  paragraph.append($createTextNode('Third Line'), $createLineBreakNode());
});

I must admit I'm picky here 😬, but the fact is that such behavior is not documented and someone needs to read the source of lexical to understand how it happends. At least it should be pointed out that the input of editorState write operations should not depend on previous nested editor updates.
Still, I think the root cause is a bad code design that uses nested updates, the pattern should be avoided, from a framework user's perspective.

[trueadm]

Much of the time nested updates happen because they're unintended. i.e. you do a React setState in an update, which causes an effect to flush and another update to trigger.

[yf-yang]

I see, thanks!