Great to hear! I actually have done that, but I haven’t written a guide on it yet. One way to approach it, as I decided to do, can be figured out by following the archived example from Dashbit’s bytepack_archive.

It’s a bit more complicated than the registration flow since it uses live_component, especially adding the two-factor authentication with their nimble totp library, but it works amazingly.

Then, it’s just expanding on your application a bit to possibly break a single settings page into a Live View page with interactive tabs (tabbed pages) — but that’s just dependent on your app’s preferences.

Oh, lastly, it’s worth noting that it is a similar concept as before (and as @LostKobrakai mentioned), where you interact with your phx_gen_auth generated controllers through your Live View process. Typically, you can just make the swap between conn and socket thanks to how Phoenix is designed.

In a .leex template file all conn references are socket references and vice versa for a .eex template. The Programming Phoenix 1.4 book helps explain how Phoenix handles the connection (and many other things).

I would start by cloning the Bytepack archive, then looking over how they implement their settings page. It’s an incredibly great learning resource.

In the meantime, I’ll post back here if/when I write a Medium guide on it. Good luck!

You’ll need classical controllers for everything needing to modify the session. So as you did you can handle the forms in liveview, but they need to submit to a controller. This also kinda means you might need to share some form handling / changeset stuff between the liveview and the controller.

Same goes for logout, which needs to be in a controller given it needs to remove stuff from the session. This however is usually not a problem given it’s often just handled as a link/2 with method: :delete and not a manually created form.