Could it be that the problem is Controller+Template is less convenient than a single file LiveView?
And, in particular, that it could be easier to go from a static/dead page to a LiveView by changing only a few things like route definition and perhaps a top level use invocation in the controller to turn it into a LiveView? In addition to being able to colocate controller and template like in a LiveView.
I feel I can understand the wish to “default to LiveView for everything”, as I’m doing the same and writing a controller feels awkward.
But I also feel adding more modes to the LiveView lifecycle is going to make reasoning and creating a mental model of it even harder.
The original idea was to turn off the connected render. That affects existing patterns like deferring actions to the connected render, async assigns, pubsub subscriptions, etc.
Steffen proposed auto_connect: false with different semantics. IIUC that feature would create situations like a supposedly static page behaves differently if you load it via regular HTTP request or if you live navigate into it. Presumably, regular request would leave you in a disconnected state but live navigation would stay connected, changing the behavior of <.link>, for example.
So in one such LiveView’s that opted into auto_connect: false, mount would be called in either a connected or disconnected state. I think that requires a developer to understand all the nuances of the original lifecycle, plus this new mode, which is a net negative for me.
I think I’d rather revisit Controllers and see if working with them can be made more like the LiveView authoring experience.
