All courses : Replacing CodeSandbox.io devboxes with sandboxes

[Sahil-958]

Checks

• [X] This is not a duplicate of an existing issue (please have a look through our open issues list to make sure)
• [X] I have thoroughly read and understand The Odin Project Contributing Guide
• [ ] Would you like to work on this issue?

Describe your suggestion

Throughout the curriculum, there are interactive devboxes embedded from codesandbox.io, but they present several issues:

• By default, all panes and panels are visible, making it challenging to focus on the actual content.
• Editing the code is impossible without signing in.
• On Firefox and its forks, there's a page scrolling issue that hampers usability (see #27702 and #27665 for more details).

Initial Potentially Outdated Assumption

My understanding was that this issue exists because we're not using proper embed methods. Instead, we are embedding the full codesandbox.io devboxes inside iframes. I initially thought the root cause was the `embed=1` URL parameter not functioning as intended. This results in: - Cookie permission prompts. - A less responsive interface, unsuitable for the constrained space of an embed. - A requirement to sign in to clone the devbox in order to make edits. For comparison, here are two examples highlighting the difference between a properly embedded sandbox and one displayed in an iframe: - [Embed in an article](https://www.developerway.com/posts/intro-to-css-animations-for-react-devs) - [Devbox embedded using an iframe](https://www.theodinproject.com/lessons/react-new-introduction-to-state) Here are the above embed links opened in standalone tabs: - [Standalone Embed](https://codesandbox.io/embed/46mmq7?codemirror=1&hidedevtools=0&view=preview) - [Standalone Framed devbox](https://codesandbox.io/p/devbox/unruffled-pasteur-6h36wf?embed=1) The issue initially seemed to be related to the use of the `embed=1` URL parameter. For more context, here’s the information shared by @xandora on Discord, including code snippets showing the difference between our devbox embeds and the more structured article embeds: **Our embed:** ```html ``` **Article embed:** ```html ``` As you can see, the URLs differ significantly. In our case, we rely on URL parameters to specify it as an embed, while the article examples use a dedicated path (`/embed/embedID`), suggesting a more structured approach to embedding.

Updated Findings

Upon reviewing the documentation on codesandbox.io, I discovered important distinctions between the two types of embeds:

Type 1: Devboxes

1. Full VS Code-like IDE.
2. Runs the project on a server using a VM or Docker and supports a wide range of languages.
3. These embeds cause the aforementioned issues we've been encountering.

Type 2: Sandboxes

1. Minimal, editable UI.
2. Runs the project client-side, which limits support for some project types but fixes the issues mentioned earlier.
3. These embeds address all of the problems previously mentioned.

Migration Consideration

A key question is whether it's possible to convert a devbox into a sandbox.

The documentation doesn’t provide a clear answer, but given the difference in runtimes, we can assume that for complex projects, a sandbox might not be suitable. However, for simpler projects, using a sandbox could resolve these issues.

One important limitation: sandboxes cannot be used for projects that require bundlers like Vite. However, for simple React apps, sandboxes appear to be a viable solution.

Path

Foundations, Ruby / Rails, Node / JS, Other / NA

Lesson Url

The lesson URLs will be added after consulting with the community to identify all the Codesandbox embeds across various paths.

(Optional) Discord Name

saw_hill

(Optional) Additional Comments

A special thanks to @Eduardo06sp for the initial support and for recommending that this issue be raised on the curriculum GitHub repository.

[wise-king-sullyman]

So it sounds like for our use case here there really is no downside to changing them to sandboxes instead of devboxes? Is that correct?

[Sahil-958]

So it sounds like for our use case here there really is no downside to changing them to sandboxes instead of devboxes? Is that correct?

Yes and no.

For simpler embeds, switching to sandboxes works perfectly. However, for more complex embeds that require a full VM environment to run, it's not feasible. In those cases, we have to stick with devboxes or explore alternatives like StackBlitz, which also provides clean embeds without causing similar issues.

[wise-king-sullyman]

👍 well I'm in favor of us at least doing it where we can. Thanks for making this issue!