Feature request: add support for more customisations of Draftail

Previously at #4315 / #4436. Related: #4445, #4223.

At the moment, rich text extensions can only customise the following parts of Draftail:

• Blocks
• Inline styles
• Entities (e.g. links, images, embeds)
• Horizontal rules being enabled or not

Here are things that are not customisable and would be very valuable to make customisable:

// Displayed when the editor is empty. Hidden if the user changes styling.
placeholder: "Write here",
// Show undo control in the toolbar.
showUndoControl: true
// Show redo control in the toolbar.
showRedoControl: true,
// List of active decorators.
decorators: [],
// Additional React components to render in the toolbar.
controls: [],
// List of plugins of the draft-js-plugins architecture.
plugins: [],
// Max level of nesting for list items. 0 = no nesting. Maximum = 10.
maxListNesting: 4,

And things that I think would be valuable for some extensions, but probably not that valuable to make customisable just yet, except to allow for experimentation:

// Called when the editor receives focus.
onFocus: null,
// Called when the editor loses focus.
onBlur: null,
// Optionally override the default Draftail toolbar, removing or replacing it.
topToolbar: Toolbar,
// Optionally add a custom toolbar underneath the editor, e.g. for metrics.
bottomToolbar: null,

---

Additionally, for those customisations that would be done with Wagtail’s rich text features, I think it’ll be important that a single rich text feature can map to multiple Draftail extensions – for example, a code-block rich text feature could configure both a block type for code (as is supported already) and a decorator that would do syntax highlighting. I think this might be possible already in the rich text features API, but the Draftail integration of this might not support it.

Implementation

I think the options described above fall in different categories:

• Things that map well to “rich text features” or “rich text formatting” because they determine the formatting available in the editor in a widget-agnostic way. For example an “emoji” feature that maps to a plugin and a control, and we would likely want to enable either site-wide, or per-field
• Things that would ideally map to field or widget attributes, because they aren’t widget-agnostic. For example providing a custom placeholder string for some fields, or hiding the undo/redo controls site-wide.
• It might also make sense to have customisation APIs that are client-side only – for more advanced customisations that we might not want to have APIs for, but where it would still be valuable to reuse existing code.

As a way to assess API designs, here are types of editor extensions that I would like those new APIs to support:

• Indent/dedent buttons. This is the only operation currently doable with the keyboard only, thus unusable on touch screens with virtual keyboards that generally don’t have a “tab” key.
• Paste from Word button – content import features
• Clear formatting button – Resets the editor to plain-text
• Character replacements – smart quotes, convert --> to → like Google Docs
• Slash-commands – interact with the editor, and Wagtail, by typing CLI-like commands with autocomplete
• Emojis – emoji picker, copy-paste support
• Content linting – validation rules, highlighted words
• Content metrics – live-updating measures of the content’s readability, SEO-keywords-ratio, sentiment analysis.
• Single-line input – the editor constrained to a single block, with no block-level formats in the toolbar. Pasting causes the content to be added in a single line.

[adsee42]

Hi, any update on this? I would love to have an “add emoji” button!

[kmohrf]

I’ve published the code as a gist for reference 😃