Add flushSync option to update()

[fantactuka]

This would allow synchronous updates (e.g. for tests and some cases of headless mode):

editor.update(() => {
  ...
}, { flushSync: true });

// Update and listeners are already executed

[trueadm]

I don't think we want to call it flushSync as this would encourage people to always use it. discrete would be more accurate and follow the terminology browsers and React uses for the same behaviors.

[fantactuka]

discrete

Thought react uses flushSync, but discrete sounds good too

[fantactuka]

@trueadm Another option I had in mind is to add $flushSync() util to be called within updateFn. It might make it even more explicit than a flag

[trueadm]

Thought react uses flushSync, but discrete sounds good too

That's true, I guess I meant as the underlying terminology. I'm just worried everyone will do this rather than use async updates.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
lexical	✅ Ready (Inspect)	Visit Preview	Oct 17, 2022 at 2:40AM (UTC)
lexical-playground	✅ Ready (Inspect)	Visit Preview	Oct 17, 2022 at 2:40AM (UTC)

[trueadm]

Another option I had in mind is to add $flushSync() util to be called within updateFn. It might make it even more explicit than a flag

Gets complicated with nested updates though and what should happen when others happen etc.

[fantactuka]

Another alternative would be to have it in a headless mode as a default (so far it's the main usecase), since there's no benefit from batching as there's no dom reconciliation. Then can just rely on _headless flag. Although it adds implicit inconsistency between .update calls & updated state availability right after it

[acywatson]

That's true, I guess I meant as the underlying terminology. I'm just worried everyone will do this rather than use async updates.

Would this really be a problem? You'd have to go looking for this API and then maybe we could ameliorate the problem with some documentation around valid use cases for it.

[trueadm]

Lexical used to have a flush sync flag, we actually killed it. Everyone used that in their tests and then their production surfaces were in async causing a different behavior.

[fantactuka]

Lexical used to have a flush sync flag, we actually killed it. Everyone used that in their tests and then their production surfaces were in async causing a different behavior.

With that I don't like neither of solutions anymore :) But using internal _flushSync flag is even more confusing, so I'll move on with discrete