Expose ckeditor5-widget API via plugins

[Reinmar]

Provide a description of the task

The widget API is available in the DLL, so it doesn't have to be used via plugins. However, we were considering #1012. Also, there's #7823 (a bit related). Hence, it makes sense to expose its API via the plugin.

As for cloud-services-core, we want to remove it from the DLL as it's a link to CF (commercial offer) –> see #8811.

The steps here:

1. Make an ADR on how this API can be exposed (Figure out how to expose utils API via plugins #8925)
2. Apply changes to widgets and cloud-services-core

Then, we can do #8811.

[Reinmar]

Some notes:

Widget – requires WidgetCore, exposes widget utils
WidgetCore – contains the current Widget

* Pros: we get rid of the utils file and keep the utils separated from the core logic.
* Cons: another BC.

CloudServicesCore will expose only classes (constructors). So it's a bit differnt case.

editor.plugins.get( 'Widget' ).utils.toWidget()
editor.plugins.get( 'CloudServicesCore' ).api.Token

editor.plugins.get( 'CloudServicesCore' ).Token
editor.plugins.get( 'Widget' ).toWidget()

[pomek]

RFC (as ADR): #8925.

[Reinmar]

Exposing CS-core was part of this ticket, but it's done already. So, the remaining thing here is ckeditor5-widget.

[pomek]

What about WidgetTypeAround utils that after the refactoring, will be used by the Widget class?

• ckeditor5/packages/ckeditor5-widget/src/utils.js

  Line 273 in a127c97

  const typeAroundFakeCaretPosition = getTypeAroundFakeCaretPosition( selection );

• ckeditor5/packages/ckeditor5-widget/src/widgettypearound/utils.js

  Line 73 in 6b6ba8a

  export function getTypeAroundFakeCaretPosition( selection ) {

Should those be moved to the WTA plugin? However, the dependency tree is getting more chaotic.

[pomek]

The entire idea looks good on the paper. However, when it goes to the implementation, it gets a little messy.

If we remove the widget/widget/utils.js file and move all its content to be available as the Widget plugin, we need to pass the plugin to all packages' utils that used the removed file previously.

The easiest way to do that is by adding another parameter to functions. See the examples below:

1. a2355fb#diff-791a5172df9592c30ca21886852e4aa79e37df4035d7dde4e6d2a03d6bf3759fR55
2. 93272ae#diff-029e7b90fa7085a07f7bd6ecf2644c9f0853f199da8753293205b54c861a3aeaR74
3. 461825f#diff-f07d66ad40e55d8059a70782a8b070adba4662337754210b8216e72be8f09ac4R105-R121
4. c748584#diff-eca4b6baa2b8777be524f75f5cec843ebf74700b0c40b79d89f8ac4645642907R84

Adjusting packages like html-embed (1) or page-break (2) is not too difficult. Internal utils have been aligned and packages work fine. However, table (3) or images (4) features are more complex, and passing the Widget plugin through all layers makes our utils uglier. Also, it brings many minor breaking changes. I didn't mention tests, that also (unfortunately) started to fail and require adjusting assertions. My all changes are available on the #i/8901 branch.

I know, I suggested removing the utils file in the ADR. But it will require much more changes that we couldn't predict when writing the idea.

Right now, I'd like to keep the utils file and add the utils' methods to the Widget class. We could adjust simple cases like (1) or (2) but the more complex shouldn't be touched.

However, in the documentation, we should suggest using the new method – using the Widget class and utils that the class provides.

[CKEditorBot]

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may still be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

[CKEditorBot]

We've closed your issue due to inactivity over the last year. We understand that the issue may still be relevant. If so, feel free to open a new one (and link this issue to it).