search

ianstormtaylor / slate

A completely customizable framework for building rich text editors. (Currently in beta.)
http://slatejs.org
MIT License
29.8k stars 3.24k forks source link

Declare which schema rules should be evaluated (or not) based on slate command #2405

Open cameracker opened 5 years ago

cameracker commented 5 years ago

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

Feature

What's the current behavior?

Current behavior is that all of the schema rules are evaluated on every command, including insertText, even when many schema rules can only be violated in response to a finite set of commands. The symptom of this is that editor performance is negatively impacted by having to check rules that are not always relevant to the current interaction with the editor.

What's the ~expected~ desired behavior?

The schema should have a way of identifying rules that do not need to be evaluated at all in response to certain commands. Consider a schema that merges two lists. There is no way that this rule will become invalid on an insertText operation, therefore even checking for the violation is superfluous.

ianstormtaylor commented 5 years ago

It might also be good to start by just seeing what is causing the performance bottleneck and trying to remove it, rather than add complexity to schema rules.

cameracker commented 5 years ago

Yeah this is good advice. I think part of the problem I'm running into is that I had several schema rules that were operating on the document level but until this latest upgrade were not running on insertText because of that specific normalization suppression in that function. Now that insertText is (correctly in my view) firing off normalizations, I'm now observing performance issues related to the way the rules are written.

The inspiration for this issue is that the intention behind suppressing normalization in insertText was that most people (probably) didn't need the document to be normalized just after inserting some text, and some processing could be saved. I think this is still probably largely true for a lot of schemas people will put together, and in general it seems more useful to be able to fire off a subset of only the related schema rules when a command is executed.

Thanks for the feedback though, I will hopefully have resolved my upgrade soon and will have a better set of examples for where this would be useful.

ianstormtaylor commented 5 years ago

@CameronAckermanSEL totally, that makes sense. We'll probably need to do both honestly. If you think of any ideas about what the API could look like for this (or anyone else does) I'd love to hear it!

e1himself commented 5 years ago

I think the real issue here is performance.

We need better performance, not necessarily by means of declaring which schema rules should be evaluated or not. So there might be other options to achieve the goal.

It might also be good to start by just seeing what is causing the performance bottleneck and trying to remove it, rather than add complexity to schema rules.

:+1:

cameracker commented 5 years ago

The idea behind this suggestion is to gain some additional performance improvements that are not currently within reach by granting some control of what schema rules fire in response to certain editor events to the developer.

While we can optimize away slowness in the schema, there will always be the lingering concern that my structure schema rules (which are incidentally most of my schema rules) don't need to get evaluated when I insert a text character into a block, and I should have some mechanism of ignoring them for this specific event.

bryanph commented 5 years ago

One thing that might help in the future is if we would switch to normalization at the operation-level. So instead of normalizing a potentially deeply nested node we would normalize the operation and "correct" the operation if necessary. Besides performance, this has another advantage of normalization not causing the addition of extra operations after invalid ones. This way all operations that are in the history are guaranteed to be correct and in line with the schema's rules.