Add support for multi root editors

[ma2ciek]

The multi-root editor isn't currently supported within this integration. However, it shouldn't be so hard to improve the integration so it will be able to handle this kind of editor.

Firstly, the editor element(s) should be more configurable:

https://github.com/ckeditor/ckeditor5-angular/blob/1ef5947aa81acb8c692f20dad556e0ec1227224d/src/ckeditor/ckeditor.component.ts#L225-L226

Secondly, the data should be treated a little bit differently while using data.get() and data.set():

https://github.com/ckeditor/ckeditor5-angular/blob/1ef5947aa81acb8c692f20dad556e0ec1227224d/src/ckeditor/ckeditor.component.ts#L269

https://github.com/ckeditor/ckeditor5-angular/blob/1ef5947aa81acb8c692f20dad556e0ec1227224d/src/ckeditor/ckeditor.component.ts#L183

https://github.com/ckeditor/ckeditor5-angular/blob/1ef5947aa81acb8c692f20dad556e0ec1227224d/src/ckeditor/ckeditor.component.ts#L61

Thirdly, the typings should be aligned to these changes.

However, I'm not sure if adding support for multi-root editors will not require any breaking change in the API.

---

If you'd like to see this implemented, react with a 👍

[oleq]

@Mgsy Do you know where this issue originally came from?

[isetpro]

@ma2ciek have you already added this feature ? I cannot use my custom multiroot editor with angular.

[ma2ciek]

@isetpro,

Unfortunately, I'm not sure if the support for the multi-root editor can be easily implemented right now after adding the support for the watchdog feature...

Currently, this functionality can be implemented only by creating multiple editor instances.

[ma2ciek]

I checked the issue, and it looks a bit more complex than it was at first glance.

First, the current snippet with an implementation of the Multi-root editor (https://ckeditor.com/docs/ckeditor5/latest/framework/guides/deep-dive/ui/custom-editor-creator.html) operates on the source elements. This conflicts with the way how the Angular wrapper works. The implementation should be slightly changed to operate on the initial data for each root rather than providing a config with root source elements.

Then, after changing it, there are at least a few ways how the integration with this type of editor can be implemented.

Possible approaches

1A: A new component that would provide support for the special inner “Root” components.

• Should this integration support Watchdog?
• Do we want to support multi-root editors + Context?
• Quite a lot of duplicated logic.
• I’m not sure if adding/removing roots at runtime is supported but with the declarative form, this would be expected to work. OTOH data for the roots would be separated from the roots. So perhaps the data should be a Root’s component property?
• PoC containing an improved multi-root editor implementation and another multi-root editor wrapper component should take ~3-5MD, the whole thing with tests and docs may take ~10MD.

1B: Reusing of the current CKEditor components and adding support for the inner “Root” components.

• Potential blocker: it may be hard to keep the API of the current solution (data as a string vs data as an object in the “normal” usage and 2-way bindings)
• It may be hard to guess how the editor should be initialized by the component as it would depend on the component’s children.
• Hard to estimate as there is a risk of a blocker

\<MultiEditor [config]="editorConfig" ...> \ \

Some content\

\ \

Some more content\

\ \

2: Allowing doing some weird DOM mutations once the editable areas are created and ready to insert somewhere:

onReady( editor ) { for ( const rootName of editor.ui.getEditableElementsNames() ) { // Insert somewhere the `editor.ui.getEditableElement( rootName )` } }

• Probably quite cheap ~3MD if Angular supports it
• Probably unusable for the users

Some more concerns

• Should the multi-root editor work with the Contextfeature?
• Should the multi-root editor work with the 2-way binding and reactive forms?
  • Probably yes. But setting data on the editor might be quite tricky - we would need to set data for the changed roots only. Quick research would be needed here.
• We could reuse the idea in the Decoupled Editor