Released a few days ago: https://sandpack.codesandbox.io/

Details of bundle changes

@material-ui/core: parsed: +Infinity% , gzip: +Infinity%
@material-ui/lab: parsed: +Infinity% , gzip: +Infinity%
@material-ui/styles: parsed: +Infinity% , gzip: +Infinity%
@material-ui/private-theming: parsed: +Infinity% , gzip: +Infinity%
@material-ui/system: parsed: +Infinity% , gzip: +Infinity%
@material-ui/unstyled: parsed: +Infinity% , gzip: +Infinity%
@material-ui/utils: parsed: +Infinity% , gzip: +Infinity%

Generated by 🚫 dangerJS against 0442bbd

Released a few days ago: https://sandpack.codesandbox.io/

I was going to ask whether we have considered https://www.npmjs.com/package/@codesandbox/sandpack-react too :)
I would say it would be better to use this option, rather than implement our own tool. Looks like it's already battle-tested in https://beta.reactjs.org/learn and is coming in the docs in Chakra-UI too.

I was going to ask whether we have considered https://www.npmjs.com/package/@codesandbox/sandpack-react too :) I would say it would be better to use this option, rather than implement our own tool. Looks like it's already battle-tested in https://beta.reactjs.org/learn and is coming in the docs in Chakra-UI too.

Makes sense, Marija. I can implement a version with Sandpack and then we can compare the performance, UX and bundle size changes across the two branches.

There is a layout shift when starting to interact with an editable demo.

This is fixed on the deploy preview for me:

This is fixed on the deploy preview for me

I get it for the first click on a code block on a page. Clicking on a subsequent demo doesn't have the same issue.
However in addition to the layout shift shown in the screen capture in the PR description, the text following the code block moves up when you click to edit. This happens for every demo, not just the first one clicked.

No bundle size changes

Generated by 🚫 dangerJS against 47ee023

The ComboBox demo fails in the editable version; it works only when the

export default function ComboBox() {
  return (
    <Autocomplete
      disablePortal
      id="combo-box-demo"
      options={top100Films}
      sx={{ width: 300 }}
      renderInput={(params) => <TextField {...params} label="Movie" />}
    />
  );
}

// Top 100 films as rated by IMDb users. http://www.imdb.com/chart/top
const top100Films = [
  { label: 'The Shawshank Redemption', year: 1994 },
  { label: 'The Godfather', year: 1972 },
  ...

top100Films definition is moved before the ComboBox component definition; however, this is reversed by yarn docs:typescript:formatted

@siriwatknp Any thoughts on this?

I am not sure, can you try with a function instead?

export default function ComboBox() {
  return (
    <Autocomplete
      disablePortal
      id="combo-box-demo"
      options={getTop100Films()}
      sx={{ width: 300 }}
      renderInput={(params) => <TextField {...params} label="Movie" />}
    />
  );
}

const getTop100Films = () => [
  { label: 'The Shawshank Redemption', year: 1994 },
  { label: 'The Godfather', year: 1972 },
  ...

Just so that I understand correctly, by the first one do you mean that the outline (focus indicator) should not appear if the editor is clicked on?

Yes. Here's how it was done in the prior PR.

I seem to be missing this one locally and on the deploy previews as well

Whether by accident or design, the message seems to be gone

Just so that I understand correctly, by the first one do you mean that the outline (focus indicator) should not appear if the editor is clicked on?

Yes. Here's how it was done in the prior PR.

I seem to be missing the rationale for this - why should the focus indicator not show up if clicked?

why should the focus indicator not show up if clicked?

@bharatkashyap I think that it's well explained in https://www.w3.org/TR/wai-aria-practices-1.1/#kbd_focus_discernable_predictable. TL:DR The focus indicator is distracting when the modality is a mouse but helpful when the modality is a keyboard. It's mostly a UX consideration, I wouldn't expect all the designers to agree on what is right.
This is why the W3C has introduced the concept of :focus-visible. It's progressively implemented by all browsers, e.g. Safari: https://blogs.igalia.com/mrego/2021/06/07/focus-visible-in-webkit-may-2021/

[x] Layout shift of text below editor (first interaction with any editor).

The current state of the layout issue seems to be best one possible given a reasonable effort

• Preview layout shift (first interaction with one editor).

The flash on first interaction is still occurring and is a production only issue, probably related next/dynamic

• Editor cursor not placed at position clicked.

Since we are replacing one component with the other, this is highly unlikely to be able achievable with any reasonable approach.

As an alternative, spent some time on this possibility: #30873 (load the editable demos by default, not requiring replacement) which fixes all of the above at a marginal cost to first load time.

load the editable demos by default, not requiring replacement) which fixes all of the above at a marginal cost to first load time.

Would there be any benefit in loading the editor on page load, but only load the live preview when the editor is focused?

Is there any bundle-size advantage to not having both?

Would there be any benefit in loading the editor on page load, but only load the live preview when the editor is focused?

Comparing the network tab of preview deploys of both PRs (cache disabled), I seem to notice about a 90kB increase in downloaded resources (= +/- 5% increase). It's not nothing, but it's also not dramatic compared to the 1.8MB we already have.

Bundle size checker doesn't seem to take the docs into account. We should include them in there.

I seem to notice about a 90kB increase in downloaded resources

With which one? (I could run the same exercise, but since you already have...)

I compared this PR (deploy) with #30873 (deploy). The latter downloads about 90kB 85kB more resources. jarle is a pretty heavy dependency so I think we can attribute most of the increase to not lazy loading it in #30873.
This shouldn't necessarily stop us from using #30873, ofcourse.

Okay, so a hybrid of "load the editor by default, but don't load the preview until the editor is interacted with" could be the way to go.

Okay, so a hybrid of "load the editor by default, but don't load the preview until the editor is interacted with" could be the way to go.

The "flicker" production-only issue would remain unsolved with that approach given that we would still need to replace a static component with a dynamic one on runtime. Are there any particular benefits to this hybrid approach over loading both by default (except the bundle size)?

No, but bundle size is obviously important. What causes the "flicker"?

The "flicker" production-only issue would remain unsolved with that approach given that we would still need to replace a static component with a dynamic one on runtime.

What if Jarle was render on top of the "static" demo?

Closing in favor of #32107 Great job for kicking off this effort @bharatkashyap

Great job for kicking off this effort @bharatkashyap

<Cough>: #24640 😁