The generated code for mix phx.gen.live ... directly subscribes to PubSub on mount of the index and show LiveViews.
Isn’t it necessary to check if the socket is connected?
I was used to the pattern of:
def mount(_params, _session, socket) do
if connected?(socket) do
Phoenix.PubSub.subscribe(MyApp.PubSub, "topic")
end
There was a code review comment at add scopes to generators by SteffenDE · Pull Request #6102 · phoenixframework/phoenix · GitHub when the relevant code was added, but the check for connected socket was not mentioned.
While this doesn’t bring an immediate bug (the disconnected LiveView process will unsubscribe when the process goes away), the traditional check would be better.
Cc @steffend could you please confirm?
We should only subscribe when connected. Fixed in only subscribe if connected by SteffenDE · Pull Request #6215 · phoenixframework/phoenix · GitHub. Thank you bringing this to my attention @netto, @rhcarvalho!
Hi! How stable do we think the rc1 release is? I am about to start a new project and would like it to be based on the new 1.8 architecture.
Question maybe easier: when do you think your project has to be stable? 
Going with an RC is almost always worth it as long as it’s pre-prod. Changes are high the final is out before you complete your project. If not, it’s a small project and adapting it is not that big of a deal.
ps. I would go with main branch for new projects. Especially for the generators as you can see they have been finetuned.
I installed Phoenix 1.8.0.rc.1 to have a look and play around with the new features.
With the new magic-link integration, it seems that in it current state, UserLive.Settings has been simplified a lot while other pages such as “reset password”, “forgot password” have been (temporarily?) removed.
https://github.com/phoenixframework/phoenix/issues/6041
What’s the current plan about these pages? Are they going to be re-implemented later-on or is the idea to simplify the generators and skip these password related things entirely?
They won’t be coming back (unless you re-add them to your app yourself), because one benefit of the magic link solution is that you don’t need separate “reset password” and “forgot password” pages. If you forgot your password, you can just sign in by magic link and change your password on the settings page!
A magic login link is a “Reset Password” link without the mandatory setup of a new password. If you want to have a reset password functionality it would be a magic-link with auto-redirect to the password page in settings
Do we water down with magic links?
The usage of magic links makes a mailbox a global temp-password storage. The reset-passwords features of websites already caused it to be, but magic link goes further: it removes the ‘inconvenient’ step for a hacker of setting a new password for each site when he has compromised the mailbox. So auth-wise we loose the inconvenience defense.
The major benefit is people stopping to use the same super simple passwords for every website -as they forget complexer/site-unique passwords all the time- and hopefully have multi-auth on their mailbox making magic links a win.
I see, thanks for the clarification. I actually like the simplified version better as generated email and password management is something I like to tweak most of the time.
One thing that seems to have been forgotten in the generator update/refactor: the :current_password virtual field is not being used anywhere else in the codebase.