Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

introduce a "refs" concept

See original GitHub issue

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


What’s the current behavior?

Right now the Point model in Slate has “paths” and “keys” (in addition to “offsets”) to reference a location in the document. Paths are generally more performant, since you can use them to traverse directly to a node. Whereas keys need to be looked up by searching through the entire tree. (We cache keys to try to alleviate this issue, but the caches are invalidated often.)

Ideally we’d use paths in many more places, but the problem with paths is that you can’t guarantee they aren’t stale after an operation is applied because it may have been invalidated by insert_node/remove_node/etc. operations. The same goes for offsets as well as paths, since insert_text/remove_text operations could invalidate an offset as well.

But we might be able to create editor-specific objects to alleviate this…

What’s the expected behavior?

We could create a mutable Pointer model that referenced a point in the editor’s document. When you create it, you pass in the Point you’re wanting to keep an up-to-date reference to.

const pointer = new Pointer(point)

Then, whenever a new operation is applied to the editor, it updates all of the pointers it’s keeping track of, so that they aren’t stale. And at any time in the future, you can access pointer.path or pointer.offset and it will be guaranteed not to be stale.

const { path, offset } = pointer

This could alleviate a lot of the current uses of keys. Even renderNode would be able to receive a Pointer instance since its mutable and referentially equal. (It can’t receive the path right now because every time the path changed it would force a re-render.)

However, this could also help for asynchronous commands, like inserting images, where you need to perform some asynchronous work (eg. uploading the image) before you insert it, and you need to make sure that the insertion point stays updated as more editing happens.

Also if anyone has a better name than “pointer” I’m all ears!

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Reactions:6
  • Comments:17 (16 by maintainers)

github_iconTop GitHub Comments

zhujinxuancommented, Jan 29, 2019

@ianstormtaylor Hi, I am thinking something like this:

We can see query and pointRef share things in common as following ways:

  1. query takes an editor, and then returns a node or other result editor.query(q) => node|any
  2. pointRef takes an editor, and then returns a node. editor.find(pointRef) => node Both are just asking for a result, and neither has side effect.

So we can think a pointRef as a kind of query. We can merge them in one interface, like

const pointRef = new PointQuery(editor, node);
editor.query(pointRef);  // new node

I think the gaining is that we do not need to introduce a new model explicitly. If we think pointRef as a query, we can use query as the single source of asking values from editor.

Another problem is that pointRef.current is changed according to the editor change, which is implicit. Personally, I feel making get a mutable value (and whose mutation is changed by calling editor.doSomething rather than pointRef.doSomething) makes the pointRef.current hard to predict.
When passing an pointRef around, we do not explicitly pass the editor as another argument; it would be hard to track where editor it is when one pass pointRef to another function.

ianstormtaylorcommented, Nov 14, 2018

@Dundercover we wouldn’t, we’d ideally want to keep a PathRef I think.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Refs and the DOM - React
Refs provide a way to access DOM nodes or React elements created in the render method. In the typical React dataflow, props are...
Read more >
A complete guide to React refs - LogRocket Blog
First, let's start with a simple component and grab a node element using refs. import React from "react"; const ActionButton = ({ label,...
Read more >
React: Understanding Refs - Medium
Think of refs as a direct connection between components and DOM elements or class components and their parent components. This connection ...
Read more >
ReactJS | Refs - GeeksforGeeks
Refs are a function provided by React to access the DOM element and the React element that you might have created on your...
Read more >
Everything You Need to Know About Refs in React
Short for “reference”, refs are a way to access underlying DOM elements in a React component. There are many reasons why you would...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found