A lot has happened for the Phoenix.LiveController library and its API in last weeks just as it did for Phoenix and LiveView itself - which has finally became a true first-class citizen in the framework. With that in mind and with below recent changes, it’s a great time to remind you guys that phoenix_live_controller offers an (experimental) alternative way to structure your LiveView-heavy projects.

Plugs: Live controllers may now easily organize & run reusable logic such as user auth (works great with new mix phx.gen.auth!) or anything else - consistently regardless if mounting, handling params, events or messages. It includes a powerful conditional filtering mechanism via the when clauses, making it easy to plug into any chosen part of the live view lifecycle.
More info & examples in “Chaining & plugs” section of docs.

Easy access to URL and session: URL and session, passed by regular live views at various moments in the lifecycle, may now be grabbed consistently and at any time via the get_current_url/1 and get_session/1 helpers.

Extra annotations: Mount opts, such as temporary_assigns may now be specified on per-action basis via the @action_mount_opts annotation. More info & examples in “Specifying mount options” section of docs.

But perhaps most importantly considering that I’ve taken the risk of shaping live controllers in different direction than one proposed by Phoenix 1.5 live generators, I’m doing some real battle testing developing a real-world LiveView-heavy project using this abstraction and so far it proves really efficient. I may discuss this further soon but so far I consider it an alternative worth at least taking a look - especially if, like me, you want to go all-in with live views in a way that lets you hold on to some battle-proven features of Phoenix, like plug chaining or templates & views in separate directories.

See you all on GitHub!