Blog » Syntax highlighting in React with highlight.js and Web Worker

Syntax highlighting in React with highlight.js and Web Worker

2018-09 |

This content is only available in english

Syntax highlighting in React with highlight.js and Web Worker

One of the most common issues I heard people have with my blog was lack of syntax highlighting in posts, especially those, which contain a lot of code. Okay, it's almost 2019, I'm a software engineer, working mostly with front-end these times - I finally agreed, that it should be added. So I added it. And in the meantime, I also learned a little bit about Web Workers. Hence, this post, in which I describe this little adventure.

So, how do you do syntax highlighting? I have no clue! It's open source world, we don't bother with these questions, unless rare case, when there is no library for given purpose. Luckily, for syntax highlighting there is handful of them. Plenty of different implementations that exist out there allowed me to pick one that is tailored specifically to my needs.

My initial idea was that I don't want to block rendering of my post with syntax highlighting mechanism. It's cool feature, but it's not more important than the content of the article itself. More often than not, by the time user scrolls down to some piece of code in my post, at least a few seconds should pass - it's not at the top of the view in any case, there are always a few paragraphs of text, and I assume, that my readers actually read a few words from me. Therefore, I decided to use Web Worker for the job.

That's why I needed a standalone library that provides syntax highlighting mechanism. I didn't want it to be part of my project, one of my dependencies - I wanted to have it separated, and to be able to use it from my Web Worker conveniently. I decided to go for highlight.js, also because it allowed me to compile it to minified version, containing scripts only related to languages, that I use in my posts.

Once I established what I want to do and how I want to achieve it, I was ready to proceed to actual implementation. I started with modifications to my EntryContent component. Up until now, it was dummy component, which displayed HTML content of the entry, passed to it through props:

import * as React from 'react';

interface EntryContentPropsInterface {
  content: string;
}

export const EntryContent = (props: EntryContentPropsInterface): JSX.Element => (
  <div dangerouslySetInnerHTML="{{" __html:="" content="" }}=""/>
);

export default EntryContent;

With introduction of syntax highlighting, I wanted EntryContent to trigger this mechanism whenever it's mounted. My plan for triggering was to select all elements matching pre code selector from entry's content; then, pass content of each of those elements along with it's index to Web Worker, which I expected to return the same content, but highlighted; finally, substitute it in the view. So that's pretty much what I did:

import * as React from 'react';

import highlightWorker from './highlight.worker';
import WebWorker from 'common/WebWorker';

interface EntryContentPropsInterface {
  content: string;
}

export class EntryContent extends React.Component<EntryContentPropsInterface> {

  componentDidMount(): void {
    this.highlightCodeBlocksAsync();
  }

  highlightCodeBlocksAsync(): void {
    const codeBlocks = document.querySelectorAll('pre code');
    const worker = new WebWorker(highlightWorker);

    worker.addEventListener('message', (event) => {
      const { code, codeBlockIndex } = event.data;
      codeBlocks[codeBlockIndex].innerHTML = code;
    });

    codeBlocks.forEach((codeBlock, index) => {
      worker.postMessage([codeBlock.textContent, index]);
    });
  }

  render(): JSX.Element {
    const { content } = this.props;

    return (
      <div dangerouslySetInnerHTML="{{" __html:="" content="" }}=""/>
    );
  }

}

export default EntryContent;
</EntryContentPropsInterface

Two things in this code that remain unresolved are highlightWorker and WebWorker scripts, both imported at the top of the file. That's the implementation of my Web Worker, where all the magic happens. Let's start with highlightWorker:

export default () => {
  self.addEventListener('message', (event) => {
    try {
      importScripts('https://soofka.pl/scripts/highlight/highlight.pack.js');
      const result = self.hljs.highlightAuto(event.data[0]);
      postMessage({ code: result.value, codeBlockIndex: event.data[1] });
    } catch (e) {
      postMessage({ ...e });
    }
  });
};

It uses highlightAuto method from highlight.js library. This and other methods provided by the library are explained in details in documentation. TL;DR: it takes text as a parameter, and returns the same text, but highlighted, with automatic language detection. As you can see in the code of EntryContent, content of my code block was passed as first element of array of arguments in worker.postMessage function. The other parameter was index of given code block, so that I know where exactly should I place highlighted result in my view (keep in mind that it happens asynchronously).

The other piece of the puzzle is WebWorker. It's actually a piece of code I've found on the internet, most likely on StackOverflow, if memory serves. It's very clever way to help Webpack deal with Web Worker by creating it from imported script on the fly. Without it, I'd have to keep my Web Worker separated from source code of my blog, similarly to how I did with highlight.js library. Or I'd have to use some other workaround, such as worker-loader for Webpack. But instead, I did this:

export class WebWorker {
  constructor(worker) {
    const code = worker.toString();
    const blob = new Blob(['(' + code + ')()']);
    return new Worker(URL.createObjectURL(blob));
  }
}

export default WebWorker;

And that could be it! But I decided to do one more thing.

Even though Web Worker is very widely supported by browsers nowadays, I still wanted to practice a case, in which it's not available. Thus, I added one last method to EntryContent, which is meant to be triggered in case of lack of support for Web Worker, and which highlights code in synchronous manner. This time I used highlightBlock method from highlight.js, which handles DOM nodes conveniently. It allowed me to avoid setting innerHTML explicitly, which is never preferred option.

// ...

componentDidMount(): void {
  if (Worker) {
    this.highlightCodeBlocksAsync();
  } else {
    this.highlightCodeBlocks();
  }
}

// ...

highlightCodeBlocks(): void {
  document.querySelectorAll('pre code').forEach((codeBlock: Node) => {
    hljs.highlightBlock(codeBlock);
  });
}

// ...

I must admit, this way was much easier than the one with Web Worker, but much less fun too. Either way, I got what I wanted - syntax highlighting in my posts, and a little but of new knowledge and experience.

As usual, you can find all the changes I described in this post on my blog repository on GitHub.

Other blog posts

How to integrate Disqus comments in React app

2017-09 |

This content is only available in english

How to integrate Disqus comments in React app

One of the challenges that I faced while programming this, so far, very simple blog app (the one that you are using to read this post, most likely), was how to give my readers a possibility to comment on my posts. Obviously, it is one of the crucial features of this kind of app – I would like my readers to be able to tell me where am I wrong, and I would like me to be able to respond to such heretic claims. However, the whole feature seems quite a lot of work to implement from scratch. Luckily, there are plenty of ready out of the box solutions out there, one of them being Disqus.

Continue reading

My first MobX store

2018-07 |

This content is only available in english

My first MobX store

My dad wants to read my blog. The only issue is that he doesn't speak English very well. It's communicative, but it's not quite enough to understand intricate, sophisticated Shakespearean language, I am decorating my posts with. Worry not, father, as I've found the solution: language versions. I am currently working on adaptations of my posts in Polish language. In the meantime, I'm also adapting my codebase to be able to recognize and properly handle language parameter. And for that purpose, for the first time, I decided to use MobX.

Continue reading

How to set up tooling around your open source project

2019-11 |

This content is only available in english

How to set up tooling around your open source project

Lately in my project we had very particular need for specific validation of content of JavaScript bundle produced by Webpack. In the process of extensive research we have not found any existing tool to serve this purpose. Therefore, I've created Webpack Bundle Content Validator, which is a Webpack plugin and a CLI tool for Webpack bundle content validation. More importantly, I made it open source. Surprisingly, simply publishing it to NPM wasn't enough - I decided to set up continuous integration, automated unit tests code coverage calculation, automated check for vulnerabilities and a few other things, in order to make it legitimate and reliable package. In this post I'm describing those steps in details.

Continue reading

When building web applications in React, I usually choose Express to be my server, and more often than not I use React-Router to manage redirections and changes in history. Not without a reason - both are among the most popular choices in their respective fields nowadays; both are simple and elegant in every day work. However, I had some tough moments with both of them when it came up to setting all unrecognized routing to "Not Found" page, and this piece came as a result of them.

Continue reading

Back in the day, my JS projects were small and self-contained. Nowadays, in my professional work, majority, if not all of front-end applications I am working on are connected to multiple back-end services for variety of reasons. It gives me a freedom of not caring of the back-end, as long as we have defined a contract, and proceeding happily with what actually matters, i.e. colors and animations. But it also gave ma some headache, when I wanted to have pleasant, convenient coding environment on my localhost, and not have all of these weird back-end stuff running on my local machine as well. Here's how I worked it out with both Webpack Dev Server and Express.

Continue reading