Schema#addChildCheck leads to performance problems

[scofalik]

📝 Provide a description of the improvement

Currently, we can use Schema#addChildCheck() to add custom callback that can affect whether some node is allowed at given place in model structure. The callbacks were meant to be flexible, you can check anything and as you wish in it. Same for Schema#addAttributeCheck().

Unfortunately, this can lead to performance problems if you start using many of them. Why?

Schema is checked very frequently by multiple features. Most commands check either whether it can insert a child at given place or whether it is possible to apply attribute for given selection. This is refreshed after every selection change and model change. With a rich set of plugins, you may have as many as 10-15 checks every keystroke. When multiple callbacks like this are added, this can become 50-100 callbacks each keystroke, and you may start to see downgrade in the editor responsiveness, especially on slower machines.

This is of course not necessary. There's no need for features A,B,C,D... to check whether feature X complies with schema. But since these are very simple callbacks, they are fired each time the schema checked by each feature.

However, we use declarative schema so much, how come it does not affect performance?

Well, declarative schema is checked only for a specified element/attribute. Schema#checkChild and Schema#checkAttribute gets a definition for specified element/attribute and only checks it. As a result feature X checks only feature X rules.

We should try to limit how many custom callbacks are called after each model update.

First, we should add additional parameter to addChildCheck() and addAttributeCheck() that will specify for which element/attribute this callback is declared. We can have this optional to still allow for very general checks but we would assume that these are used very rarely, for complex custom plugins, and maybe there's one or two such callbacks in the editor at most.

We should try to keep checkChild and checkAttribute events for backward compatibility but it might be that the arguments for these events will change, which will affect all addChildCheck() uses. But... as I look at it know, it shouldn't change, as we normalize the arguments in the highest priority listener:

this.on( 'checkChild', ( evt, args ) => {
	args[ 0 ] = new SchemaContext( args[ 0 ] );
	args[ 1 ] = this.getDefinition( args[ 1 ] );
}, { priority: 'highest' } );

So, after adding the extra parameter, we have two ways of solving the performance issue.

First -- instead of simply adding the callback as an event listener, we would save it in an internal map in Schema. Then, when checkChild() is called, before doing default declarative check, we would go through all the registered callbacks for given definition.

Second -- we could use namespaced events. So, if I check schema for paragraph, then checkChild:paragraph is called. In this solution, we don't need to change much how addChildCheck() works. We will simply add callbacks to the namespaced events. However, checkChild() cannot be a decorated method any longer. Instead, it would have to be like this:

public checkChild( context, def ) {
    normalize(); // What happens in highest priority listener now.

    if ( !def ) {
        return false; // As in `checkChild()` now.
    }

    // The default check in `_checkContextMatch()` must be defined as `low` priority callback.
    this.fire( 'checkChild:' + def.name );
}

I am fine with both solutions. One thing that I don't like about the second solution a bit is that we have a method (childCheck()) which behaves much like a decorated method but isn't really, which may be confusing? But this is a tiny nitpick.

[scofalik]

Summary:

1. Schema#addChildCheck() and Schema#addAttributeCheck() have a new optional parameter that allows to register the callback for a specific item or specific attribute.
2. Earlier, when you registered a custom callback, it was fired for every checkChild() and checkAttribute() call. With multiple features and multiple custom callbacks, it could lead to performance problems (lagging when typing).
3. The way how it works is very simple:
   1. If you registered addChildCheck( cb, 'foo' ) it will be called when checkChild( ctx, 'foo' ) is called.
      1. Mind, that checkChild( ctx ) also checks the whole ctx. If 'foo' is inside ctx the callback will be fired too.
   2. If you registered addAttributeCheck( cb, 'bold' ) it will be called when checkAttribute( ctx, 'bold' ) is called.
      1. Mind, that you register attribute check for a model attribute not a model item.
4. Generic callbacks are still available.
   1. Of course, generic callbacks are not recommended as they can lead to performance problems. However, sometimes, they can't be avoided.
5. checkChild() and checkAttribute() are still decorated so you can add listeners to the events. This is not recommended as it can also lead to performance problems.
6. The order of performing checks is as follows:
   1. All callbacks added as events listeners with highest and high priority.
   2. All generic callbacks. Among them, order as added in code.
   3. All specific callbacks. Among them, order as added in code.
   4. Declarative checks.