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

Overall, I like the concept and the direction, thank you for putting this masterpiece together with such detailed documentation and test plan!

A couple high-level thoughts:

While most of the LexicalCaret methods are simple, this adds a major of piece of opinionated API that (will) touch on most of Lexical core methods, I'm curious how complicated it will for contributors to familiarize with it. Before that, selection and LexicalNode were mostly independent. However, it does make some of the core implementation easier to read when the verbose iteration logic is abstracted away, and your LexicalSelection fixes prove this.

Selection and LexicalNode are still very much independent. NodeCaret has nothing to do with the selection specifically, it's an abstraction for finding a node adjacent to some origin node in some specific direction. It's just a building block that can be used to come up with things like selections (e.g. using two PointCaret you can make a CaretRange which is basically a more robust RangeSelection).

Even in situations like TableSelection, NodeSelection, etc. you still need to do document tree navigation and in those cases it will be very useful to have these abstractions at hand. In some cases RangeSelection could be used for that but it's awfully hard to work with them without setting the editor's selection which is counter-productive when you are working with another selection type.

Naming wise, @fantactuka proposes the use of cursor instead of caret. Previously, we introduced block "cursor" selection, I wonder why we decided to name this one caret instead.

The words have very similar meaning, and I think it will be hard to avoid some confusion no matter which name is chosen. I settled on caret specifically because it is used more commonly for text, where cursor is the more general term. Cursor is used in other contexts in lexical already which is why I avoided that (blockCursor, css cursor for the mouse pointer, etc.). See also:

• Caret
• Caret navigation

I think a more accurate way to think of it is that NodeCaret/PointCaret are a way to bring something like PointType (but more fit for purpose) to everywhere in Lexical in a way that does not depend on RangeSelection. Right now RangeSelection is too intertwined with LexicalNode and document navigation in general. For example there's probably been a hundred times where I want to programmatically create a selection that spans multiple nodes but the APIs to do that are just miserable because calling .select(...) on a node sets the EditorState's selection as a side-effect and always sets both points when you're really just trying to get an anchor or a focus. In order to get an anchor or focus from a node with NodeCaret you just create one with one function call.

Will merge this after v0.24.0 so there's some nightly releases before it goes live

Latest couple commits:

• Resolve conflict with main
• Added more docs, and copied and pasted the examples from the docs to find a small mistake or two
• Added flow types for the new stuff
• Refactored StepwiseIteratorConfig to use a hasNext guard instead of stop so the types didn't have to lie sometimes (this is one of the things that flow does better than typescript with implies)

Should be good to merge once re-approved