AZholtkevych
commented
11 months ago Link to the discussion: https://dockyard.slack.com/team/U03GBMZ68JE
Entire discussion:
May Matyi 1:35 PM @Carson Katri Do we have an established pattern or abstraction for caching data that originates from the server on the client, particularly for session tokens and the like? I know it’s possible to do this through messing about with the custom registry but I feel like its a common enough use case that we should have a solution for it. 1:37 If possible, it would be nice if this could be handled by core so that its available for all platforms. I’m imagining an API that gets exposed via the platform’s FFI bridge that has put / get / delete methods for storing basic values like strings so that they’re available if you quit and relaunch the app.
bcardarella 3:10 PM Anil did this for the original chat app and the TODO app 3:10 @May Matyi I don't know if he established a pattern or just found a place to stash 3:10 but maybe the Registry should do this?
May Matyi 3:11 PM Yeah, its possible with the custom registry but kind of a pain point IMO (edited) 3:11 I think for such a common use case we should have a formal solution or an add on lib right?
bcardarella 3:11 PM I agree we probably should have a pattern for this 3:11 but I defer to @Carson Katri on the "how"
May Matyi 3:16 PM I do think having an underlying representation of clientside state (i.e. in liveview-native-core) is worth considering though as this is something that every platform will need to figure out.
bcardarella 3:16 PM yeah, even LiveView web allows for this 3:16 there are certainly things that don't make sense to have as a server state (edited) 3:17 but what I wouldn't want is for people to just use LiveView Native as a api-less thing to send structured information over the wire for storage and client side handling 3:17 it's a fine line
May Matyi 3:18 PM mhm, I think we should just start with primitive values like strings and ints; especially if we’re handling this in core to simplify the FFI path between Rust and whatever language the linked platform library is using
bcardarella 3:19 PM yeah things like you're referring to for auth state I assume?
May Matyi 3:19 PM correct, the main use case I have in mind is storing a session token so that when I close and open the app it preserves my login state
bcardarella 3:20 PM yeah that's completely reasonable... if you are blocked by this I suggest just stashing somewhere you can get it for now and when Carson is back tomorrow we can chat about a better long-term API :+1: 1
3:20 we should open an issue for this @alex.zholtkevych
alex.zholtkevych 3:22 PM On it
matthieuchabert
bcardarella
carson-katri
We have to have an established pattern or abstraction for caching data that originates from the server on the client, particularly for session tokens and the like? I know it’s possible to do this by messing about with the custom registry but I feel like its a common enough use case that we should have a solution for it.