Mark model changes which do not affect data

[pjasiun]

There are model changes which do not affect data: selection change, some markers. At the moment, there is no easy way to learn if the change touches data what makes integrations much harder.

First, we should introduce marker API to tell if that marker change touches data. I propose to call it affectsData (true by default). It should be a property in options parameter in addMarker and updateMarker. If the value is set it should be the same for all further operations, as long as it is not changed.

Then, we need to have an easy way to get only these change events which affect data. I propose to introduce change:data event. It will be called for all changes which affect data. If the change will contain only selection change, or markers which do not affect data, then change event should be fired. In all other cases, when data can change change:data should be fired.

[pjasiun]

This is "Solution 2" from https://github.com/ckeditor/ckeditor5-autosave/issues/1.

[scofalik]

I thought that change:data is not backward compatible but it actually is. I am leaving this as a note if others would wonder.

I wanted to argue that I like a flag in Differ or evt more, but actually I don't care that much :). It ca be change:data too.

[ma2ciek]

While adding affectsData to markers is easy and backward compatible, I'm a bit stuck providing the change:data event.

Should I add the affectsData property to the MarkerOperation too? I'm thinking about listening to the model#_change event (or document#change event with the high priority) and checking whether at least one operation from writer->batch->deltas->operations changes the data, so I can emit the event.

[pjasiun]

Should I add the affectsData property to the MarkerOperation too?

Yep. It seems to be the way to go.

[ma2ciek]

Am I right and it only makes sense to fire data:change event on markers changes for markers that are managed using operations?

[ma2ciek]

Answering my own question, no, I'm not. A marker that exists only in the model.markers can still have a dataDowncast converter as @scofalik pointed it out.