Ckeditor5: Could toWidget() automatically enable the widget system?

[Reinmar]

Problem

When creating a widget, you need to do two things:

1. Use the toWidget() function to downcast an element to a widget.
2. Load the Widget plugin to enable the widget functionality. This is usually done by adding Widget to your plugin's requires property.

The second step is easy to forget (especially, since we don't have a proper docs for this system yet).

Perhaps, it could be possible to automatically enable the widget system if toWidget() was used.

The advantage would be that you'd have to do less to write a plugin.

However, I think that:

• This would create a direct dependency between toWidget() and the Widget plugin.
• We'd need to ensure that the Widget plugin can be loaded during the runtime. This is certainly possible, but this would change the loading order. Suddenly, that plugin might be loaded at the very end or together with other plugins which may lead to strange situations.
• In CKEditor 4 you need to load the 'widget' plugin manually too. I don't remember problems with that so perhaps we simply miss a guide.

[wwalc]

Maybe the issue is just that this is terribly confusing because it isn't explained anywhere. As a minimum there must be a note in the API documentation next to toWidget() documentation that the plugin must be included separately (also it should be explained in the future in tutorials about writing Widgets).

IMO toWidget() could simply throw an exception if the Widget plugin is not found, pointing to an error code that would explain in details what's the issue. This way we'd not have to introduce any kind of magic for enabling this plugin automatically. The developer that works on the plugin would easily found out where he's doing a mistake and that he misses therequires entry in the plugin definition.

[Reinmar]

Alternative: expose toWidget and toWidgetEditable and other utils on the Widget instance. We can still have the utils.js module, but the most important utils could be available on the plugin instance as well.

This will resolve another issue:

import Widget from '@ckeditor/ckeditor5-widget/src/widget';
import { toWidget, toWidgetEditable } from '@ckeditor/ckeditor5-widget/src/utils';

That I have to have additional, irritating imports.

[jodator]

Alternative

Taking into account a possibility to write plugins without requiring classes it should be done the way you've described IMO. So :+1: for editor.plugins.get( 'Widget' ).toWidget().

[mlewand]

Sounds like a good idea :ok_hand:

What about the existing API? Imho it make sense to remove the old API and keep a single way of doing thins (™), but given it's a very commonly used API, we should do this with care. E.g. deprecate it for like one (or even two) major releases, printing a console warning that it's going to be removed.

[Reinmar]

TODO:

• API changes,
• use the new methods,
• update the doc.

[Reinmar]

One thing's unclear – what about other util methods. There are a couple of them besides toWidget() and toWidgetEditable(). Where should the other end up?

This question needs to be asked in context of the ckeditor5 global where we want to expose many base classes and utils. We want to force people who use toWidget() to get it from the plugin instance (to ensure that the plugin was loaded). But that doesn't apply to isWidget() or findOptimalInsertionPosition() utils. Those can be exposed on ckeditor5 only.

WDYT?

[Reinmar]

Related feature: #7823.