# ModelSchemaCheckChildEvent

typedef

Event fired when the [`checkChild`](module_engine_model_schema-ModelSchema.md#function-checkChild) method is called. It allows plugging in additional behavior, for example implementing rules which cannot be defined using the declarative [`ModelSchemaItemDefinition`](module_engine_model_schema-ModelSchemaItemDefinition.md) interface.

**Note:** The [`addChildCheck`](module_engine_model_schema-ModelSchema.md#function-addChildCheck) method is a more handy way to register callbacks. Internally, it registers a listener to this event but comes with a simpler API and it is the recommended choice in most of the cases.

The [`checkChild`](module_engine_model_schema-ModelSchema.md#function-checkChild) method fires an event because it is [decorated](module_utils_observablemixin-Observable.md#function-decorate) with it. Thanks to that you can use this event in various ways, but the most important use case is overriding standard behavior of the `checkChild()` method. Let's see a typical listener template:

```typescript
schema.on( 'checkChild', ( evt, args ) => {
	const context = args[ 0 ];
	const childDefinition = args[ 1 ];
}, { priority: 'high' } );
```

The listener is added with a `high` priority to be executed before the default method is really called. The `args` callback parameter contains arguments passed to `checkChild( context, child )`. However, the `context` parameter is already normalized to a [`ModelSchemaContext`](module_engine_model_schema-ModelSchemaContext.md) instance and `child` to a [`ModelSchemaCompiledItemDefinition`](module_engine_model_schema-ModelSchemaCompiledItemDefinition.md) instance, so you do not have to worry about the various ways how `context` and `child` may be passed to `checkChild()`.

**Note:** `childDefinition` may be `undefined` if `checkChild()` was called with a non-registered element.

So, in order to implement a rule "disallow `heading1` in `blockQuote`", you can add such a listener:

```typescript
schema.on( 'checkChild', ( evt, args ) => {
	const context = args[ 0 ];
	const childDefinition = args[ 1 ];

	if ( context.endsWith( 'blockQuote' ) && childDefinition && childDefinition.name == 'heading1' ) {
		// Prevent next listeners from being called.
		evt.stop();
		// Set the checkChild()'s return value.
		evt.return = false;
	}
}, { priority: 'high' } );
```

Allowing elements in specific contexts will be a far less common use case, because it is normally handled by the `allowIn` rule from [`ModelSchemaItemDefinition`](module_engine_model_schema-ModelSchemaItemDefinition.md). But if you have a complex scenario where `listItem` should be allowed only in element `foo` which must be in element `bar`, then this would be the way:

```typescript
schema.on( 'checkChild', ( evt, args ) => {
	const context = args[ 0 ];
	const childDefinition = args[ 1 ];

	if ( context.endsWith( 'bar foo' ) && childDefinition.name == 'listItem' ) {
		// Prevent next listeners from being called.
		evt.stop();
		// Set the checkChild()'s return value.
		evt.return = true;
	}
}, { priority: 'high' } );
```

[See source](https://github.com/ckeditor/ckeditor5/blob/master/packages/ckeditor5-engine/src/model/schema.ts#L1338)

<a id="properties">

## Properties

<a id="member-args">

### `args: [ [ context: ModelSchemaContext, def: ModelSchemaCompiledItemDefinition ] ]`

<a id="member-name">

### `name: 'checkChild'`

#### Value

`object`

## Fired by

* [ModelSchema#checkChild](module_engine_model_schema-ModelSchema.md#event-checkChild)

---

Full index of the CKEditor 5 API reference: [llms.txt](llms.txt)