[play] query parameters and code persistence

[rgbkrk]

As an initial first pass, and supported by the work in #2141, we should figure out what our URL structure should be. Here's a first pass for just repo, ref, and kernel:

https://play.nteract.io/?repo=nteract/vdom&ref=master&kernel=python

Those seem totally fine. Now onto the code layer...

Persistence layer

One way to do these fiddles is to put all the code in the URL itself, URI encoded:

https://play.nteract.io/?code=import%20this

Another way would be to back these with gists (suggested by @yuvipanda, @betatim):

https://play.nteract.io/?gistID=5c73e81ee857686168c3abec49225482

Or we could rely directly on firebase (suggested by @captainsafia) and track our own storage:

https://play.nteract.io/?id=agQr23nuI

One consideration that I'd like to take into account is if/how we'd support forking from one of these. I'd like to make it immediate. As you change a previously "published" fiddle, you're running on a (virtual) fork of the original. As soon as you share/save, you've effectively committed a new version. I guess this means we have to take into consideration what a document lifecycle is with these.

Prior art (in the JS space):

• http://jsbin.com/
• https://codepen.io/pen/
• http://requirebin.com/
• https://jsfiddle.net/

/cc @yuvipanda, @mpacer, @captainsafia, @betatim

[yuvipanda]

Thank you for starting it!

Binder support more than just github (although UI for that isn't here yet) - gist, gitlab, raw git, and probably OSF in the future. Internally, binder's URL structure is <apiVersion>/<provider>/<provider-specific-reference>, so individual providers can dictate what kinda information they need. For the github provider ('gh') it is '//', but for other providers it's different. This should be incorporated into the design somehow from the start IMO, while defaulting to github.

Perhaps an optional ?provider= that defaults to github, and combine the repo and ref URL params to a single one that can be passed to the binder api?

[yuvipanda]

For storage, all these options sound great :) If they're pluggable, it allows different installations to enable / disable different variants based on their needs. Whether that should be part of MVP or not is upto your discretion!

I personally think outsourcing content storage to gists is the way to go, since it offloads a lot of content provider responsibilities to a third party :)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue hasn't had any activity on it in the last 90 days. Unfortunately we don't get around to dealing with every issue that is opened. Instead of leaving issues open we're seeking to be transparent by closing issues that aren't being prioritized. If no other activity happens on this issue in one week, it will be closed. It's more than likely that just by me posting about this, the maintainers will take a closer look at these long forgotten issues to help evaluate what to do next. If you would like to see this issue get prioritized over others, there are multiple avenues 🗓:

• Ask how you can help with this issue 👩🏿‍💻👨🏻‍💻
• Help solve other issues the team is currently working on 👨🏾‍💻👩🏼‍💻
• Donate to nteract so we can support developers to work on these features and bugs more regularly 💰🕐

Thank you!

[PradyumanAgrawal]

As of now, when the user enters the new "gitref" and "repo" values and submits the form, the query parameters are updated but when we enter this URL, it still connects to the default nteract/examples repo. I would like to work on this issue and would like some guidance . So far, one solution I could come up with was using the "useRouter" Hook from "next/router" to get the values from the query parameter. I am successfully able to update the state values of gitref and repo but the kernel component is not getting refreshed when this happens. So its still connected to the default value but the states have been changed. If this seems like a viable solution, I would like some help to solve this problem.

This is basically what I am trying to run.

[captainsafia]

@PradyumanAgrawal The KernelUI component doesn't currently take the gitref or repo as props at the moment so it's shouldComponentUpdate does not detect a change in those values and trigger a re-render.

Your approach around using Next's routing library makes sense.