Propose: Better support React simple use cases

[joshgoebel]

Creating this thread to discuss if we might provide a simple/small React plugin/component to make using Highlight.js as part of a React application a little easier to get started.

[joshgoebel]

First response from the original mixed thread:

---

For React.js I use the following simple wrapper.
I can't use highlightBlock as it writes directly to DOM node's innerHTML, that is not React way.

import React, { useState, useEffect } from 'react';
import PropTypes from 'prop-types';
import hljs from 'highlight.js/lib/core';
import excel from 'highlight.js/lib/languages/excel';

hljs.registerLanguage('excel ', excel);

const SyntaxHighlighter = ({ sourceCode }) => {
    const [parsedCode, setCode] = useState(null);

    useEffect(() => {
        function highlight() {
            let highlighted = hljs.highlight('excel', sourceCode);
            setCode(highlighted.value);
        }
        highlight(sourceCode);
    }, [sourceCode]);

    return (
        <div>
            <pre
                contentEditable={false}
                className="excel"
                dangerouslySetInnerHTML={{ __html: parsedCode }}
            />
        </div>
    );
};

SyntaxHighlighter.propTypes = {
    sourceCode: PropTypes.string,
};

SyntaxHighlighter.defaultProps = {};

export default React.memo(SyntaxHighlighter);

Originally posted by @andrewQwer in #2535 (comment)

[silverwind]

I would not recommend dangerouslySetInnerHTML under any condition. highlightBlock can be used via refs and useEffect.

[andrewQwer]

highlightBlockmodifies innerHtml, that is not React way of working with DOM.

[silverwind]

I agree it's not ideal if you have to use them but dangerouslySetInnerHTML is even worse as it can introduce security issues when highlighting untrusted code unless hljs can sanitize. Maybe a wrapper module for that outputs a react element for given source code and language would be better.

[joshgoebel]

highlight escapes passed code... the output will only include HTML generated by Highlight.js itself. highlightBlock preserves HTML already inside the block but still properly escapes any code itself that is re-rendered.

I would not recommend dangerouslySetInnerHTML under any condition. highlightBlock can be used via refs and useEffect.

So using code via refs that itself calls innerHTML is seen as better than using dangerouslySetInnerHTML? Aren't they effectively the same?

[joshgoebel]

https://stackoverflow.com/questions/37337289/react-js-set-innerhtml-vs-dangerouslysetinnerhtml

This seems to be arguing in favor of dangerouslySetInnerHTML because it educates React about the block - that it's dynamic and react can ignore it from the shadow DOM, etc.

[joshgoebel]

In Vue we can just make the highlighted code a computed property and then insert it into the template via variable... passing the code into the component as a prop... surely this type of thing is also possible in React?

The sample above looks a lot like I'd expect that might look but I dunno about all the effect stuff and if there is a simpler way to write it - or if React just requires more boilerplate than Vue.

Highlight.js generates raw HTML... that by it's nature is a [potentially] dangerous thing...

[joshgoebel]

IE, I think the "simplest" form in Vue might look something like:

export const Component = {
  props: ["language", "code"],
  computed: {
    className( ... ) {},
    highlightedCode() {
      this.highlightedCode = hljs.highlight(...)
    }
  },
  template: `<pre><code :class="className" v-html="highlightedCode"></code></pre>`
};

What would the equivalent be in React?

[silverwind]

I guess it is fine if hljs already escapes dangerous characters in the source. Minimal example could be

function Component({language, code}) {
  const [highlightedCode, setHighlightedCode] = useState(code);

  useEffect(() => {
    setHighlightedCode(hljs.highlight(language, code));
  }, [code]);

  return (
    <pre>
      <code dangerouslySetInnerHTML={{__html: highlightedCode}}/>
    </pre>
  );
};

This will initially render unhighlighted and do another render once highlighting is done. I guess one could block the first render until highlighting is done, but it'll be more complicated.

[joshgoebel]

And could you share what that would look like as pure JS without the JSX?

[joshgoebel]

I guess it is fine if hljs already escapes dangerous characters in the source.

We currently do > < &... it looks like we should maybe add a few?

&   ------->   &
<   ------->   &lt;
>   ------->   &gt;
"   ------->   &quot;
'   ------->   &#x27;
/   ------->   &#x2F;

Should that cover it? I'm not sure (off the top of my head) how the quotes or / could break out on their own though without the tag characters... I think the quotes are more about raw insertion anywhere (like in the middle of an HTML attribute) as shown here:

https://webmasters.stackexchange.com/questions/12335/should-i-escape-the-apostrophe-character-with-its-html-entity-39

That's not what we do... although now I'm wondering if there is a potential attack vector with a evilly coded grammar via className. Although grammars already run any JS they want freely though, so some sort of attack via className would be the HARD way to do it.