Live Code Editor be Server Side Rendered

[ntucker]

💥 Proposal

It would be nice for the Editor part of live editor to be server side rendered, that way it can be previewed before the editor loads as well as improving search engine optimization.

A preliminary investigation makes me unsure of why this even is, since there's an explicit part that keys the LiveEditor component based on whether it is server side or not.

Have you read the Contributing Guidelines on issues?

yes

[slorber]

Hmmm yes we should try to minimize layout shifts and render code in SSR.

Not sure it's possible for the preview, but at least it should be for the editor.

https://docusaurus.io/docs/next/markdown-features/code-blocks#interactive-code-editor

With JS:

Without JS:

---

This line looks suspicious, maybe we should get rid of it:

[Josh-Cena]

Code blocks need to be rendered client-side whatsoever because of Prism being client-side. #4318 removed SSR because double-evaluation can lead to side effects.

[ntucker]

Code blocks that aren't live are evaluated during SSR - so why can't the SSR render produce the same HTML?

[Josh-Cena]

Code blocks that aren't live are evaluated during SSR

In a perfect world we could. I think we can render a normal code block (maybe another "dummy element" for the output) during SSR and only really "evaluate" the code block during CSR. Problem is, currently the "live code block" which looks deceptively like a code block is actually a completely different component that's part of a context provider, and rendering it inevitably means sending that context value to the renderer and producing side effects, making things a little more complicated that we may have expected

[ntucker]

Can you elaborate on the side effects? I would love to understand the nature of this difficulty more.

[Josh-Cena]

Can you elaborate on the side effects?

You can check the comment for #4318 and the related issue for that. The code is here:

docusaurus/packages/docusaurus-theme-live-codeblock/src/theme/Playground/index.js

Lines 66 to 85 in fd41239

	<div className={styles.playgroundContainer}>
	<LiveProvider
	key={isBrowser}
	code={isBrowser ? children.replace(/\n$/, '') : ''}
	transformCode={transformCode || ((code) => `${code};`)}
	theme={prismTheme}
	{...props}>
	{playgroundPosition === 'top' ? (
	<>
	<ResultWithHeader />
	<EditorWithHeader />
	</>
	) : (
	<>
	<EditorWithHeader />
	<ResultWithHeader />
	</>
	)}
	</LiveProvider>
	</div>

The code-block-looking comp is actually EditorWithHeader provided by react-live, not the default one. So if you send the actual code in SSR, the context value would be updated when the SSR output arrives at the end user, and again after hydration. But I have a solution in mind with BrowserOnly and using its fallback

[ntucker]

I already override my liveprovider and just removing the key and code forks worked fine so I guess I'll just use that for now.

After reading the issue thread I'm still very confused as to what issue people were having. I'm not realizing 'side-effect' means 'something else broken, rather than side-effect like global variable change. Other that than I'm still stumped.

On the plus side since pointing out the code conditional I was able to get what I wanted working!

[Josh-Cena]

@ntucker In the current situation, I just rendered a static code block during SSR. Does that look better than rendering nothing?

[ljharb]

Literally anything looks better than rendering nothing, no?