Ckeditor5: Test instance of editor with editable UI

[oskarwrobel]

Link feature needs editable ui to be fully tested. Right now ClassicTestEditor uses BoxedEditorUI as ui controller and editable ui is not created.

What do we want to do?

• create another version of test editor?
• enhance ClassicTestEditor to use ClassicEditorUI as ui controller?
• or maybe try to use ClassicEditor in this case?
• something else?

[Reinmar]

This touches a very important topic.

The link feature will need to cooperate with different kind of editors. Such which have one editable or multiple various editable elements. Therefore, it's very important _how_ the link feature access the editables. E.g. it must not read it through EditorUI.editable because such a property does not exist in general scenario – it's only defined in case of the specific ClassicEditorUI... Therefore, I'd consider making it protected to underline that it's not a general use property, or, if there's no other way to access editables, I'd standardise it as a property containing a _collection_ of editables. And collection may contain 0+ items of course.

The question is whether such a property is really needed. We need to answer that first. So – how does the link feature access editable now?

[oskarwrobel]

EditableUI.editable property is not needed, bud rendered DOM is needed. Currently ClassicTestEditor doesn't render editable in DOM.

[Reinmar]

Superb. Then the only thing you need to change, IMO, is enabling some editables in your tests. But you can do that directly in your tests, we do not need to change any existing helpers. If we'll see that more feature tests will require some kind of editables to be rendered, then we can expose a helper to creating them.

[Reinmar]

I understood your point, I guess you mean that those lines are missing in the ClassicTestEditor:

    .then( () => editor._elementReplacer.replace( element, editor.ui.view.element ) )
    .then( () => editor.editing.view.attachDomRoot( editor.ui.editableElement ) )

Am I right?

[oskarwrobel]

Exactly.

[Reinmar]

So, I think that you can safely do this in your beforeEach() callback, as a followup of ClassicEditorTest.create().

[oskarwrobel]

Alright. I think there will be more features requires rendered editable in DOM, but like you wrote:

If we'll see that more feature tests will require some kind of editables to be rendered, then we can expose a helper to creating them

Thanks.

[Reinmar]

I'd actually keep this ticket open. It's a valid concern. Just, we don't necessarily should do something now :).

[oskarwrobel]

Just adding

.then( () => editor._elementReplacer.replace( element, editor.ui.view.element ) )
.then( () => editor.editing.view.attachDomRoot( editor.ui.editableElement ) )

in test beforeEach() won't work because ClassicTestEditor uses BoxedEditorUI as UI controller (https://github.com/ckeditor/ckeditor5-core/blob/master/tests/_utils/classictesteditor.js#L32) and BoxedEditorUI doesn't create editable element. Looks like we need another variation of editor if we want to have ClassicEditor with and without editable UI.

[Reinmar]

We realised that since the feature access the DOM through the engine's view anyway, then the only thing which we need in the tests is to create engine view's root. For that we don't need any specific editor and editable UI.