Create-react-app: Export to fiddle

Created on 25 Jul 2016  Â·  21Comments  Â·  Source: facebook/create-react-app

I want to find a way to provide something like “export to fiddle” by default. There is a lot of value in that for sharing prototypes and especially bug reports. I think everyone would win if it was easy to share editable source of your project right from the command line.

Fiddles are probably not the best tool for this because they tend to only have a single file view. But there are other tools such as http://plnkr.co, http://www.webpackbin.com/ and https://esnextb.in/. They allow multiple files and npm packages.

I think this would be an interesting direction to explore. I'm not saying we will necessarily build support for either of them but I think it's worth investigating.

Most helpful comment

I started working on this today for CodeSandbox. The idea is that people can either paste a github url (codesandbox.io/s/github/:user/:repo/tree/:branch/:path*) or use a cli (codesandbox) to create a sandbox based on existing file.

I'm getting the dependencies from the package.json and use all files in src as project files. I'm planning to finish this either this weekend or next week, I'll also link to the repo as soon as it's up for anyone willing to help.

Let me know if you have more suggestions!

All 21 comments

This sounds like such a good idea. I'll ping the creator of these services for good measure, feel free to chime in!

/cc @christianalfoni (WebpackBin), @voronianski (ESNextBin), @ggoodman (Plunker)

Sounds like fun. The challenge from the Plunker perspective is with respect to bundling. To reproduce the right UX, users would expect to be able to make changes to source files and have those recompiled on the fly.

Plunker doesn't (currently) support bundling in its run server. It does support building with babel and a selection of the most common presets. Here is what the babel compiler looks like, it is split into two components:

  1. Master: https://github.com/ggoodman/plunker-run/blob/master/facets/renderer/lib/babelRenderer.js
  2. Worker(s): https://github.com/ggoodman/plunker-run/blob/master/facets/renderer/lib/babelWorker.js

The same logic could be applied to webpack builds though I would be concerned about the additional load on the run server.

@gaearon @mxstbr

In order to support http://esnextb.in you just need to save GitHub gist with the following files:

  • package.json - provide required dependencies key with list of the packages
  • index.js - es6 flavored js code
  • index.html - markup, inlined styles, etc.

example gist - https://gist.github.com/voronianski/0cfe5ed99c004b74a463
and example esnextbin based on the gist (use exec param to execute code immediately onload) - https://esnextb.in/?gist=0cfe5ed99c004b74a463&exec=true

GitHub gists seem like an amazing “intermediate representation”.

“Upload to gist” would be a great feature by itself, and if other tools could offer “import from gist”, the problem would be solved.

That's a good point. To load any gist in the Plunker editor, this pattern
applies: https://plnkr.co/edit/gist: or in the embedded (more
modern) editor: https://embed.plnkr.co/gist/.

On Mon, Jul 25, 2016 at 10:04 AM Dan Abramov [email protected]
wrote:

GitHub gists seem like an amazing “intermediate representation”.
“Upload to gist” would be a great feature by itself, and if other tools
could offer “import from gist”, the problem would be solved.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebookincubator/create-react-app/issues/169#issuecomment-234962289,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADDbg4ovbgRxSM9ZWeO7PFhTsXk1gCGks5qZMJjgaJpZM4JUBh_
.

The problem with gists is that they can't have subdirectories (and filenames cannot contain /) which makes them fairly limiting.

Oh, that’s frustrating. We could settle on a custom format like :: for separators if tool authors agreed to support it.

@ForbesLindesay this is, indeed, a problem. IIRC gist.run gets around this by using backslashes in lieu of forward slashes and does a dynamic remapping. Plunker's new embed editor copied this approach but I can't remember if I did the same for the older, main, editor.

I started working on this today for CodeSandbox. The idea is that people can either paste a github url (codesandbox.io/s/github/:user/:repo/tree/:branch/:path*) or use a cli (codesandbox) to create a sandbox based on existing file.

I'm getting the dependencies from the package.json and use all files in src as project files. I'm planning to finish this either this weekend or next week, I'll also link to the repo as soon as it's up for anyone willing to help.

Let me know if you have more suggestions!

@CompuIves how about files in the public folder?

@viankakrisna CodeSandbox doesn't support static file hosting yet. I want to add this in the future, but I need to do some thinking on scalability and infrastructure for this.

My proposal is to show this as a warning in the CLI until it's added to CodeSandbox.

I think an overall better solution here is to not make the CLIs push to a specific code sharing tool, but rather a command to push to a github repo:

create-react-app repo whatevah

That way it will be possible for any bin service that integrates github support to use them, also public files. Basically:

  1. You want to share some code, you run create-react-app repo whatevah in your terminal
  2. Create react app creates a repo and pushes source and public files to that repo
  3. Now go to your "favorite" bin service and paste in the url to the repo
  4. The bin service will now collect the files and be able to map public files to its rawgithub equivalent

Instead of creating a create-react-app CLI, it could be a separate CLI that could be used with and framework or codebase. Like share-with-repo src public. It could be used without bin tools as well, just to quickly share some code.

Making custom CLI command for create-react-app and custom implementation for codesandbox does not feel very "open sourcy" ;-)

I agree, pushing to a repo is more open and solves the static file hosting too.

There are two drawbacks with this approach we need to take note of:

  1. Users need to sign in to their Github account before they can push
  2. For every issue or bug report a new Github repository needs to be created

It would be easier to implement a simple cli that can call an endpoint to create a sandbox, but I think that in the end it would be better and more fair to have a cli that can push to github instead.

I don’t think CRA itself should integrate such a command. But if Code Sandbox provides a command that “just works” with CRA-generated projects it would be great, and we’d be happy to advertise it. Then somebody else could make another tool for other sandboxes, or maybe even collaborate on one tool with many targets.

Yeah, if @CompuIves wants to pioneer this that would be awesome :) Will probably meet some issues and learn some lessons that could maybe go into a more generic tool later :D

@christianalfoni, @CompuIves how do you go about serving apps with explicit dependencies on webpack builds with usable latency?

Ultimately, if a tool like CRA can produce an output suitable for static consumption by a web browser, then any fiddle (or even dropbox) would be able to serve this. The challenge is closing the edit, preview, adjust cycle at scale with something as heavy as babel + webpack seems excessively $$ and risky (running untrusted code).

@ggoodman Short story here is that NPM dependencies are packaged into a Webpack DLL separately from your bin code. The bundle is aggressively cached in browser, uses CDN for others to grab same compilation of packages. That means that only code that is really handled is your actual BIN code, as if there were no NPM dependencies, they are all externals. So it is insanely fast :)

Though there are of course limits. It depends on the scope I suppose. I would suggest people would use this CLI tool for relatively small examples, not huge projects.

But yeah, I feel very confident that both webpackbin and codesandbox can handle a lot bigger projects than what they currently do now as a "fiddle" service :)

If that answered your question?

Will probably meet some issues and learn some lessons that could maybe go into a more generic tool later :D

Yes, already found some things :smile:. Everything will be open source, git extractor is here: https://github.com/CompuIves/codesandbox-git-extractor. I will open source the cli as soon as I start working on that.

I finished the CLI! You can find it here: https://github.com/CompuIves/codesandbox-cli.

@CompuIves Awesome! Would you like to send a PR to add a snippet to the user guide?

I'll close as we don't intend to implement this specifically ourselves.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

fson picture fson  Â·  3Comments

fson picture fson  Â·  3Comments

AlexeyRyashencev picture AlexeyRyashencev  Â·  3Comments

ap13p picture ap13p  Â·  3Comments

jnachtigall picture jnachtigall  Â·  3Comments