Provide a `getInsertionPoint` query

Do you want to request a feature or report a bug?

Request a feature. (See https://github.com/ianstormtaylor/slate/issues/2865)

What’s the expected behavior?

At the boundary between two text nodes, or a text and an inline node, we have points that are ambiguous. Should the point be at the end of the preceding node? Or at the beginning of the next node?

Different browsers have different behaviors for their native selections. To avoid edge cases and make things easier for plugin devs and slate-react itself, that point should be normalized consistently. I think the default today is always “end of the preceding node.”

Plugins like slate-sticky-inlines would like more control over that normalization, so you can edit the edges of nodes. So this should also be customizable.

To solve both these problems, Slate should use and provide a getInsertionPoint query. This query would take a point and return a normalized point. Slate would use it internally when normalizing points, so plugins could customize it with their own behavior.

[justinweiss]

Yep, we absolutely are – besides filling in key / path if one or the other is missing, that’s all it’s doing today. Until we remove keys, though, I think it’s still useful to do the silent fixes. We expect to do some amount of fixup for selections, because not everything will fill in both key and path. Once we expect selections to stay mostly unchanged, I think it makes more sense to raise.

I can separate out the “fixup” / “fixup and resolve ambiguities” into two different methods – only the second one would take the editor. Then, when it makes sense to raise errors, it would be an easy replacement.

[ianstormtaylor]

@justinweiss that list of places is awesome, thank you! Helps a lot to think about it.

Something it brings up is… I think we’re using resolveRange/Point in some places to pave over “invalid” entries (eg. in element.createIterable, value.setSelection, etc.). Instead, we might want to introduce dumber element.hasPoint and element.hasRange methods, or similar, which can be used to check whether an argument is valid, and throw errors if it’s not. Instead of silently fixing them.

In the past this was more problematic since the points/ranges could more easily be invalid. But I think going forward we’ll be able to more nicely guarantee that methods are always returning valid values for these, so it will be harder for people to pass in invalid ones accidentally.

Just generally throw a few more errors when things don’t line up with expectations.