Yeah, because LV is all over a websocket you cant alter the cookies so your stuck with local storage or another system.
From what I recall, you can do hacks like trigger a HTTP request from JS to adjust the cookies from LV, but it wont propagate into the LV, so you end up double handling everything.
My other option when I was thinking of this was to spawn an
Agentto store the state (using themix phx.gen.authuser_tokenas key) but I wondered if it was overkill.
In this case your agent would probably become a bottleneck where every view will have to wait for the agent to sequentially handle each “get_var” call as messages are processed sequentially,
Instead you probably want an Agent/GenServer per LV, so each handles its own “persistent state”
Previously I have done similar to what you describe, using the live_session_id from phx.gen.auth as a way to look up the correct genserver. phx.gen.auth also generates some broadcast messages on logout that you can use to tear down the servers (but I still have an automatic “no messages in N time, kill” callback (See send_after, Registry).
The ETS table has concurrent reads and a simpler & existing interface, so its probably the best “out of the box” option where you can just pair the records against your auth token or whatever, just be aware you need manage eviction or the memory will continue to grow.
I would preference ETS over separate genservers unless there is clear behaviour to associate with the data (eg: they can set the value and it should revert after n minutes or something or you’re defining workflows between liveviews that are dependent on other services, etc).
