Skip to content
This repository has been archived by the owner on Feb 28, 2018. It is now read-only.

feature request: sub-folders + upload pre-existing repo #19

Open
faceyspacey opened this issue Apr 29, 2017 · 1 comment
Open

feature request: sub-folders + upload pre-existing repo #19

faceyspacey opened this issue Apr 29, 2017 · 1 comment

Comments

@faceyspacey
Copy link

faceyspacey commented Apr 29, 2017

this is a comment moved from the old repo: christianalfoni/webpack-bin#227

I love the left file browser by the way. I think it should just be the default and the files row removed so that there is more vertical space. I personally have a few demos that really need that vertical space since the app's are made to be non-vertically-scrollable on purpose.

File ordering is far less important with a tall sidebar as we have now because a lot more files can be seen at once since each file name's text runs horizontally.

However what is now important is the ability to make folders. That way what you build here can actually become your app. Couple that with the ability to upload apps (even if the webpack config can't be used), and you have huge marketing potential: now anyone can upload their pre-existing app without having to remake it from scratch. This is especially important for package creators that want to demonstrate capabilities, as they likely already built boilerplate examples and if they could click one button to upload their code, webpackbin now has a bunch more high-traffic examples. Those package creators are far less likely to recreate everything on webpackbin. I mean you could also simply allow pasting the URL to a github URL and it will extract its files. Imagine how many package creators will do that. Imagine how many users of packages will do that for them and post the link back to their Github issues, which the creator will then see and perhaps post in a readme, all without having to even think about doing it themselves.

Basically the way React Storybook became popular for package maintainers to showoff their packages in use is what could happen for webpackbin. It does not matter for most packages that we can't bring along our webpack config--we can easily figure out how to replicate what we need in webpackbin. But if you want to take it farther, obviously build a way to specify custom webpack configs. At least part of it: e.g. loaders, plugins. I get that you don't want arbitrary code running on your server where these packages are built. So whitelist some plugins and loaders, etc.

Anyway, I know it's a lot of work. I'm grateful for the sidebar you recently added. My suggestion is that the next step is folders. And then the next step after that is a feature to upload or paste a link to a repo to extract files from. Those 2 features don't seem outlandish, and perhaps are low-hanging fruit. Just add a button next to the files in the drawer to designate which file is the entry, rather than only allowing that on file creation.

@christianalfoni
Copy link
Member

Hi there and thanks for taking the time to explain your thoughts and ideas :-)

Actually folders are supported now. You just type: someFolder/myFile.js and it understands that is a folder. It is not very explicit, but I wanted to get it in with least amount of effort ;-)

I am actually talking to creator of Codesandbox.io (which shared bundling service with Webpackbin) to create a service to sync github repos with bin services. This is still in idea stage though and need to figure out best way to handle it, because it is rather complex.

I think complete projects in a bin service might be a bit too ambitious, because then you start competing with IDEs, which is a HUGE undertaking and others has so much more experience with that. Services like Nitrious and Cloud9.

So to summarize:

  1. You can create folders, but should give some indiciators to make it more intuitive
  2. Working on finding a good approach to github sync
  3. Bigger projects is current a no go, just because of scope :-)

About the files tab there now is also a "least effort" thing. Cause if it is removed you need to know what file you have open, which means new implementation ;-) Now it actually works much like an IDE, which I personally like. Show the files that is of interest, but be able to switch them out. But yeah, is just an effort for me to figure out how to handle stuff in best way.

Happy to receive PRs on this though :-)

Thanks again for your input!

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

2 participants