Still working on my wonky application. It would be helpful to me if I had a way to interact with LocalStorage directly from an action. I am philosophically opposed to gathering and retaining information from/about my users. It would, however, be nice to maintain some state with respect to their preferred settings/views to save them annoyance and/or clicks on load.
I know that “local-first” is a long-term priority, but I couldn’t find LocalStorage on the roadmap. Is this in the zeitgeist somewhere? It might even be explicit and I lack the ability to spot it.
I would offer to help make it happen, but my “simple” HOLO formatter is already a month on with no real timeline in sight. (I apologize for that slowness; life gets on the way much more aggressively than anticipated!)
In short think that it could be as simple as using:
value = Hologram.JS.call(:localStorage, "getItem", ["key"])
Right now it’s easiest to save it on the server. With JavaScript Interop feature Hologram would definitely gain tons of features and use cases. We just have to wait for the decision and implementation.
This is a non-starter for me for a number of reasons.
In any case, I had looked over that thread before, but I guess I didn’t recognize that I am looking for a browser API. It makes sense now that you’ve said it. I appreciate the pointer!
Fully understood, but we can’t expect everything to work in current Hologram state. Therefore maybe you can consider mixing Hologram and LiceView, so LocalStorage-related pages would be done in LiveView and then you can store it for session in Hologram. This is not the best for sure, but it could work. Of course it may not be good solution for number of other reasons, but I’m not sure if we can do something else besides it.
In theory you can add an external script in the layout which would “watch” for specific elements and change in them, save them in LocalStorage and modify on the next page init. You know the light/dark theme switcher can be done fully in CSS and so the JavaScript code would have to set the initial value. This is also bad for various reasons like the fact that the theme would visually change on page init if non-default value has been saved.
This all sounds reasonable. Of course, i am an unreasonable guy.
The application on which I am working is actually being converted away from LiveView. I had JS hooks there which handled LocalStorage (and some other stuff which I now get “for free” from Hologram!)
It’s not so much that I cannot make it work as that I would like to push the bounds with Hologram. To be clear, I have on the order of 5 users who are used to me mucking about with the application to suit my whims. So, it’s not at all a blocking issue for anyone, including me.
I’m certainly not complaining about missing features and demanding relief. I’m mostly just noting that I have a “real world” Hologram application and this would help me. Frankly, I am much more interested in being able to turn async OTP messages into component/page consumable messages. I’ve mentioned this before and I know where it is on the roadmap, so I mostly keep schtum about it and follow along at home.
Thanks again for the guidance; I truly appreciate your time even if it looks like I’m being a stubborn PITA.
For storing user preferences client-side, have you considered using Hologram sessions? They’re cookie-based, so everything is stored client-side anyway - no server retention of user data. That might be the simplest solution for your use case.
There’s no proper JavaScript interop yet, but there are some basic primitives you can use temporarily (though fair warning: these might change or be removed when proper interop lands). There’s a Hologram.JS.exec/1 function that can execute JavaScript snippets. In your case, something like this should work (haven’t tested it myself, but the approach is sound):
# Setting a value
JS.exec("localStorage.setItem('theme', 'dark');")
# Getting a value
theme = JS.exec("return Type.bitstring(localStorage.getItem('theme'));")
Regarding the roadmap - I need to update it, because basic local-first data storage is closer than it appears. I wouldn’t call it a long-term goal anymore. The vision is that LocalStorage use cases will eventually be handled by the local-first autosync datastore. It’ll likely have a concept of models where you can specify that particular data should only live client-side, or be encrypted client-side before being stored in the central database for privacy. The main idea is that this store would handle all persistent data storage client-side, so direct LocalStorage access wouldn’t typically be needed.
And no worries at all about the formatter - I really appreciate you helping out! Life happens, and I’m grateful you’re contributing.
I looked at these, but something in the docs put me off. Let me see if I can find it. I guess it was these two bits:
Minimize session data - Store only necessary information to keep memory usage low
Clean up on logout - Remove sensitive session data when users log out
I don’t have any conception of a “log in” and, consequently, no “log out.” I didn’t know if this would have some kind of knock on effect on the size and contents of a “persistent cookie.” Moreover, I don’t really know what the lifetime will mean. I reckon it’s no big deal to simply reinitialize a missing session. It’s no worse than what I have now, modulo potential surprise.
My settings data is pretty small (maybe 100 bytes today and growing to 1k seems inconceivable. However, I am highly sensitive to adding additional transfer. Mobile data is both the default and stupidly expensive here. I’d prefer not to expand payloads wherein the contents are ignored.
This is actually what I was hoping to hear! I don’t have any special love for LocalStorage or SessionStorage or IndexedDB or knowing the differences. I’d just like to be able to have the user indicate “this is how I like these displayed” and be able to save/restore those values without involving a server roundtrip.
Thanks for the update; I remain excited and engaged!
