ianstormtaylor / slate Goto Github PK

Since it's recreating those React components every cycle.

Right now since renderMarks is passed a single mark, it's not possible to do things like load custom fonts if a range of text has both italic and bold applied.

Needed for collaborative editing among other things, but could also be useful for plugins.

It would be useful for plugins that want to "normalize" the document in different ways. For example ensuring that it always ends in an empty paragraph. Right now the undo stack will get contaminated otherwise.

• getNextTextNode()
• getPreviousTextNode()
• getFirstTextNode()
• getFirstNode()
• getLastTextNode()
• getLastNode()

Right now if someone overrides the core onKeyDown behaviors, they have to remember to preventDefault(), otherwise the editor can end up in weird states.

Right now some behavior assumes that startKey and endKey are always text nodes and some doesn't. But going forward, I think it's best to normalize a selection once it's applied to a document, so that it always points to text nodes. This will mimic the current onSelect behavior of the contenteditable attribute, and it will also allow for easier "wrap/unwrap" handling.

This would get rid of the need to manually set the isBackward property of the selection.

Fairly sure right now that we're doing too much work. Would be better instead to remove all of the calls, and maybe just keep a list in ./transforms of which transforms actually require normalizing afterwards, since it would be few.

Haven't dug into this yet, but seems like there might be something helpful to do for the concept of "atomic" nodes that should be deleted/selected all at once.

I haven't looked at this closely, but I feel like there are places where .map() is returning odd ordered maps with the previous type of blocks keys, eg:

nodes.map((node) => {
  return node.nodes.first()
})

Right now the code just happens not to use those keys afterwards, but seems better to fix the issue. Either that, or be sure to call .toList() for each of those...

to help implementing #6 since it should act on block nodes, but ignore inlines like links. similar to how contenteditable in a browser would normally works

Getting tedious always writing things like:

const data = new Map(obj)
const block = Block.create({ type, data })
const blocks = Block.createMap([ block ])

When it could just be:

const blocks = Block.createMap([{ type, data: obj }])

Without that much magic going on.

Would need to be kept in sync with .normalize(), but we're already doing that as it is for text nodes. Might reduce a lot of the parent = ... reaching up the tree logic that needs to happen.

Right now I think there are a few spots where top-level texts will break. If this is fixed, the "fragment" concept can just be the same as a document.

It would be useful to solve this in core, just like in the DOM where img or input tags can be "void" to have no children. Right now it's hard to do this since the selection state gets wonky quickly when trying to add void / non-content-editable pieces to the editor, like an image.

Before doing #10, we need to differentiate between type and kind. In the new model, kind will be the type of model, whereas type will be a user-specifiable field that applies to block and inline nodes.

So we'd end up with four kinds of nodes:

• document
• block
• inline
• text

Right now, the API for decorators feel nice in that it just maps directly to marks that get added to ranges of text. But the current implementation is very slow, such that it causes noticeable lag used. Fairly sure there's a way to speed it up, and that it's not inherent to the way the API works, just needs to be investigated before they will be fast.

they should be separate from state, and have an .apply() method or similar, so that it's clear where save boundaries are for undo/redo

Right now the helper in normalizeKey is causing extra work since it prefers the string key which then has to be looked up again. Would be better to flip it, to prefer to node so that it doesn't have to keep looking it up again.

Seems like very often you need to use Editor and either Raw or State or something else, so it ends up being cleaner to just make everything a named export I think.

I haven't looked into this too deeply, but we might be able to get away with just having Leaf and not need the extra <span> from each text.

Right now there are lots of cases where they are re-rendering needlessly. This should be a pretty low-hanging fruit performance boost.

Similar to #25, we're calling selection.normalize() in lots of places right now, when it would be better to figure out exactly where it needs to be called to save cycles.