Introduce the dataChangeEventDisabled property

[Ruud-cb]

Suggested merge commit message (convention)

Feature: Introduced the dataChangeEventDisabled property that will enable performance boost for large documents. Closes #141.

---

Additional information

For example – encountered issues, assumptions you had to make, other affected tickets, etc.

[oleq]

Hi, @Ruud-cb! Can you tell us more about what problem does this PR actually solve? Some use–case or maybe a demo?

[Ruud-cb]

Hi @oleq, follow the reproduction steps in the issue, use the demo-form component. You will notice extreme lag after inserting a lot of text. Then change public disabledOnChangeEvent: boolean = false; to true. The lag during typing/pasting text is solved. Still lag noticeable during leaving the textbox unfortunately, but at some point the new data has to be sent to ngModel.

[ma2ciek]

Thanks @Ruud-cb for the PR.

The lag during typing/pasting text is solved. Still lag noticeable during leaving the textbox unfortunately, but at some point the new data has to be sent to ngModel.

It's something we can do nothing about, the editor.getData() must be called at some point. However, I'd change the property name to something like muteDataChangeEvent, as it touches both, the [(ngModel)]'s control value accessor and the <ckeditor (change)>. Also, could you write a test for this change?

[ma2ciek]

Some necessary changes are described in the above post.

[ma2ciek]

I could not find a way to get the text manually since Editor.getData() does not exist, so I execute cvaOnChange when the text editor blurs.

What do you mean? you can get the data with editor.getData().

[Ruud-cb]

Thanks @Ruud-cb for the PR.

The lag during typing/pasting text is solved. Still lag noticeable during leaving the textbox unfortunately, but at some point the new data has to be sent to ngModel.

It's something we can do nothing about, the editor.getData() must be called at some point. However, I'd change the property name to something like muteDataChangeEvent, as it touches both, the [(ngModel)]'s control value accessor and the <ckeditor (change)>. Also, could you write a test for this change?

I understand that editor.getData() must be called at some point, no problem for me that this happens on blur, it doesn't happen during typing which is great.

I could not find a way to get the text manually since Editor.getData() does not exist, so I execute cvaOnChange when the text editor blurs.

What do you mean? you can get the data with editor.getData().

Sorry for the confusion, Editor.getData() was used in the demo component (or whichever component uses the ckeditor component). As far as I found that doesn't exist. As you commented on my code, indeed that does not exist on the class constructor. I forgot to delete it again because it's now not needed anymore in onSubmit() because (blur) will occur before the user clicks on onSubmit(), right?

It would be favorable if you can adjust the unit tests as it will take you significant less time.

[ma2ciek]

After a while I think about this, such change can be dangerous for big documents as they might be not saved for a long time, as now the saving is done only during the blur event. A debounce-based approach could be a better solution as this should work out of the box, without providing any unuseful properties. Although I'm not sure if that approach will work with Angular Reactive Forms too.

[Ruud-cb]

After a while I think about this, such change can be dangerous for big documents as they might be not saved for a long time, as now the saving is done only during the blur event. A debounce-based approach could be a better solution as this should work out of the box, without providing any unuseful properties. Although I'm not sure if that approach will work with Angular Reactive Forms too.

True, although it is deliberately set by the developer, so one should know. Currently the problem is that no text can be typed in big documents smoothly. And to solve the 'losing data' problem, I would suggest developers to make use of IComponentCanDeactivate, which can produce a warning when trying to reload, go back or exit the page. Of course this is beyond the scope of this project.

[ma2ciek]

True, although it is deliberately set by the developer, so one should know. Currently the problem is that no text can be typed in big documents smoothly. And to solve the 'losing data' problem, I would suggest developers to make use of IComponentCanDeactivate, which can produce a warning when trying to reload, go back or exit the page. Of course this is beyond the scope of this project

But I think that using the debounce effect is safer and it should allow the same editing experience. This is a better approach than "I know it can be an unsafe feature, but I have big documents so I have no option."

[Ruud-cb]

Alright, that's also possible. Only argument against that is that it might occur the user starts typing again exactly at the moment the debounce is fired off. Maybe both, whatever you want :).

[tgv1975]

Hi @ma2ciek, the build is failing on this due to unit test coverage being under 100%, so your changes have not been merged, the large document problem was not solved.

[ma2ciek]

I think that this change is no longer required as the editor.getData() only happens in the 2-way binding and it's a must there - see:

ckeditor5-angular/src/ckeditor/ckeditor.component.ts

Lines 383 to 393 in bdfabf4

	modelDocument.on( 'change:data', ( evt: CKEditor5.EventInfo<'change:data'> ) => {
	this.ngZone.run( () => {
	if ( this.cvaOnChange && !this.isEditorSettingData ) {
	const data = editor.getData();
	this.cvaOnChange( data );
	}
	this.change.emit( { event: evt, editor } );
	} );
	} );