change Selection points to be nullable

[ianstormtaylor]

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

Debt / improvement.

What's the current behavior?

Because the user can have "not selected anything", and because the document can actually be empty, with no nodes, such that there is nothing to select even... we have this concept of an "unset" selection.

Right now we model this as a Point with path and offset both set to null. But I think this introduces ambiguity into the data model that creeps into lots of places, since all Ranges/Points can then be nullable.

Instead, I think it would be better to model it as:

interface Selection {
  anchor: Point | null
  focus: Point | null
  isFocused: boolean
}

That way the null-ness only ever applies to the Selection model. And if you have a Range or a Point you know they are guaranteed to be filled in.

This will mean people have to check Selection.isSet(), but they really should have been doing it before, we just kind of exit early and other unintuitive behavior when the selection isn't actually set.

[ianstormtaylor]

Related: #2108

[ianstormtaylor]

Actually, I wonder if instead of the points on the selection being nullable, the value.selection property should be nullable instead? The tradeoffs would be...

It makes it even more clear what's going on, since having value.selection == null is really easy to check for. And it also means that if you do have a selection object, you're guaranteed that it implements the Range interface. (As opposed to having to ensure that it's points are nulled out.)

However, it means that we'd need to tweak the operations a bit I think. Because I think it would need to be modeled as three operations (?):

set_selection
unset_selection
update_selection

Which feels a little overkill?

The DOM goes with always having a selection, that may or may not have ranges. But I think this is one of the more awkward parts of the DOM API, so it's not really something I want to take into account, unless we can find a good reason for it.

[justinweiss]

Would you need to have three operations? Could set_selection have properties / newProperties: null?

Mirroring the DOM API would make sense if Slate supported multiple ranges. Which I think we've talked about before. I've only really wanted multiple ranges in one situation (rectangular table cell selections), and I don't think faking it with anchorCell / focusCell is any worse than having it be officially supported. So I (at least) don't feel a strong need for it.

[ianstormtaylor]

That's a good question, we could probably let properties be null. It would make the operation interface a little less certain, but that might be the best way to handle it. Good idea!

[justinweiss]

Or maybe even an empty object, if null makes things weird. I don't think that would be ambiguous.

[ianstormtaylor]

Fixed by #3093.