This likely won’t be relevant to a lot of devs here, because the remember plugin does the job fine in most cases, but:
Here’s a normal text input (id is not needed for this example, but is almost always needed so adding it here):
<input id="thingyInput">
And here’s one which remembers what you type into it even after page refresh:
<input id="thingyInput" oninput="localStorage.thingy=this.value" value="[localStorage.thingy || '']">
Of course, the remember-plugin can do this for you, but I often find myself reaching for the above pattern for its simplicity.
localStorage is what the remember-plugin uses behind the scenes - whatever you store in it will be persisted even after page refresh. It’s a built-in browser/JavaScript feature - not something that’s specific to Perchance.
The || '' in [localStorage.thingy || ''] means or ''. In other words, it means or output nothing. If you want a default value for when the user loads the page for the first time, you could write [localStorage.thingy || 'blah'] which means “use whatever is in localStorage.thingy if it exists, otherwise use ‘blah’”
You could even do something like
localStorage[this.id]=this.value. Not sure if that would work for getting the value though… 🤔Quick question on this topic… is localStorage “safe”? Does it only store for that specific generator (like, localStorage’s behavior is overridden for that), or can it pick things up and change things from other generators?
Quick question on this topic… is localStorage “safe”?
The
localStorageis contained inside each generator, meaning that values set from one generator can only be accessible from that generator (like not tied within thelocalStoragefrom the entire Perchance website), so it is safe. Basically, every generator has its ownlocalStoragecontainer, and there’s an explanation to why.Ooooh, okay. So secretly they’re running from their own subdomain, and subdomains have their own localStorage I think. Great 👍
is localStorage “safe”? Does it only store for that specific generator (like, localStorage’s behavior is overridden for that), or can it pick things up and change things from other generators?
Yep, it’s safe. Each generator gets their own subdomain, and browsers partition storage based on subdomain/origin, so one generator cannot read the localStorage of another generator. If you want to do that, then you need to control both generators, and you’d need to embed one within the other, and use postMessage
Thank you 👍
Yeah, it’s just not easy to figure out that actually generators are running in their own subdomain–once someone explained that, I could see how it worked 😁
I remember this one using only the
localStoragething and I think I’m actually using this in some of my generators. After trying this a bit, I found a benefit from using this method, that the data will stay in the input even if the generator is reloaded through the
feature when editing the generator’s code.Using the remember plugin, in normal circumstances, that would reset the value when it’s auto-reloading. And I’d also like this kind of behavior to be implemented right into the plugin so that remembered variables (and not just the user inputs) can retain its value even when auto-reloading generators.
Ah good point. I think for this what I’d ideally need is a global ‘onUpdate’ function so plugins can ‘do something’ when the
updatefunction is called (as happens with the auto-reload checkbox thing). There are hacky ways to do this (effectively “wrapping” theupdatefunction), but it might be about time for a proper solution.
I want a suggestion. And a report as well. The remember plug-in is totally amazing, I can agree on it 100%! But, the remember plug-in has one flaw; it cannot detect programmatically changed values.
Now, calling it a flaw might be an overstatement, because I, myself created an entirely new script to perform automatic saved and load of values, and that too cannot detect changes made hy program. I tried to tweak it a bit, but I was still unsuccessful.
Fair point! I think I can fix this (using MutationObserver), but it’ll need to be opt-in (e.g. via an extra keyword like
@includeProgrammaticInputsor something [but ideally shorter…]), since it’s a “breaking change”. But before I do: Another flaw is that you can’t choose to only remember specific inputs, right? My memory is a little fuzzy and I can’t see anything about that on the page or in the code. If so, I’ll try fixing both issues at once.
