Export to fiddle

[gaearon]

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.

[mxstbr]

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)

[ggoodman]

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.

[voronianski]

@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

[gaearon]

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.

[ggoodman]

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 notifications@github.com
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
#169 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADDbg4ovbgRxSM9ZWeO7PFhTsXk1gCGks5qZMJjgaJpZM4JUBh_
.

[ForbesLindesay]

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

[gaearon]

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

[ggoodman]

@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.

[CompuIves]

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!

[viankakrisna]

@CompuIves how about files in the public folder?

[CompuIves]

@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.

[christianalfoni]

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" ;-)

[CompuIves]

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.