Persist data

[Shuunen]

Hi ! Great project, I love minimal app like this ❤️

It would be great to store the diagram status :

• in url : to let users send diagram via copy pasting url
• in localstorage : to avoid losing the diagram by closing the tab or browser accidently (or system crash, cat on keyboard, nuclear attack, ...)

I'm wondering now about the size limit in url address & the way of encoding boxes, lines and text all together in a string.

For the local storage, it should be easier without this string restriction.

[jncraton]

Thanks for the feedback. I'm glad that you've enjoyed this project. 😀

I've played around with adding persistence via the URL fragment in a feature branch. You can play around with it here:

https://persistence--box-line-text.netlify.app

Here's an example URL with stored data:

https://persistence--box-line-text.netlify.app/#PHNlY3Rpb24gc3R5bGU9IndpZHRoOiAzMThweDsgaGVpZ2h0OiAxOTBweDsgbGVmdDogNjJweDsgdG9wOiA2MnB4OyI+PHAgY29udGVudGVkaXRhYmxlPSJ0cnVlIj5TdGF0ZSBpcyBzYXZlZCBpbiB0aGUgVVJMIGZyYWdtZW50PGJyPjwvcD48L3NlY3Rpb24+

[Shuunen]

Wow nice !

I just looked at url length limitation, everyone agrees on keeping them under 2000 characters to have a good compatibility everywhere.

Your sample has a length of 244.

I tried to create a big BLT of random but in the end it was not persisted in url, I pushed it too far 😛

blt-random-art.zip

this is the url I have right now but it's just the beginning of my test

[jncraton]

Haha. Cool.

One challenge with just serializing the DOM like I'm doing currently is that any elements added by extensions or userscripts are also stored, so the storage requirements can get very large quickly.

I've pushed a change that uses LZ compression for the URI data. That should also help a lot with the size.

Here's your example art cleaned up a bit.

Ultimately, a proper serializer and deserializer will probably be necessary to make this work efficiently.

[Shuunen]

any elements added by extensions or userscripts are also stored

damn, indeed my grammar skills have been exposed ^^

I've pushed a change that uses LZ compression for the URI data. That should also help a lot with the size. Here's your example art cleaned up a bit.

cool ! why not use the npm pkg ?

Ultimately, a proper serializer and deserializer will probably be necessary to make this work efficiently.

is this not enough for a first version ?

[jncraton]

why not use the npm pkg ?

I'm not currently dependent on Node, so adding the entire Node ecosystem when I only need one JS file seemed a little excessive. I did use the JS file from that project.

is this not enough for a first version ?

I'm not comfortable with this currently. Here are a some of my concerns:

1. If this feature is made generally available, I need to make sure that URLs keep working in perpetuity. That makes future changes to the application more difficult.
2. I'm not comfortable with the current privacy implications with regard to data created by the user agent being shared with others in a way that is not expected. This could currently reveal private data stored in the DOM by extensions.
3. The current implementation is a textbook XSS attack. That shouldn't matter much for the Netlify version, but this could create very real security implications for anyone who decides to self-host this on their own domain.

In terms of functionality, though, this does seem to get the job done.

[Shuunen]

adding the entire Node ecosystem when I only need one JS file seemed a little excessive

I agree, npm independent projects are quite rare these days, and surely faster to use (clone & start)

I need to make sure that URLs keep working in perpetuity

Do you mean no-breaking changes ? Because it's commonly accepted when projects jump from a major version to another major according to SEMVER

I'm not comfortable with the current privacy implications with regard to data created by the user agent being shared with others in a way that is not expected

Maybe a share floating button could display a modal and link with a note below explaining risks of sharing this url (just used as a quick mocking tool, nice ^^)

The current implementation is a textbook XSS attack

Right, maybe not taking the DOM as input would solve this, so this get back to serialization

[jncraton]

Do you mean no-breaking changes ? Because it's commonly accepted when projects jump from a major version to another major according to SEMVER

Not necessarily. I just want to minimize breakage as much as possible. I'd want to have versioned URLs between major versions so that users can still access their old data. If I'm storing the entire DOM as data, even a seemingly minor change could require a major version change, creating more work for everyone.

I've pushed a change to serialize the elements more intelligently. This uses less space for most documents than before, obviates the need for a compression step, and should take care of the XSS issue.

Here's your example again.

[Shuunen]

\o/