Figure out path to configurable front-end supporting custom components.

[thibaudcolas]

At the moment the package comes with a pre-compiled bundle that can be integrated as a single script tag. This is problematic because some of Draftail still requires JS code to be written for configuration.

Figure out how to expose this properly (npm package of the same name?) so it can be consumed and customised fully.

[thibaudcolas]

Continuing a separate discussion with @loicteixeira,

There are two potential approaches here. High level:

• Make people override or extend wagtaildraftail's JS init mechanism (initDraftailEditor at the moment). Facilitate this by publishing wagtaildraftail on npm to facilitate the reuse of most of its code.
• Expand the current init mechanism to support customisation of more JS things from Python. In concrete terms, this could for example mean adding the ability to grab JS code from an exposed global.

I like the first approach way better because it's more proper dependency management and versioning. The drawback is that we would have to publish two separate packages not one, but that sounds reasonable. We'll see how it goes.

[loicteixeira]

As discussed offline, I'm not a huge fan of asking the user to create their own initDraftailEditor function because:

• there is more than just hooking up custom components happening
• they will be forced to update their own function every time we update the one in the package
• some sort of switch will be needed for the package not to include its version of initDraftailEditor so the user can add its own; failing that the user will need to subclass the widget and overwrite render_js_init to call initMyCustomDraftailEditor and not initDraftailEditor.

I'd rather have the user bundle its custom component in a JS file which can be added to the admin interface with Wagtail's hooks mechanism. On the JS side, this could be in the global space (not so great) or have hooks as well like registerDraftailSource and registerDraftailDecorator (much better). initDraftailEditor can then pick from the list of registered sources/decorators (built-in and customs).

[thibaudcolas]

Discussed offline as well – I like the idea! It makes perfect sense to have a friendlier approach for advanced yet common configuration like adding custom entities.

IMHO we should keep a documented path for "heavy-lifting" type customisations where people will want to override any part of the editor's behavior (documentation only, no special care to having it well supported).