Slate: Using [data-key] on an element somewhere else on the page can cause issues with slate.

[chriserickson]

Took me quite a while to track this down, and it isn't easy to reproduce or write a JS Fiddle for.

On our page, we are using Slate inside a react-bootstrap modal. Behind the modal, we have various document sections, using the [data-key] attribute.

WHen you'd attempt to focus on the slate input, it would instead focus on the section with a matching [data-key] element in the background. (Our section had [data-key='3'], which matched a slate input section).

THe call stack where the problem occured is:
Content::updateSection -> findDOMRange -> findDOMPoint -> findDOMNode$1

The function appears to find the element using a [data-key] selector, but not limiting it to within the scope of the slate control container.

```/**

• Find the DOM node for a key.
  *
• @param {String|Node} key
• @param {Window} win (optional)
• @return {Element}
  */

function findDOMNode$1(key) {
var win = arguments.length > 1 && arguments[1] !== undefined ? arguments[1] : window;

if (Node.isNode(key)) {
key = key.key;
}

var el = win.document.querySelector('[data-key="' + key + '"]');

if (!el) {
throw new Error('Unable to find a DOM node for "' + key + '". This is often because of forgetting to add props.attributes to a custom component.');
}

return el;
}```

[ericedem]

Nice catch! It looks like we have a couple options:

1. We namespace anything attributes in slate that might get query selected, like data-key or data-offset-key with slate somewhere in the name in order to prevent collisions.
2. We change the findDOMNode API to require an element (probably content), and instead we do element.querySelector.

I think 1 would be a fairly straightforward change, so that one gets my vote.

[ianstormtaylor]

data-slate-* sounds good to me!

[ianstormtaylor]

Fixed by https://github.com/ianstormtaylor/slate/pull/3093.