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’”

  • wthit56@lemmy.world
    link
    fedilink
    English
    arrow-up
    3
    ·
    3 months ago

    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?

    • BluePower@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      1
      ·
      3 months ago

      Quick question on this topic… is localStorage “safe”?

      The localStorage is contained inside each generator, meaning that values set from one generator can only be accessible from that generator (like not tied within the localStorage from the entire Perchance website), so it is safe. Basically, every generator has its own localStorage container, and there’s an explanation to why.

      • wthit56@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        3 months ago

        Ooooh, okay. So secretly they’re running from their own subdomain, and subdomains have their own localStorage I think. Great 👍

    • perchance@lemmy.worldOPM
      link
      fedilink
      English
      arrow-up
      1
      ·
      3 months ago

      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

      • wthit56@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        3 months ago

        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 😁

  • BluePower@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    2
    ·
    6 months ago

    I remember this one using only the localStorage thing 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 auto-reload 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.

    • perchance@lemmy.worldOPM
      link
      fedilink
      English
      arrow-up
      2
      ·
      6 months ago

      Ah good point. I think for this what I’d ideally need is a global ‘onUpdate’ function so plugins can ‘do something’ when the update function is called (as happens with the auto-reload checkbox thing). There are hacky ways to do this (effectively “wrapping” the update function), but it might be about time for a proper solution.

  • Cocell@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    6 months ago

    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.

    • perchance@lemmy.worldOPM
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      6 months ago

      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 @includeProgrammaticInputs or 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.