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

Support storing multiple screens / screen states #184

Open
barucAlmaguer opened this issue Sep 7, 2020 · 5 comments
Open

Support storing multiple screens / screen states #184

barucAlmaguer opened this issue Sep 7, 2020 · 5 comments

Comments

@barucAlmaguer
Copy link

Hi everyone!

First of all, thanks for this great tool, I use it every day.

I'm having trouble building a nice workflow when working on several designs simultaneously.
when working on 2 screens (or 2 screen states) at the same time (on 2 different tabs), It can only save the state of the last one I'm editing (for example, if I exit the browser and come back again later).

What happens next, is that I can only recover the last design I made, sometimes not even that (when entering my playroom page again, it shows me the default code).

I tried to establish a workflow saving my designs in bookmarks (to store the URL's code hash in several links), but when the design gets too large, sometimes it truncates the hash and the playroom brokes (see image below).

image_720

I think a good, simple addition would be a "save system", the possibility to "save as..." the design with names other than "code", and then we could just save / load them whenever we like.

Do you think there are better alternatives to this?
or if you think this is a good proposal, I could work on it and do a PR 😄

@michaeltaranto
Copy link
Contributor

We'd like to move this way in the future sure. The difficulty here is it really needs to be server-backed to ensure the Playrooms remain shareable and even proper support for generating/expanding short urls. The server-side component makes it harder to share as an open source solution.

We would like to add hooks for these sort of solutions, with a local storage/state solution as the default, but yeah need to consider how to do this without breaking the sharable and collaborative workflow that exists today.

@barucAlmaguer
Copy link
Author

barucAlmaguer commented Sep 8, 2020

and how do you currently handle this kind of issues when working in a design? (playroom going blank, minified React error, etc).
I'm trying to avoid data loss as much as possible.

Because of this I was thinking in the "save as..." system, we could keep shareable the last viewed code, while allowing to store locally different versions of the screen.

Other option would be an "import/export" feature, not as fancy as a quick link share, but would allow to share several states at once and give the designer more confidence on his/her work being preserved correctly.

@michaeltaranto
Copy link
Contributor

I must say i have heaps of playroom bookmarks and some that i would consider quite large, and i have not hit this limit. Not sure if that is browser-specific based on url length though.

If you can provide more info on how you're hitting the limit, maybe we can provide messaging around hitting the url limit if that is the problem. This would maybe help prevent the data loss/broken encoding.

@barucAlmaguer
Copy link
Author

thank you,
I'll try to make a reproducible case and come back to you.

@danidewitt
Copy link

danidewitt commented May 25, 2021

I'm also running into this issue. I reproduced it by adding a bunch of svgs and going over the limit here.

I used this svg about 20 or so times, until I hit a limit:

<svg viewBox="0 0 11 11" fill="none" xmlns="http://www.w3.org/2000/svg">
  <path
    d="M2.06295 4.07865C2.06295 3.87385 2.21417 3.70787 2.40075 3.70787H3.46066C3.64712 3.70787 3.79846 3.87385 3.79846 4.07865C3.79846 4.28345 3.64712 4.44944 3.46066 4.44944H2.40075C2.21417 4.44944 2.06295 4.28345 2.06295 4.07865ZM9.45842 7.53933H8.12197L7.98009 6.53178C7.95093 6.32043 7.78529 6.17978 7.5905 6.17978H2.76884C2.57404 6.17978 2.40841 6.32043 2.37924 6.53178L2.23737 7.53933H0.900802V2.8427H9.45842V7.53933ZM2.68 10.1348L3.10743 7.04494H7.25191L7.67934 10.1348H2.68ZM3.37801 1.85393H6.98122V0.741573H3.37801V1.85393ZM9.90882 1.85393H7.65682V0.370787C7.65682 0.165989 7.55818 0 7.3716 0H2.98774C2.80127 0 2.70241 0.165989 2.70241 0.370787V1.85393H0.450401C0.201667 1.85393 0 2.06627 0 2.33929V8.00961C0 8.28263 0.201667 8.52809 0.450401 8.52809H2.10033L1.83189 10.4526C1.81455 10.5773 1.84766 10.7288 1.92254 10.8245C1.99742 10.9202 2.10664 11 2.22149 11H8.13796C8.25281 11 8.36192 10.9141 8.4368 10.8184C8.51168 10.7228 8.54478 10.5928 8.52755 10.468L8.259 8.52809H9.90882C10.1576 8.52809 10.3592 8.28263 10.3592 8.00961V2.33929C10.3592 2.06627 10.1576 1.85393 9.90882 1.85393Z"
    fill="#8B99A6"
  />
</svg>

In the seek playroom, it looks like this, there is an error:
Screen Shot 2021-05-25 at 3 35 19 PM

Locally, it renders like this (without the error):
Screen Shot 2021-05-25 at 3 35 10 PM

The production build for my application does show an error. Would be great to get an over-the-limit error locally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants