chore(live-code): replace with react-runner

[nihgwu]

Review link: https://deploy-preview-6589--docusaurus-2.netlify.app/docs/markdown-features/code-blocks/#interactive-code-editor

Motivation

react-runner (or react-live-runner as a compact layer for react-live) is very similar to react-live but support more features, it uses sucrase instead of buble to transpile code(though I found they switched to sucrase recently), more flexible and less bugs, better SSR support

Comparing with buble, sucrase has smaller bundle size and supports modern language features, and supports Typescript, and the compile speed is super fast

SSR support of react-runner After Before

Have you read the Contributing Guidelines on pull requests?

Yes

Test Plan

Related PRs

[netlify[bot]]

✅ [V2]

Built without sensitive environment variables

Name	Link
🔨 Latest commit	714adeb46e001972a877f11d0fdfb7cecc0c81ba
🔍 Latest deploy log	https://app.netlify.com/sites/docusaurus-2/deploys/62a0e546b262460008907709
😎 Deploy Preview	https://deploy-preview-6589--docusaurus-2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[github-actions[bot]]

⚡️ Lighthouse report for the deploy preview of this PR

URL	Performance	Accessibility	Best Practices	SEO	PWA	Report
/	🟠 86	🟢 100	🟢 100	🟢 100	🟢 90	Report
/docs/installation	🟠 77	🟢 100	🟢 100	🟢 100	🟢 90	Report

[nihgwu]

@Josh-Cena Even take compiler optimisation in count

[nihgwu]

I pushed this PR as a PoC, if you think it's legit, I'll update other related docs, like the notes about imports, actually we can "support" that syntax, and you don't need to set noInline manually, it just works out of box

[Josh-Cena]

Yes, that looks great! We can remove the mentions of react-live, and you can update the other docs accordingly. 👍

[slorber]

Thanks, that looks like a nice POC and a good improvement over react-live

I'm not 100% sure of the potential impacts yet so I'm marking this as a potential breaking change, as we are updating the underlying lib.

Some random thoughts:

• We need to test this more deeply on sites using live codeblocks more extensively (we don't use much live codeblocks)
• How does it compare to Sandpack, which we may want to adopt in addition or as a replacement for the existing plugin
• FB/Meta is already interested to deploy Sandpack on other sites like Jest/Relay in the future
• I feel like we should create a new distinct plugin, as we may end-up with 2 distinct plugins for live codeblocks in the future 🤷‍♂️ and it can also permit incremental adoption and a deprecation period for the react-live plugin
• Considering you are quite alone and it's a new lib, don't we want to own that code, or at least have git/npm publish permissions to ensure this lib will stay maintained?

[nihgwu]

@slorber It's not a new lib, I created 3 years ago and used in a lot of projects of mine or I worked, I just migrated it to Typescript recently, and itself is tested fully, regarding the maintenance, I'm happy to invite more as admin for this package

Regarding Sandpack, yes I noticed you are using it in new React docs website(you will find that the demos there could be copied to react-runner and just work out of box), and that's why I added multi files support recently, and the example is copied from there, I think for small live preview, Sandpack is still too heavy, we still need to load resources in the iframe, and the dependencies will be loaded again there, and then build, but with react-runner, all of those are synchronous and super fast, which provide best SSR support and better user experience.

Regarding React Runner, it's designed to be modular, so you can just use react-runner and create your own editor, and even support on-demand imports, like Play React uses CodeMirror and Skypack

I don't think it's a breaking change as there is no change for user space but more features, and the change is actually smaller then from [email protected] to [email protected], which doesn't support SSR anymore and breaks preview cache, that if error happens, your code editor with jump as nothing will be rendered.

[Josh-Cena]

I also think that:

• This is not a breaking change as there's absolutely no behavior change
• Sandpack is quite an irrelevant topic in this migration. We are only interested in getting rid of react-live
• SSR seems interesting enough

However, @nihgwu the test is failing and it looks related to your component

[nihgwu]

@Josh-Cena I think builds are failing because the import config of Docusaurus after I tried to re-export createRequire, I'll have a look later, should be easy to fix, or perhaps we don't ex-export it but leave it to user space

[nihgwu]

@Josh-Cena @slorber So what's the plan

[nihgwu]

@slorber Yeah regarding there is no user space change, it would be nice to roll it out to test it in the wild

[nihgwu]

@slorber I've taken your advice and made a small change to react-runner to use scope.import as import scope, so users don't need to use createRequire anymore, though it's still supported https://github.com/nihgwu/react-runner/pull/84 https://github.com/nihgwu/react-runner/pull/85, and it's not included in this PR

Regarding Sandpack, I raised a ticket in reactjs/reactjs.org

[slorber]

Thanks @nihgwu, that PR on the ReactJS website (https://github.com/reactjs/reactjs.org/pull/4339) is interesting and I'll watch it carefully

Unfortunately, you can understand this PR is not a so tiny change and I'll have similar concerns as Dan Abramov has, and as I said I have to focus in priority on the last features we want for v2.0 even though I like this PR.

Please don't be too impatient, I'll review this deeply when it's time, which is unfortunately not this week

[nihgwu]

@slorber Sure I will wait, and I understand it's not that important for v2 releasing, thank you again for your feedback and detailed explanation. Regarding the concerns, I'd say it's different, as for the ReactJS docs website, it needs more features then common library document website, like Fast Refresh / Server Component, but for most of the cases we don't need to care about that, besides react-live doesn't support those as well, anyway I don't want to disturb your work on V2, take your time, and thank your for this great project

[Josh-Cena]

@nihgwu Checking in again as I probably lost track of this PR, for now, there's absolutely no API change and ReactLiveScope works just the same as before without createRequire, right?

[nihgwu]

@Josh-Cena Yes, the only change is that I added a import field to scope to support imports syntax(not mentioned in this PR per comments), because import is a key word, so it should be same and you can still use all the variables as before

[slorber]

Note: React-Live 3.0 is also using Sucrase now

https://github.com/FormidableLabs/react-live/releases/tag/v3.0.0

[nihgwu]

@slorber Yes I know(I mentioned that in the description), but I'd say it's not as powerful and flexible as react-runner ;p, BTW styled-components website is already using react-runner https://github.com/styled-components/styled-components-website/pull/847, and soon for material-ui https://github.com/mui/material-ui/pull/32107

[Josh-Cena]

@nihgwu react-live suffers from the same issue, but do you think we can change div for span for the line container? The validator is warning that "Element div not allowed as child of element pre in this context.".

[nihgwu]

@Josh-Cena we can't simply change div to span as it should be a block, we can do or the following to avoid breaking change(keep className & style props for line) Even I made this change, validator will still complain on the editor, and I don't think it could be solved easily, like this one

[Josh-Cena]

Yeah, I'm also aware of the style tag problem. FYI, Docusaurus solves it through span + br:

https://github.com/facebook/docusaurus/blob/67faa686e8d53ab0f439454bc046344d5580a665/packages/docusaurus-theme-classic/src/theme/CodeBlock/Line/index.tsx#L42-L54

[slorber]

In https://github.com/facebook/docusaurus/pull/9316 we upgraded both prism-react-renderer and react-live.

Thanks for your work, but for now I prefer to close this PR. It would be better if you create a react-runner community plugin and prove its usefulness in userland. If users adopt it successfully, and report preferring it over react-live, we can consider switching the official package.