gatsby-remark-prismjs line highlight breaks when react-live is included

[bvaughn]

I recently noticed a bug with the gatsby-remark-prismjs plugin on a site I'm working on: code line-highlights show up when I navigate to a page initially, but if I reload the page in place they're missing. (There's no wrapper <span class="gatsby-highlight-code-line">...</span> after a page reload).

After a lot of trimming down, I've been able to demonstrate this bug in a small repro (at bvaughn/gatsby-remark-prismjs-react-live-bug). The tl;dr is that including any react-live component (even if it's not used) will break the gatsby-remark-prismjs plugin line highlight.

I will attempt to further track this issue down. I'm also unclear about whether I should file this as an issue for Gatsby or React Live, although I believe it's probably more appropriate to file it against React Live. That being said, for now I'm going to try filing against both in case either project author has ideas or suggestions.

Relates to FormidableLabs/react-live/issues/22

[bvaughn]

It looks like Gatsby is initially rendering the markup, with line highlights, and then react-live is requiring its own copy of prism-core which is clobbering Gatsby's initial content.

I can prevent this by updating Prism to check an element's contents before potentially re-highlighting it, but... I kind of doubt Prism would be interested in accepting that change.

[bvaughn]

Maybe a potential fix here would be for Gatsby to make use of Prism's data-line attribute as mentioned in the Prism docs. Not sure... I will try to test that out locally.

Scratch that. Prism's line highlighting seems pretty fragile/busted and this looks like a dead-end based on my initial testing.

[bvaughn]

Looks like maybe this can be avoided by removing the language attribute from Gatsby's pre-generated <pre> tags. This way, requiring Prism a second time won't re-highlight the already-processed content.

Based on my initial testing, this fixes the problem without introducing any major regressions with the exception of styles that depend on pre[class*="language-"].

Perhaps we could instead use a data attribute (eg <pre data-language="javascript">) to support custom styling?

[jbolda]

Would having our prism prefix the classes help?
http://prismjs.com/plugins/custom-class/

[bvaughn]

Not sure I understand. Would that prevent Prism from re-processing the already-processed markup? Any benefits for that vs the data attribute approach?

[bvaughn]

(From our conversation in Discord)

brianvaughn: Hm. So looking at the Prism docs, I'm not so sure this does what you're thinking.
brianvaughn: http://prismjs.com/plugins/custom-class/#example
brianvaughn: The prefix isn't for the <pre class="..."> but rather its nodes within
brianvaughn: Which wouldn't help with what I'm trying to address

[bvaughn]

After the change from #1491 was released, I upgrade the docs site and while the initial markup seems as expected:

<pre class="gatsby-language-js">
  <code>

The markup after reloading is incorrect:

<pre class="gatsby- language-js">
  <code class=" language-js">

The line-highlight wrapper element is also gone, meaning (I assume) that somehow Prism is still reprocessing the <pre> tag contents.

The repro case I provided does not illustrate this broken behavior. I am not currently sure why this is. ☹️ More investigation is required.

I'm guessing that the behavior of Gatsby is not to blame for this, since the initial markup is correct. I'd like to leave this issue open a little longer though while I investigate.

[bvaughn]

Ah. That's because my selector wasn't unique enough. Prism searches for [class*="language-"] code (pretty greedy) which matches my gatsby-language- prefix 😅