TIA Engineering: How we built our new rich text editor

Photo credit: Humusak.

Building and facilitating our community, Asia’s tech ecosystem, is Tech in Asia‘s raison d’etre. For us, a big part of achieving that goal is the effective sharing and dissemination of information, expertise, and experience across all sectors of the ecosystem.

To that end, we realized that we hadn’t put quite enough emphasis and time polishing our in-house rich text editor, which any member of the community can use to submit articles that eventually make it onto the front page of our website. As a result, we’ve spent the last three months building a brand-new text editor to facilitate our community goals.

Prior art

When we rebuilt our main website with React, our engineering team faced many challenges in manpower. Our team was half the size it is now, with our founder, Willis, doubling as product manager on top of his duties as CEO. We decided to go with Redactor, a commercially licensed rich text editor that seemed to serve our needs at the time. Later on, we discovered that it just didn’t give our users the kind of experience we wanted them to have. The codebase was by and large out of our control and iterating on a product that didn’t belong to us didn’t make sense from an economic point of view. We had to rewrite.

We eventually decided on Draft.js. Backed by Facebook, it is a framework for building rich text editors that’s powered by React and rock-solid Immutable.js (another Facebook-backed open source project) data structures. Getting up and running with it is quick. Diving deep into the codebase is approachable and provides almost unlimited flexibility. Ultimately, the combination of a functional, “reasonaboutable” data model and accompanying declarative UI approach allowed us to write a complex text editor that fulfilled all our needs in a sane way—and, perhaps, more importantly, a sane amount of time.

Draft.js crash course

As mentioned, Draft.js is backed by several core immutable data structures. They are used to keep the DOM (document object model) in sync with the editor’s internal state, comprehensively including everything from inline styling data to selections. This is important to keep in mind because building a rich text editor involves keeping large amounts of rapidly changing, arbitrary data in sync. Its not an easy task, as anyone who’s had the pleasure (or pain) of building any kind of editor will attest to. The most important are as follows:

• EditorState – This data structure holds all data needed to render the editor component to the DOM and provides several convenient methods for accessing them.
• ContentState – The secret sauce. This contains all data, such as text, links, images, and so on.
• ContentBlock – Each contiguous range of text/content gets its own ContentBlock. For instance, this list item is represented by an instance of this data structure and has the type ordered-list-item, which is used to render the appropriate HTML element for it.
• Entity – These objects function like metadata, allowing you to attach special powers to specific ranges of text like links or Twitter-style mentions.

The Draft.js package itself provides an Editor component, which allows the user to type and manipulate text and accepts a number of props used to handle “events” like specific key combinations (keyboard shortcuts like ctrl/cmd-s, which saves the article you’re typing), to intercept specific characters typed into the editor before they’re actually rendered on-screen.

In combination with React’s powerful declarative way of describing UIs, it paved the way for us to build a truly world-class editor right in the browser. This summary, however, only scratches the surface. We recommend looking through some of the reference implementations in the official Draft.js repo and its well-written documentation.

Features

We wanted to provide an easy and fluid user experience for writers. Our top priority was minimizing the number of steps required for users to manipulate text and providing a distraction-free UI that would get out of the user’s way as much as possible without compromising on a full-feature set. With some elbow grease and a sprinkling of hacks (OK, maybe a little bit more than sprinkling), we think we were able to deliver on this promise.

Floating toolbar

Look ma, no menu!

At the top of our agenda was getting rid of the old-school toolbars that forced users to move their cursor to the top of a text box to format text. This style of text editing has been steadily gaining traction in UI/UX circles, so we decided to implement our own, with modifications that made sense for our users and our platform.

Standing on the shoulders of the giants