fix(docs): highlight code blocks after client-side navigation (#3287)

[MFA-G]

Summary

Fixes #3287 — code highlighting is missing on the docs site after client-side navigation (e.g. clicking Deployments in the sidebar). The code only gets styled after a hard refresh.

Root cause

The docs use two different code paths to run highlight.js, and they target different selectors:

• Full page load runs an inline hljs.highlightAll() (injected in build.js). highlightAll() uses highlight.js's default pre code selector, so it highlights every fenced block — including blocks written without a language tag.
• Client-side navigation swaps .docs-content and fires a pathchange event. The pathchange handler in example.js highlighted only code[class^="language"].

Markdown fenced blocks without a language hint render as bare <pre><code> (no language-* class), so they matched on full load but were skipped after in-app navigation — exactly the symptom in the issue.

On the Deployments page there are 3 pre code blocks but only 1 carries a language- class, so 2 of 3 blocks stayed unstyled after client-side nav.

Fix

Align the pathchange handler with highlightAll() by selecting pre code, and skip blocks highlight.js has already processed (data-highlighted="yes") so repeated pathchange events stay idempotent and don't log highlight.js's "Element previously highlighted" warning.

-    // highlight code
-    $('code[class^=\'language\']').each(function () {
-        var $this = $(this);
-        if ( $this.attr('data-highlighted') === 'yes' ) {
-            $this.removeAttr('data-highlighted');
-        }
-        else {
-            try {
-                hljs.configure({ ignoreUnescapedHTML: true });
-                hljs.highlightElement(this);
-            } catch (e) { console.error('Error: Failed to highlight.', e); }
-        }
-    });
+    $('pre code').each(function () {
+        if ( $(this).attr('data-highlighted') === 'yes' ) return;
+        try {
+            hljs.configure({ ignoreUnescapedHTML: true });
+            hljs.highlightElement(this);
+        } catch (e) { console.error('Error: Failed to highlight.', e); }
+    });

Testing

• npm run build in src/docs succeeds.
• Reproduced the bug and verified the fix with a jsdom harness driving the built bundle: starting from a code-free page and simulating a pathchange navigation to the Deployments page, highlighted pre code blocks went from 0 → 3 of 3. Pre-fix the same flow highlighted only 1 of 3.
• Confirmed the pass is idempotent — triggering pathchange again leaves all 3 blocks highlighted with no re-processing.

Scoped to a single docs file; no behavior change for blocks that already carried a language class.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[xsourabhsharma]

Fix is correct selector change to pre code aligns with hljs.highlightAll() and the idempotency guard is clean.

Two nits:

• Move hljs.configure({ ignoreUnescapedHTML: true }) outside the loop it's a global config, no need to call it on every element.
• Consider scoping $('pre code') to $('.docs-content pre code') to avoid touching blocks outside the docs area on pathchange.

[MFA-G]

Thanks for the review @xsourabhsharma — both addressed in 2e2d91b:

• Moved hljs.configure({ ignoreUnescapedHTML: true }) out of the .each() loop so the global config runs once per pathchange instead of per element.
• Scoped the selector to .docs-content pre code so the re-highlight pass only touches the swapped-in docs body and leaves any code blocks elsewhere on the page untouched.

node --check passes on the file.

[xsourabhsharma]

@MFA-G could you plz sign the CLA?

[reynaldichernando]

thanks @MFA-G @xsourabhsharma , i reviewed this, and it's ready to merge
@MFA-G could you help sign the CLA? it's standard for contributions