How to manage session state with live view

[kuon]

When reading about live view, I read this from José:

@josevalim

LiveView does not intend to fully replace your stateless actions. While you could do the login through LiveView and keep it as part of the connection state, that would indeed be a horrible idea!

Why would the login be an horrible idea for LiveView?

And, as a more general question, how should session be managed when using LiveView. For regular app, and API endpoints, I usually just have a require_user plug that check the session for a user_id and retrieve the corresponding user from the database. My login action just |> put_session("user_id", user.id) after a successful login.

How would this work with LiveView?

[josevalim]

@kuon

Why would the login be an horrible idea for LiveView?

See the original text I was replying to. If you login through LiveView, then if you navigate to another page or open up another tab, you will have to login again. LiveView keeps the current page state.

@kuon

How would this work with LiveView?

When you render a liveview, one of the parameters is the session, which are the session fields currently in your session that you want to send to the liveview.

So if you do:

 live "/foo", FooLiveView, session: [:user_id]

Then the user_id field will also be available in the LiveView mount, which you can retrieve it from the database once again.

So the idea is to login as usual and then pass the relevant session fields to the live view.

[kuon]

Right, I get it, this is what I thought at first, but I wasn’t sure.

[daveboo]

So, I can still build my registration page with liveview, but when signing in, I should just use a normal Phoenix page?

[alvises]

@daveboo

I should just use a normal Phoenix page

Yes. If I understood correctly, LiveView can’t update the :user_id in the session and the LV session is distinct in each browser’s tab.

And two tabs in the same browser won’t sync with each other. Each LiveView session is distinct.

Phoenix LiveView is now... live!

So there are a couple important differences but some of the concerns are indeed shared. One of the major differences is that LiveView is not trying to reinvent the wheel on the UI side of things. LiveView is not “UI running on the server”, it is not about accessing the DOM from the server, nor it requires a special client side notation. In LiveView, the server simply emits HTML and the LiveView state is not intrinsically tied to the UI in anyway. This is an oversimplification but you can cons…

[daveboo]

Must have been a late night back in May…sorry I didn’t thank you, but this was very helpful, thanks!

[why]

@alvises

Yes. If I understood correctly, LiveView can’t update the :user_id in the session and the LV session is distinct in each browser’s tab.

Would I be mistaken in thinking that the latest version of LiveView (0.5.0-dev) solves this problem?

[benwilson512]

0.5.0-dev makes the session available but you still can’t edit it.

[why]

Got it, thanks.

[tfwright]

If I were set on storing some data about a LV session in the browser session, what would be the best way to do that? Add a vanilla JS link that points to a non-LV controller?

My use-case is that I would like to save some UI state for a returning user even if they don’t login (or have an account).

[mindok]

@tfwright - did you figure this out?

[tfwright]

No I never pursued a solution. I’m pretty sure what I suggested above is possible but I’m not really sure it’s best practice.

[mindok]

Ok, thanks. I know who my users are so I’ll just write a home-made user state store with updates straight from the liveviews.

[shahryarjb]

i’m confused, we put session with normal redirect to live router? and add session on live router ? that’s it? like

 live "/foo", FooLiveView, session: [:user_id]

it’s oky, but how can update phoenix session in phoenix liveview, becuase I used Oauth2 protocol, and every request I have to send refresh_token and access_token, and update new refresh_token after this. but I’m using Liveview, how can I do? I just can create a normal router which is AuthController but all of my pages are Phoenix liveview

and I have one more question, we have to pass new token every page ? in Liveview ? what about after updating session ?

[toranb]

I realize I’m really /really/ late to the party but I did blog up a solution I put together for login & signup forms in Phoenix LiveView if anyone is still hunting around for options

https://toranbillups.com/blog/archive/2020/06/26/cookie-authentication-with-phoenix-liveview/

[henrik]

And I’ve blogged about storing data in the session in LiveView: https://thepugautomatic.com/2020/05/persistent-session-data-in-phoenix-liveview/

[ricardo-h]

It seems that there is still no consensus pattern to solve the state management with liveview.

[kuon]

My solution was to create the login form in a live view, and when the login succeed, I generate a phoenix token and I redirect to /login/:token with a redirect in the live view, /login/:token is a normal controller that check the token and use put_session on the conn as usual.

[slashmili]

TL;DR: use phx_trigger_action

I’ve came across this thread multiple times past few months while I was looking for a solution, I was about to implement the workaround that people are offering(calling an API to set session) here but I learned about phx_trigger_action attributes for form bindings.

The phx-trigger-action attribute can be added to a form to trigger a standard form submit on DOM patch to the URL specified in the form’s standard action attribute. This is useful to perform pre-final validation of a LiveView form submit before posting to a controller route for operations that require Plug session mutation.

Kudo goes to Pragmatic Studio’s Phoenix LiveView couse. I highly recommend it!

[shahryarjb]

@slashmili

Kudo goes to Pragmatic Studio’s Phoenix LiveView couse . I highly recommend it!

when you use this you have this problem Bug in navigating from a controller to a LiveView page (put_flash message will not be deleted)