sandbox with github repo as parent does not show on profile > sandboxes/showcase

[faceyspacey]

For example, go here:

https://codesandbox.io/u/faceyspacey/likes

You will see my main codesandbox there, but it does not appear here:

https://codesandbox.io/u/faceyspacey/sandboxes

and also it cannot be selected as for "showcase."

[CompuIves]

You're right, there is no current way to map a github sandbox to a user.

It's definitely on the roadmap to add this functionality, though it's not here right now for the reason that the user shouldn't be able to edit the sandbox. I need to change functionality on the server and client to allow changes to the title/description/tags etc, but to disable editing files.

[faceyspacey]

Thought so. Would be nice to be getting credit for my codesandbox stats. Very important for developers serious about promoting their sandboxes.

...for the showcase maybe u could paste the URL of any sandbox. Or select from liked sandboxes as well.

[faceyspacey]

I need this brotha. as well as to show my logo in the sandbox instead of just the github logo. And the ability to have this appear on my profile etc.

I get that less users probably use this feature. But the most important sandboxes will. The github connection needs to be flawless for CodeSandBox to achieve the "seriousness" it is capable of.

If the github connection is propped up, made feature complete, etc, it will get more usage and become a key part of CodeSandBox.

Basically syncing back to your repo from codesandbox will be the feature that helps this achieve the inflection point where it's a crucial aspect of the platform. What you want is to promote "EXPORT TO GITHUb" (or "FORK TO GITHUB") instead of import. This will make CodeSandBox go more viral than the embed buttons, as this is a frictionless activity users are already familiar how to do and doing it many times throughout the day.

It also wouldn't be a true fork. it's a creating a repo--so you could name the repo something with your URL in it if you want, and/or add anything you want to say to their readme, SUCH AS ADD YOUR MARKDOWN BUTTON. Or even better take a screenshot of the app, and put it at the top of the readme right below that button!!

There are tools to convert html to images via javascript in the browser. This is the primary tool if you don't already know it: https://html2canvas.hertzen.com

Convert HTML to canvas, and then canvas to image. That's how it's done.

It can't capture iframes or certain kinds of photos with hot-loading blocked, etc. But that won't be the case most of the time inside your iframe. So you need to generate it inside the app iframe, and then pass it back to the parent. You won't be able to generate it in the parent (i'm pretty sure, but i could be wrong since it's the same host).

So boom, now you're posting to repos an image, your branded button, whatever else you wanna say in the readme you create (or edit, if one already exists in the sandbox). It's one-click share instead of the embed modal, which is like 8 clicks:

• open modal
• choose 3 options
• go back go medium article
• click edit on medium article
• find place to put it.
• paste in link
• enter new line so embedly converts it
• publish article
• etc

That is a lot more friction than "FORK ON GITHUB". The latter will explode your popularity.

So that's why this is an important feature brotha, and more than just giving me the things regular sandbox users have. Please don't wait until you do all that before giving repo-based sandboxes parity to regular sandboxes. Achieving parity will take far less time than all that other stuff. But you need to do it anyway, and you don't want users scared of creating repo-based sandboxes cuz it doesnt work as well. You probably want to find a root-level way to make it so repo-based sandboxes aren't that different from regular sandboxes so that you don't always find yourself forgetting to add things to the repo-based version.

And it goes without saying, that I will help with any or all of this. Just a little bit of support and indication from you that you want such things, how you want it, etc, will make me a worker for you. Steer this ship. You have help. Spend a few minutes making some sort of plan and I'll crank out a few hours for CSB here and there.

Anyway, here is the list that would help me...and actually im just gonna DM you on twitter.

[CompuIves]

Export to GitHub feature would be an awesome feature, but we first need to lay some groundwork before we can start with it.

The biggest one being that we need to set up a snapshot system, where users can make branches of their sandboxes so they can work open a pull request after doing several saves instead of one. I don't want to have a save == 1 commit, that will be very messy for users like me that press save after every change.

But, before I want to have a snapshot system we need to have a new kind of storage system, because snapshots will be expensive if we copy all files and folders over for every snapshot. There is a much more efficient and simple system invented for Git.

The idea is that every module will have an identifier based on its content (created using sha256) instead of the content. The actual content resides in a central table called objects, with ids mapped to content, this will make forking and snapshotting much cheaper, because there is no duplicate content and most of the time only 5% of the content changes between snapshots.

After snapshotting we need to work on a team system, so multiple users can work on a single sandbox and thus the git repo. We can just build a basic version at first because this is not really pressing, I'm thinking of adding contributors has_many to sandboxes.

After this we can work on committing changes to GitHub, either directly to master, or by opening a new branch. There are a lot more things that need to be built before (like UI/UX, server endpoints, git-extractor endpoints).

This feature will be a lot of work, but will be built regardless. I want to do it right in the beginning with this, because there is no turning back after we've released this feature. I'll start working on it somewhere in August. The editor has more pressing requests and issues at the moment which I find more important, both for approachability for contributions and extensibility.

Okay, so I did do some changes in the meantime. After I deploy somewhere this week you can add tags to GitHub sandboxes by adding tags to the keywords config in package.json. The main reason is that one of the big features of git sandboxes is that more people can work on it, and I don't want to limit tags to only one user. This will be especially useful when you can edit github on codesandbox, because then the package.json will just change after the edit. This week I'm also going to build a Claim Sandbox button where you can set yourself as author on GitHub sandboxes, this will put your name in the sidebar and it'll allow you to showcase the sandbox.

Of course I'm open to suggestions, and maybe you know an easier way to have intuitive GitHub integration, I'd love to know them. Also, let's open up a separate issue for the ShareView simplifications.

[SaraVieira]

closed by lack of comments in over a year