Oh I misunderstood the docs then. Interestingly use cases for this one.
1 Like
I guess for the first time in phoenix release history, we are getting into a release, where library maintainers have to do some homework. If your library contains anything visual, (most libraries do) - you are going to get into a release where you have to specify that your library will not work properly for phoenix 1.8.
Assuming we have a library built for <1.8, most likely it will be styled using tailwind - and - now - with default daisyui for phoenix 1.8, the library will not work properly - atleast the colors part of it. Further, from now on all the library maintainers have to maintain atleast 2 versions of the UI - one with plain tailwind - and - another with daisyui.
Any ideas, recommendations or suggestions for the best way forward?
1 Like
You don’t have to use DaisyUI as a library author, just because Phoenix includes it for its base components.
1 Like
This is not the first time phoenix generators changed their look and feel. There used to be milligram.css and eventually it was replaced with tailwind and now extended to tailwind + daisy. I also doubt this’ll be the last time this will happen.
3 Likes
What if the component has to integrate into the application of the end user? Say - something like an advanced table component?
Then you make your component library themeable. This has nothing to do with DaisyUI; all components need to be themeable.
1 Like
I’m not sure how worthwhile it is to style a library to (only) match the phoenix generators, given there’s generally the expectation that users move away from that look and feel anyways. These are starting points not frameworks to stay within.
1 Like
Many thanks for the ongoing work and releases.
I have a question on the auth generator, please. I used phx.gen.auth in v1.7, and my project requires user email address to be optional, including at sign-up time. I’ve added a username field and plan to tweak the generated authentication solution to make email address optional.
From the v1.8 RC0 auth gen page:
Developers are not required to migrate to the new generators, although we recommend setting up your own scope, as defined in the Scopes guide.
For when it comes time to update to the release of v1.8, do I understand correctly that continuing to use the (modified) auth setup generated in v1.7, with scopes added according to the v1.8 guide, is a reasonable and maintainable option going forward?
2 Likes
How to update DaisyUI within Phoenix 1.8 when DaisyUI itself gets updated with new components or bug fixes?
Will Phoenix team be releasing new versions of Phoenix or how to go about it?
Thanks
Contents of generators have always been generate-once, then it’s up to the user to keep that code up to date. It’s the same with daisy ui. This is however not to say that phoenix might update the generators from time to time, so new projects will be generated with a more up to date version.
1 Like
Maybe a dumb question: are there benefits to using scopes if you’re using Phoenix channels? It seems the benefits are clearer when using plugs or Liveview.
Currently, I assign the user to the socket on connect and then inside a channel join, I assign other things to the socket like org and then grab them later with socket.assigns.
I suppose it might be kind of nice to have one %Scope and then basically your context functions always look for %Scope rather than needing to pass in %User and %Org separately. Are there other benefits? Could / should it be used as a mini cache to avoid hitting the db for authorization checks, e.g. store a list of organizations they can access and then you can avoid checking each time (I guess you’d need to update this if their membership status changes during their session)?
Appreciate any insights.
The change is more about the generated context functions. They now receive the scope (whatever you put into it) as first argument.
So now we (cough…can remove some macros…cough) don’t need to modify the context functions anymore
So it does. Whatever you put into it is up to you.
I definitely gonna abuse it to reboot How to get name of 'calling' module and/or function? adding the caller into the scope (don’t worry, i won’t)
1 Like
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!
4 Likes
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.
1 Like
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.
3 Likes
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.
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!
1 Like
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.
