You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
thibaudcolas
changed the title
Figure out path to configurable front-end
Figure out path to configurable front-end supporting custom components.
Mar 10, 2017
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.
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).
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).
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.
The text was updated successfully, but these errors were encountered: