Very slow with large text

[ropel]

I've tried embedding ClassicEditor in a clean vue project: everything is OK, but when I paste a long flat text (not formatted, just 800 lines long text) the editor became veeery slow (several seconds just to type a character and see it on screen). The same text pasted in your online (not vue) examples works without problems. After deleting all the text, editing is again responsive.
Removing "v-model" tag (thinking about a slowdown keeping the model in sync) didn't help
Tried with latest Chrome on Windows and Linux
My page is as simple as that:

<template>
    <ckeditor :editor="editor" v-model="editorData" :config="editorConfig"></ckeditor>
</template>
<script>
import ClassicEditor from '@ckeditor/ckeditor5-build-classic';
export default {
  name: "editortest",
  components: {},
  data: function() {
    return {
      editor: ClassicEditor,
      editorData: "<p>Rich-text editor content.</p>",
      editorConfig: {
        // The configuration of the rich-text editor.
      }
    };
  },
  methods: {}
};
</script>

<style>
</style>

[Mgsy]

I can confirm it. I've just loaded 800 paragraphs as initial editor content and the editor became incredibly slow. It doesn't happen in CKEditor 5 without Vue integration.

@oleq, could you take a look at this one?

[oleq]

I confirm the issue. The culprit is this listener

ckeditor5-vue/src/ckeditor.js

Lines 101 to 106 in 1dc60f8

	editor.model.document.on( 'change:data', evt => {
	const data = editor.getData();
	// The compatibility with the v-model and general Vue.js concept of input–like components.
	this.$emit( 'input', data, evt, editor );
	} );

. When there's a lot of data, it takes a lot of time to emit the event. It's getData that makes it slow. We should probably debounce it.

[Reinmar]

Dunno how it works in Vue, so sorry for a potentially stupid question – can the content be retrieved only on demand? Or does Vue implement a sort of two-way-binding so it can't?

BTW, I'd consider something like:

this.$emit( 'input', () => editor.getData(), evt, editor ); 

So, instead of passing data directly in the input event, we'd allow someone to retrieve it if needed. Although, if the consumer would actually read it on every input that would change nothing.

Sorry again if I'm missing the point :D For two-way data binding debouncing seems reasonable.

[oleq]

@Reinmar I'm afraid it is impossible. 2-way data binding depends on actual data and there's no way to do things on demand. However, in the PR I managed to reduce the number of setData() and getData() calls with some caching, which significantly improved the performance.

In the second step, I'm gonna investigate a possibility of debouncing. Stay tuned.

[oleq]

I updated the PR with a debounced #input event. Any feedback appreciated.

[AndrewMast]

It would be nice to know if the editor is currently being "debounced" so a form submission can be delayed. Maybe setting a variable "typing" to true? Or at least setting a "maxWait"...

[Reinmar]

Something like – isBusy? :D If it solves some issues, then it sounds fine to me.

[Reinmar]

BTW, perhaps we could use the PendingActions plugin? It's mentioned in https://ckeditor.com/docs/ckeditor5/latest/builds/guides/integration/saving-data.html#autosave-feature and could help here too.

[awmartin]

I just encountered this issue today in Vue.js. I get a half- to full-second delay while typing, making for a frustrating staccato, stop-and-go experience. Is there a mitigation for this, perhaps not using CKEditor as a Vue component and just loading it as a pure native build?

[Reinmar]

@awmartin could you open a new ticket (and cc me there)? I suppose that there must be an option to disable the two-way data binding or a smarter debounce mechanism (e.g. similar to the one used by autosave).

Also, a related ticket in CKEditor 5 itself: ckeditor/ckeditor5#5812.

[szohaib]

Can anyone share some update on this please?

[danefondo]

What about @ready="onReady" --> onReady(editor) { const data = editor.getData() } and skip the v-model? Possibly tying it to various events through editor.editing.view.document.on("event", (evt, data) => {})

[awmartin]

I forgot to open another ticket. :-(

For context, I use a doc with about 6000 words and a lot of paragraphs and list items to test. The delay is typically 600-700ms when it appears. I think the performance of getData is largely correlated to the number of top-level elements.

To bypass the v-model pattern and remove the hesitation, I had to remove the change:data event here and remove the modelValue watcher. The performance returned, and I just handled saving documents manually. You don't get any Vue.js data binding though.

The other approach I tried was just increasing the debounce interval to 3000ms. It seemed to be okay except for a couple of hiccups, which I couldn't quite track down.

[rolexta]

still very slow on document editor