Support storing multiple screens / screen states

[barucAlmaguer]

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

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]

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]

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]

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]

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

[danidewitt]

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:

Locally, it renders like this (without the error):

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