Improve 'sameNodes' comparator inside 'renderer._updateChildren'

[f1ames]

Stumbled upon when debugging composition:

1. Set editor content to <strong>^Bold</strong>:

Model: <paragraph><$text bold="true">[]Bold</$text></paragraph>
View: <container:p><attribute:strong>{}Bold</attribute:strong></container:p>

2. Type anything, e.g. a

The renderer._updateChildren method checks diff between actualDomChildren and expectedDomChildren returning [ 'insert', 'delete' ] set of operations, while both actualDomChildren and expectedDomChildren represents exactly same HTML - <strong>aBold</strong>.

If the sameNodes comparator would be able to handle such situations we would be able to skip reinserting same nodes (should also help with composition). Preventing situations like (the intermediate state after insert and before delete):

Checked on ckeditor5-core/tests/manual/article.html manual test with Chrome 64.0.3282.167.

If this issue was already discussed in the past somewhere just point me to the right direction, but I haven't found any similar ones. Could help with #802

[Reinmar]

The diff is based on a simple instance comparison. I agree that it'd be perfect if it was smart enough to know that it should not change the DOM when the expected child is identical. However, this is really tricky.

One issue that we'd need to solve is updating the bindings. We maintain a view <-> DOM elements map. Since expectedDomChildren contains some new DOM element instances, it means that the view document contains new view element instances as well. If we'd keep the old DOM elements, then we'd need to fix the bindings so the existing view elements point to those old, existing DOM elements. That might actually be possible. But this is a big change. Plus, the diff would need to be improved.

However, you may also ask why does the view document contain new view element instances? Because conversion from model to view does not care about such things. It purges whatever it needs. And that's fine. During conversion, the entire view should change freely. The smart rendering should be hidden inside the renderer.

Which means that we'll need to make this change one day. Renderer must be smart. Renderer must avoid doing DOM changes. However, even if we'd land this there's a big chance that IME would be still broken in some cases. E.g. by inline and block filler removal and small selection fixes which will frequently happen on inline element boundaries. That's why those are first two points in #802 (comment).

[f1ames]

I mentioned it because of two things I encountered while working on blocking selection during composition:

First one is the fact that even if we stop selection manipulation during composition, it may be affected by reinserting the DOM elements - I described it in more details in https://github.com/ckeditor/ckeditor5-engine/issues/460#issuecomment-370736424.

I also checked if preventing only selection manipulation during composition will solve any of the reported issue (from #802) and it seems that non of this issues can be solved by only this change (unless my validation method was invalid). In most cases both selection and element rerendering is the cause.
From what I see rerendering DOM also affects selection so this two mechanisms are strictly related (so modifying how updating nodes works will also affect how selection updating works - but not the other way around).