consider using paths instead of keys
See original GitHub issueThis 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 thenode
instance itself (with the same performance). Or it could be by passing thepath
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.
Issue Analytics
- State:
- Created 6 years ago
- Comments:19 (10 by maintainers)
Top Results From Across the Web
S3 keys are not file paths - alexwlchan
If you only use normalised paths as S3 keys, it's less risky to treat the two interchangeably. This post is more of a...
Read more >Vault Policy Question - HashiCorp Discuss
Instead make sure you treat each path as a single unit, where all keys have access controlled together. Where there are existing paths...
Read more >Derivation Paths - Learn Me A Bitcoin
This allows you to create a tree of extended keys, with each key having its own unique derivation path from the master key....
Read more >NextJs - Additional keys were returned from getStaticPaths
You're currently passing an array with the params, use the spread operator ( ... ) to reduce it. Docs return { paths: [...blogPosts,...
Read more >Working with registry keys - PowerShell | Microsoft Learn
These are the top-level keys visible under HKEY_CURRENT_USER in the Registry Editor ( regedit.exe ). You can also specify this registry path ......
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@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.
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.