@alvisonhunter
Weeeeeeeeelcome to SYNtaxxxxx!
@dustinpoissant
We (I work at a large development company) use session storage for tracking/tagging analytics type stuff that is session specific. For instance, if you come to one of our sites from an add, there is a campaign id that comes as a url param, we save that to session storage, and then when you "convert" we know what ad platform/campaign brought you in. But we want that to go away if you close the session and come back later from another ad. Or come back later organically we want it gone. Thats the only time i have used session storage
@jwr6796
It's been really interesting seeing all the local first stuff come to prominence in the last year or so. I have been working on an app for my employer that is essentially local first, though I didn't know to call it that in the beginning. Essentially, every client device needs to have a record of data so that it can function offline, and then when it reconnects it needs to be able to synchronize that data with the cloud and with all the other devices. It's kind of been a syncing nightmare, but it's been a ton of fun, and I've begun to implement some of the steps that I've heard on the podcast to make it a bit sturdier than just passing around JSON blobs
@Dyanosis
Local Data for remembering dark vs light theme for switchers. Session storage too if it's very temporary (like don't care if they know what it's like later). One thing I'd like to see is some way to handle data that is more local to the user and not to the computer. You guys mentioned that Local Data could be a PII problem for filling out forms on a shared PC.
@brunocrosier
heads up, the part about session storage is not actually correct. if you save something to session storage in one tab, and then open another tab with the same domain, the data will be available in both tabs. the data is only deleted by the browser when all tabs on that domain are closed
@armandodlvr
I think the correct name is IndexedDB
@hugodsa89
You are authenticated as your user, and your user is authorised to perform or access something. authentication = identity verification authorisation = permission verification
@saidyeter
I used dexie too. pretty useful
@Kayotesden
I was hoping for a bit more indepth into each of the solutions coming up. ElectricSQL & Zero look awesome!
@PrintNerdyForMe
Authentication is who you are. Authorization is what you can see/do.
@dmgithinji
Another use case for storing local-first is for end-to-end encryption of data. Data in the server is always stored encrypted while locally the data can be stored unencrypted/encrypted then decrypted during sessions. This way one could still do text-based searches with encrypted data which is really hard to do server-side.
@RT-mn2pb
You missed a basic use case for any of the local-first client-side data model: Disconnected Operation. Several apps I've worked on must be able to run with the user disconnected for some period of time from a network either by accident or as part of normal operation.
@cyrusgracias4556
One edge case we had to face was Localstorage, sessionstorge arent available on Android while website is run by Android Google Sign In flow We had to revert everything to cookies usage
@mnismi
Another usecase for Session storage would be The search filters in an ecommerce website You go into a product and come back or refresh the page accidentally (on mobile pulling down), the search filters stay the same.
@ransomecode
I store data in svg <defs>🤣
@alastairtheduke
Migrations, at first glance, look pretty difficult with these services. I'm curious how tanstack query persist plugins work , anyone try?
@alamacademi
First one here
@JTWebMan
When will Zero let everyone try? They still show a signup.
@codedusting
Local storage for jwt token is insecure, isn't it?
@nunya44288