consider using paths instead of keys

This is just an idea.

Right now we use the concept of unique “keys” to keep track of the anchor and focus of a node in a range. And we use them to look up a node by key in the document, for updating, etc.

But keys are local-only, and once we convert the change information into operations, we convert “keys” into “paths”, which are just an array of indices that locate a node in the document—like [2, 1, 2]. Because these don’t rely on local information.

But I was thinking… would it be an improvement if we actually just used paths everywhere? and did away with the idea of “keys” entirely?

---

PROS

• For many things, like “find node by key”, the “find node by path” equivalent would actually be much quicker, since you wouldn’t have to search the entire tree, you’d just know exactly where to descend by just following the path.
• It would also make operations expressed in the same terms as the local changes are applied.
• When inserting fragments or nodes, we wouldn’t have to do the current behavior where we iterate all the new nodes, insuring that their keys aren’t already in the document—which would save performance.
• I think a lot of the logic in the “at current range” transforms that determines what the selection will be after the change has applied could be simplified, because path changes are deterministic, compared to key changes which cannot be guessed ahead of time since they are unique.

CONS

• Finding a node in the DOM currently searches for its “key”, which doesn’t change across renders. But if paths were used instead then whenever a node was inserted, each node after it would have to re-render to update DOM attributes. This could potentially be mitigated by moving the key generation into the view layer, as a view-level concern instead of the data layer. Keeping it around only for locating nodes in the DOM.
• To update a specific node, you no longer have the key reference. This could be solved by either searching for the node instance itself (with the same performance). Or it could be by passing the path to places that need the node. The path approach is awkward though, since it means the information needed can change without the node itself changing. But that’s okay, because comparing by instance would work still I think, so not really an issue.

---

Would love to hear people’s thoughts on this.

[ianstormtaylor]

@zhujinxuan totally agree! I think keys are useful enough in many scenarios that it makes sense to keep them. And instead we can offer both representations.

The only thing that will become slightly more complex is setting the selection properly (since both key and path will be set at once) but I think that can be handled under the covers in most cases already. And with that handled, then consumers can choose to use whatever representation is more convenient/performant for their use case.

[ianstormtaylor]

I’d rather change the range structure to include paths, since it benefits us in other ways, like in operational transform contexts. And then we can get rid of a lot of the need for memoizing/caching other interim data structures that way, which will reduce complexity there.