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

I don't personally have any domain expertise with bidi text so will have to wait for some feedback from other contributors to see what the ideal semantics are. I agree that it seems like it should primarily be a derived/computed property, but without full context I think we need to start with declaring what the DOM should be in the ideal scenario and then work backwards to come up with an implementation strategy that matches that expectation efficiently.

I suspect that probably the complexity here is to make sure that if the user is entering rtl text in one paragraph and then creates another paragraph then it should probably start off as rtl even when empty so the selection is visually in the expected place?

Some questions to answer:

• Is there a use case for persisting dir outside of the DOM?
• What should it be set to when ltr and rtl text ends up in the same element?
• How should that get reconciled when the timing of those events are interleaved due to collab?

@zurfyx - who is the best resource for this?

I haven't looked deeply into this but we discussed it briefly on a call this morning. I would lean towards whatever the best long term solution is going to be, when updates to the DOM are made the reconciler is already processing essentially the whole tree top-down (skipping subtrees that are not dirty) so maybe reconciling the direction in a deterministic way could be done coming back up the tree at render time? The directional information could be cached on each DOM node as a cache.

I think the real question is whether the ltr/rtl decisions need to be persisted outside of the DOM and if it makes sense to honor them as an override or have the reconciler update them in-place? Like before, I don't have much direct bidi experience to know what the correct UX and expectations are around this.

if the user is entering rtl text in one paragraph and then creates another paragraph then it should probably start off as rtl

That definitely makes sense. A natural follow-on question is what happens if the sibling paragraph then changes to LTR? What if you have N blank paragraphs? Thinking about the collab case, my gut feeling is that the blank paragraphs should stay as they were when they were created. Say User 1 has their cursor on the blank paragraph, and User 2 changes the first paragraph's text to LTR -- it would seem odd to have that move User 1's cursor to the other side of the page.

I can also see it getting tricky when you have cases such as nested lists - if you're skipping non-dirty sub-trees, you could end up with parent elements that have one direction (because a sibling changed) and children with another. However...

reconciling the direction in a deterministic way could be done coming back up the tree at render time

I haven't looked into any of the rendering code yet -- maybe what you're suggesting would solve the nested list case.

the real question is whether the ltr/rtl decisions need to be persisted outside of the DOM

Agree. That said, given that the current implementation derives direction from text content (i.e. ignores anything persisted), would you be open to a PR that implements the second suggestion above ("Mark __dir as an excluded property for Yjs syncing")? Alternatively, we could just add it to our own excludedProperties, but this feels like something that, if safe to do, should be done in core Lexical.

NB: For context, this came up because we have a custom DecoratorNode on which we set a property based on some Redux state, where that property is in excludedProperties. However, the act of setting that property marks the node and its parents as dirty -> triggers the direction reconciliation -> updates Yjs -> gets recorded as the document being modified.

It probably makes sense to have __dir be excluded in yjs as a first step, as long as there are tests to show that it behaves the way it's expected to. I can't imagine that breaking anything, because AFAICT you can't really explicitly set __dir and expect it to stay that way because reconcileBlockDirection is unavoidable. I have a hard time imagining ways that it would make things worse than the status quo.

There isn't really anywhere to associate versioned data (or cache computed data) with a LexicalNode without marking it as dirty, since they're copy on write and the connection to the children are indirect. The previous version has to be considered frozen (in __DEV__ they will actually be frozen) since that computed property could depend on anything else and might not make sense in the past.

PR updated to exclude __dir from Yjs syncing with associated test case. I've also left in a test case for the reconciler to at least document the weird behaviour with activeEditorDirection.

(will wait for all extended collab tests to run before merging)