Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Export to fiddle #169

Closed
gaearon opened this issue Jul 25, 2016 · 21 comments
Closed

Export to fiddle #169

gaearon opened this issue Jul 25, 2016 · 21 comments

Comments

@gaearon
Copy link
Contributor

gaearon commented Jul 25, 2016

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
Copy link
Contributor

mxstbr commented Jul 25, 2016

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
Copy link

ggoodman commented Jul 25, 2016

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
Copy link

voronianski commented Jul 25, 2016

@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
Copy link
Contributor Author

gaearon commented Jul 25, 2016

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
Copy link

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
Copy link
Contributor

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

@gaearon
Copy link
Contributor Author

gaearon commented Jul 25, 2016

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

@ggoodman
Copy link

@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
Copy link

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
Copy link
Contributor

@CompuIves how about files in the public folder?

@CompuIves
Copy link

@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
Copy link

christianalfoni commented Jun 8, 2017

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
Copy link

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.

@gaearon
Copy link
Contributor Author

gaearon commented Jun 8, 2017

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.

@christianalfoni
Copy link

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

@ggoodman
Copy link

ggoodman commented Jun 8, 2017

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

@christianalfoni
Copy link

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

@CompuIves
Copy link

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

@CompuIves
Copy link

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

@gaearon
Copy link
Contributor Author

gaearon commented Jun 28, 2017

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

@gaearon
Copy link
Contributor Author

gaearon commented Jan 8, 2018

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

@gaearon gaearon closed this as completed Jan 8, 2018
@lock lock bot locked and limited conversation to collaborators Jan 20, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants