Deprecate Hallo.js

The last commit on the Hallo.js master was Jun 12, 2015. I’m worried we’re coupling a crucial function in Wagtail (editing text) to a package which seems to have gone off the boil somewhat.

I would suggest migrating to Draft.js, as this supports our aspirations to move to a more React-driven frontend, as well as being more actively maintained and sporting a much nicer API to write plugins against. It’s also used in production by Facebook.

---

Edit: see progress updates at

• https://github.com/wagtail/wagtail/issues/2409#issuecomment-264019860
• https://github.com/wagtail/wagtail/issues/2409#issuecomment-277226739
• https://github.com/wagtail/wagtail/issues/2409#issuecomment-297354841

---

There’s some prerequisite work to do:

• Allow for pluggable rich text editors (so that we don’t backwards-break every Wagtail site) [#2416]
• Create a new JSONField and a widget to control it.
• Allow for HTML export from a structured text editor, so that people who want to store Rich Text as HTML in the database can continue to do so.
• Write an extension to the richtext template filter to parse structured data into HTML.

Check out the Draft.js intro site

Read an article about how Draft represents data on Medium

There’s a solution for saving HTML if required, too: Draft JS HTML export

[thibaudcolas]

Another progress update:

• https://www.draftail.org/ hasn’t evolved much from the last time, but it has gotten more use and also UI/UX reviews. WIP.
• https://github.com/springload/draftjs_exporter has just reached 1.0. It is now feature complete, and documentation good enough.
• The demo of those two at https://draftjs-exporter.herokuapp.com/ is a good example of how they work together.

@loicteixeira and I, with support from lots of others (at the dev sprint in Reykjavík, online, at SL), have worked on glueing all of this together in https://github.com/springload/wagtaildraftail. It is now usable, although still unstable, and a big release is due this week.

The next steps for me are to:

• Define further the scope / backlog of those three projects to foster contributions from outside of Springload.
• Make a blog post detailing the thinking so far.
• Make a public demo of wagtaildraftail to gather further feedback and facilitate collaboration.
• Work on Draftail’s features.

Finally, in the last progress update I was highlighting our thinking around data storage and conversion (in what stage of the lifecycle to convert from Draft.js to HTML, what to store, how).

• The current implementation in wagtaildraftail, storing Draft.js content state as JSON, seems to work well for us so far. (2 projects using this at Springload, close to going live).
• We’ve opened the way to future format transformations by allowing custom exporter backing engines. This is very early, and only goes in one direction Draft.js -> HTML/other at the moment, but it’s a start.
• I will start exploring the HTML -> Draft.js route as part of https://github.com/springload/draftail/pull/50 – note that this will be in JS (for the copy/paste of arbitrary content into the editor), but it’s a start 😃

[thibaudcolas]

Here is a progress update for people interested in this:

• https://www.draftail.org/ is a more stable editor now, although still not feature complete (nor documentation complete).
• https://github.com/springload/draftjs_exporter (Draft.js content -> HTML) is nearly feature complete (documentation in progress too).

We/I are trying to make those two projects usable and relevant outside of Wagtail. It’s not that much more effort, and I think it will make the efforts more viable in the long run. And I think it’s just a better practice to keep the coupling low.

The glue between Draftail and Wagtail is here: https://github.com/springload/wagtaildraftail. This is WIP, pre-alpha, and completely unusable as-is at the moment. It just outlines our current approach to combine the pieces.

One of the big design decisions here is whether the content coming out of the editor gets stored using the Draft.js representation (JSON) or an HTML export of it. The main design tradeoffs are:

• Storing JSON means you have to convert it to HTML (and potentially hydrate it with data from the DB) when rendering the content.
• Storing HTML means that you tie rendering the content to Wagtail.

There are many more tradeoffs (performance, lower common denominator with other editors, etc) that I hope we will get to cover in upcoming documentation. The takeaway is that:

• Draftail, the editor, attempts to be agnostic to what happens to the content once it is saved. It gives you the Draft.js/JSON representation, then up to you to combine it with any of the exporters that are available: https://github.com/nikgraf/awesome-draft-js#common-utilities.
• draftjs_exporter, the Python Draft.js -> HTML exporter, attempts to be agnostic to this too. It can be run when the page is saved, or when it is displayed.
• wagtaildraftail has the opinions. In this WIP implementation, content is stored as JSON and exported to HTML when pages are rendered. We are keen to explore the other scenario as well.