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.
2 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
