onChangeCalled when ck-editor should have been removed

[ansorensen]

📝 Provide detailed reproduction steps (if any)

In this sandbox, I create an array of ckeditor-react instances. The value of these editors can be changed. Or the entire value the editor represents can be removed from the array.

1. Click the 'x' button by the second editor

✔️ Expected result

The 2nd line (editor with 'two' and its button) should be removed. Expect only the handle remove function to called.

❌ Actual result

There are still 3 editors, now display "one", "three", "three". You can see from the console logs that the new state should be ["one", "three"]. Instead, the onChange is fired and resolve after the removal, resulting in ["one", "<p>three</p>", "three"]

📃 Other details

• Browser: chome
• OS: mac
• CKEditor version: 2.1.0
• Installed CKEditor plugins: out of the box classic build (20.0.0)

---

If you'd like to see this fixed sooner, add a 👍 reaction to this post.

[ansorensen]

Note that there is a work around for setState calls from stale state(using a function in the set call, in order to perform an operation relative to current state). However, it would be even better to not have to worry about vendor libraries making stale state calls if we can figure out how to not trigger a changeEvent when the editor is not truly being changed It's inheriting new data value from the outside.

My actual use case is creating a wiget of that manages an array of data items that include ckeditor5-react as an input for rich text. My ideal interface would simply be:
<widget items={items} onChange={(newItems) => setItems(newItems)} />.

However, because I have to be careful about text changes, I have to implement a more complicated interface:
<widget item={items} onChange={(newItems) => setItems(newItems)} onTextChange={(textChangedItem, index) => setItems( (currentItems) => [...currentItems.slice(0, index), textChangedItem, ...currentItems.slice(index+1)])} />

Without worrying about stale change calls, all that onTextChange logic can actually be done in the widget, leaving one clean interface for updating the state of the parent's array. If I use this widget in multiple context, each context has to replicate that text change logic.

[jodator]

You need to have a reference or a map of the created editors in order to call editor.destroy() on destroyed editor instance.

[Reinmar]

@jodator, I think you misunderstood the example given by @ansorensen. In the React integration, the editor is destroyed automatically when the component unmounts. You should not need to care about this.

Here, the problem, if I understand correctly, is that when you press the "X" button you get:

• the state change: "remove 2nd editor"
• but then, suddenly, the onChange callback of that editor is executed, even though this editor should only be destroyed at that point

So, you get a change event from a component that should actually not be any more available.

As @ansorensen wrote, it's possible to use a callback-based setFoo() form, yet, this seems to be broken in our component or even in CKEditor 5 itself. I checked cke5-react code and the onChange callback is only executed on change:data. I've got no idea why it's executed in this case.

I'm transferring this to the cke5-react repo.

@ansorensen, could you confirm that I understood the example correctly?

[ansorensen]

@Reinmar Yeah, that's accurate. @jodator Your comment might work, i.e. manually shutting down the editor itself directly before removing the React component... However, the fact that the React component cannot handle it's own removal without trying an onChange seems buggy. You would expect the work of destroying the editor instance to be reliably abstracted out for you by the React component.