An Ultra Quick Guide to Quill.js
How to set up a rich text editor in your React App.
Recently, I’ve been working on building a WordPress-style blog from scratch using React. And before we get started, I realize that this is somewhat of an inherently trivial exercise because WordPress already exists. And as it turns out, although it can be fairly clunky to work with at times, if you’re looking to get a fully customizable blog up and running with built-in SEO, it’s probably prudent to just use WordPress. I honestly can’t really think of too many benefits of doing what I’m doing, other than the pursuit of knowledge, and self-betterment of course!
Anyway, while building out said blog, aside from some user-specific routes, the one real feature that seems somewhat tricky involves the actual posting of blogs by the Admin. Previously, I had only ever dealt with apps where users could input text, numbers, or images, but for any blog worth reading a user is going to want to be able to change font size, add styling, include images, links, etc.
This is where a rich text editor comes in! Essentially a rich text editor is an input field that allows a user to include some built-in formatting into the input. It’s like having a built-in Word Doc in the middle of your app.
There are a few rich text editor options out there, but here we’re gonna specifically work with Quill.js with a React frontend and a Rails backend.
Steps:
- Install quill.
npm install quill@1.3.6 - Import it at the top of React file.
3. Include this Quill component as part of a form in your render. Below you can see that the props include an onChange, a value, and a placeholder, much like any regular text input would. This is because in my Rails backend I chose to have this input set as a data type of ‘text’, so we’ll handle it as such.
Normally. ReactQuill saves its input as a subset of JSON called a Delta. But I’ve found you can avoid a lot of headaches by just saving it as a text for now.
At this point, I’m sure you’re noticing a couple of other props there that you’re not as familiar with. But not to worry, we’ll get to those next!
4) Now let’s look at the formats and modules props. For our purposes, the modules prop is going to represent the toolbar at the top of our input that contains all the nice functionality of a rich text editor. And the formats prop is essentially a list of content types or styles that the input field will recognize, even if said feature isn’t in the toolbar. For example, this could allow us to paste in bolded text into our editor or drag in a picture.
5) For modules, we are going to create an object with our toolbar array in it, and for formats, we are just going to create an array with all the different types of features you want to allow the editor to recognize. I just stuck these two elements below the actual render like so.
You can visit the Quill.js website for more of a granular description of how to include more specific toolbar/format features that meet your specific needs. But you could also just more or less copy what I have here and that should at least give you a pretty nice jumping-off point.
At this point, you should be able to see the editor in your render! Here’s mine as part of the larger form.
6) Next we’ll simply update our state onChange.
7) Then on submit we just take that content string from our state and POST it to our backend as a part of our larger blog post object. Nothing particularly weird so far.
8) Now this is where it gets interesting. At this point, is all we’ve done is pass a string to our backend, so how do we go from that string to functional HTML/CSS?
Well, before we do anything else, let’s look to see what the hell this string we are sending even looks like. So first, that means we need to create some content in our editor.
9) After making the content (with some features other than plain text), we should stick a console.log() in there somewhere to finally get a look at what we are passing to our backend.
As we can see it’s a pretty terrifying block of what looks to be HTML. Not fun to look at. Gross.
10) But at least now we know what we are sending to Rails. So how do we get this to just appear as rendered HTML on our actual blog page without all that nasty code in there?
For starters, after fetching the data on whichever page you want to display your blog, create a function to deal with displaying this weird HTML string as normal fully rendered HTML.
In this getBodyHTML function we are going to use a built-in javascript method called insertAdjacentHTML. This method will parse the text as HTML and insert said HTML at a specified point (in our case this point is called, ‘afterbegin’). Here ‘afterbegin’, just means that we want to insert this HTML inside of the given element, or after that element has begun, but not after it has ended.
If we look at our blog page we should see, our super informative, visually stunning blog that we slaved over, now rendering exactly as we had it in our text editor!
This is definitely a sort of quick and dirty workaround for avoiding all that delta business, but I thought it was all in all pretty straightforward, and easy to understand. Plus, it introduced me to the insertAdjacentHTML method!
Give it a go, and try to create your own WordPress competitor! Certainly don’t copy Medium though…
