Our great sponsors
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
I wrote a library for storing application state in the URL. Its novel feature is using fragment query, which prevents the information from being sent to the server.
https://github.com/Cyphrme/URLFormJS
I would love to see it get more use.
Here's a small demo: https://cyphrme.github.io/URLFormJS/#?first_name=Bob&last_na...
See my other comment on this page for some other examples of its use.
This is quickly becoming a standard in apps and it really shouldnt be handrolled since its such a common requirement and easy to get wrong (between serializing/deserializing/unsetting states). In Svelte it is now as easy as using a store: https://github.com/paoloricciuti/sveltekit-search-params
in general i've been forming a thesis that there is a webapp hierarchy of state that goes something like:
1. component state (ephemeral, lasts component lifecycle)
2. temp app state (in-memory, lasts the session)
3. durable app state (persistent, whether localstorage or indexeddb or whatever)
4. sharable app state (url)
5. remote user data (private)
6. team user data (shared)
7. global data (public)
and CRUD for all these states should be as easy to step down/up as much as possible with minimal api changes as possible (probably a hard boundary between 4/5 for authz). this makes feature development go a lot faster as you lower the cost of figuring out the right level of abstraction for a feature
https://convert.zamicol.com/#?inAlph=Text&in=Hello%20world!&...
https://cyphr.me/ed25519_applet/ed.html#?msg=Hello%20World!&...
https://cyphr.me/coze?verify&input={%22pay%22:{%22alg%22:%22...
I'm developing more tools to these ends, via my overarching project calculang, a language for calculations [1].
I also have a loan/repayment validator [2] but haven't added this QR code feature yet.
Bank letters e.g. "Interest rates are rising and now we want 100e more per month, every month" could use a QR code to an independent validator or to see the workings behind the 100 calculation.
Not using this in the real world now and there are security considerations to keep in mind, but reading state from a URL facilitates the usecase, QR codes that link physical numbers to their calculation and model.
Implementation of payroll calculator is an Observable notebook and thankfully it neatly supports all my strict requirements as a QR code demo.
[0] https://observablehq.com/@declann/payroll-playground-ireland...
+Feature tweet: https://twitter.com/calculang/status/1608183731533107206
[1] https://github.com/calculang/calculang
[2] https://observablehq.com/@declann/loan-validator-dev
I did something similar in a simple whiteboarding app that I made a while back:
https://github.com/jncraton/box-line-text
The data representation could probably improve in terms of readability, but I'm happy with the way it provides a concise encoding while still including the text from the document directly:
https://box-line-text.netlify.app/#;c2121Hello;5321;c1341Hac...!
Store the content in ipfs and just put the hash in the URL? I haven't used https://github.com/ipfs/js-ipfs in this capacity but I'm under the impression that that's what it's supposed to do.
I imagine I'm not the first one to think of this, but a little while back I wrote a toy pastebin-like webpage that stored the code being rendered directly in the URL (with base64 and gzip compression to make it a bit smaller, although it still was quite large by usual standards). My thinking was that rather than having a centralized app for this publicly available, making a small page that could be statically hosted would make it easy for people or organizations to host their own page with whatever security they need (e.g. behind a firewall or VPN) and then the links could be shared privately on Slack or whatever without a need to add functionality for determining who should have access or how long to keep the code snippet around and instead just piggyback off of the privacy of whatever channel/DM they sent it across and how long the Slack instance is configured to retain history.
When I first came up with this idea, I was going to write some sort of server backend rather than just doing everything in the frontend, but once I started actually working on it, I realized that it wouldn't really add any value and it would make it a bit more annoying for people to self-host. Since then, I've wondered a bit how viable "static pages with state in the URL that can be easily self-hosted" would be as an alternative to a desktop GUI or Electron app for more technical users. One of the nicest parts of this approach to me is that I was able to make in only a few hours one evening despite knowing only the basics of webdev from maybe 8-10 years ago and next to nothing about programming GUIs in general. This makes me think that it wouldn't be too hard for people to fork and modify it to their own liking (e.g. changing the hard-coded style settings for rendering the code snippets), so there could be potential for an ecosystem to grow organically around something like this.
In case anyone is curious to take a look: https://gitlab.com/saghm/pastml/
I did something similar using Racket's (nee PLT scheme) web programming module ( https://www2.ccs.neu.edu/racket/pubs/hosc07-sk-mf.pdf ) back with an app that got on slashdot -- https://github.com/holdenk/web2.0collage
The theory was wonderful (yay! stateless load balancer etc.) but in practice browsers at the time were less than happy with trying to store that much state in the URL.
Shameless plug: I made a library to encode any json as query/hash params in a human readable manner adhering to url friendly characters.
https://github.com/recurrency/urltron
Perfect use case for storing page state in url.
Here's the non-psuedo code equivalent that can leverage CompressionStream rather than using a browserified-gzip-library: https://github.com/GoogleChrome/lighthouse/blob/437eb4d757c5...
We use it in Lighthouse for the exact same purpose, a URL #hash full of state. We found that modern browsers support 10mb of data in the hash. https://github.com/GoogleChrome/lighthouse/pull/12509#discus...
About 6 years ago I had to do this on a project. We had charts with a lot of options and we wanted them to be bookmarkable and shared between colleagues. We started with base64, soon moved to a custom encoding with version support https://github.com/ananthakumaran/u
Yep, it is! You can find the sources on GitLab[0]. The compression is done using brotli-wasm[1].
The entry point to the compression is the syncCompress[2] function, which converts the data to UTF-8, adds the needed header bytes, and then compresses using brotli-wasm. Decompression is done in a streaming way in streamDecompress[3]. This is to avoid zip bomb attacks, where even a short URL could decompress to gigabytes of data, locking the browser. Thankfully brotli-wasm had streaming decompression builtin, I just had to write the wrapper code to update the text content and the status bar in the UI.
You can find the brotli-wasm code I'm using in the vendor folder[4], there is a JS wrapper and then the WASM code (both are straight from brotli-wasm).
[0] https://gitlab.com/Nicd/t
Depending on how repeative the object keys are, you maybe able to save quite some spaces with compress-json [1].
Since the OP is using lz-string to do compression, I suppose the data should be repetitive.
[1] https://www.npmjs.com/package/compress-json