update phoenix dep, install tailwind 4, & vendor daisy
I followed this repo: dayzee/assets/css/app.css at master · Gazler/dayzee · GitHub
Pal
1
cvkmohan
I am still a bit confused on the implementation of scopes. Sorry, if the question looks dumb. Most of the times, what the user can see depends on not just the user_id - but - the community in which he is a member of. For example, in a course - what teacher can see versus what student can see might be different. In an organization, what a manager can see versus what an operator can see might be different. What would be the case where one wants to see only the records that he created? I mean, suppose, we are building an ERP - showing only the records entered by the same operator - will not lead to any meaningful result. Is it that, in all such cases, scope is not useful?
Or are we saying that we do what is suggested in “augmenting scope” - and - extend it to organization? Just extending it to organization will not be sufficient then also - in the organization, what role he plays will determine what he can see. So, do we enhance the scope to include organization and role? And the augmented scope for organization takes care of filtering?
What conveniences scope will bring in such cases? I am a bit confused. Ofcourse, as a systems’ builder I can feel the advantage. Unsure, how to put it into practical programming.
3
steffend
Phoenix Core Team
Exactly. The idea of the scope struct is to provide a well-defined data structure that contains all the information that you need to render your page. So if your application has different user roles that decide what should be visible and what not, this information should be in the scope. For example:
%MyApp.Scope{user: ..., tenant_id: 12345, role: :teacher}
And in your Controllers / LiveViews, but, you can use @current_scope.role assign to differentiate if someone is a student or teacher.
Instead of a “role”, you might also store a list of permissions, etc.; but this is highly specific to the actual application that you’re building.
4
camcaine
So are scopes analogous to Current/CurrentAttributes in rails?
Feels like they serve a similar purpose. Which is cool if so.
0
sodapopcan
AlchemistCamp
I generally try to avoid ever tying authorization directly to a user. It’s much more flexible to allow each resource to be accessed by a list of groups (where each group can represent an organization, a role, an ad-hoc collection of users or just an individual).
Prior to the introduction of scopes, my auth setups have generally involved running an auth function that fetched the list of approved groups for a resource and action (both of which are available from the socket) and then allowing access if and only if the logged in user was a member of one of those groups. This is very flexible since it allows both adding or removing groups allowed to access a resource as well as changing the updating the composition of those groups as people join and leave organizations and roles.
As I understand them so far, scopes somewhat reverse this conceptually so that instead of thinking about who is allowed to perform a given action, you’re thinking about what actions the logged in user is allowed to perform.
2
hubertlepicki
I don’t think you can intercept :handle_info, but you should be able to intercept :handle_event.
I think it may be useful from the macro use case that you provided as example code, in fact I have a similar one that I could probably refactor to use life cycle hook. The example in the linked documentation also shows how we can avoid creating stateful components to respond to :handle_event Phoenix.LiveView — Phoenix LiveView v1.2.5
I guess this may be helpful from performance side of things, but the downside is that you now have to explicitly attach your callbacks in LiveView and it’s not something a LiveComponent down the tree of components can do on their own.
Even with macro, I don’t think a macro itself can anymore attach these lifecycle hooks, it needs to be attached from something like mount function in the parent LiveView, so the macro no longer is self-contained and requires the programmer to do two things: use macro and then hook the callbacks from mount function.
We probably also may need to end up with life cycle hooks being attached to parent LiveView that handle actions from components that we don’t even have rendered at given time. LIke, there’s some sort of “edit” button on a leaf component somewhere deep in the render tree and it’s not present on the page until you click that “edit” button. A row turns to editable variant once clicked and now you need to handle the events but we didn’t have to do it before. This requires the programmer to know a lot what can be happening during the program life cycle, and understand how the stack of components works and what needs to be attached and when, versus black-box approach provided by self-contained components known from, for example React.
1
LostKobrakai
You can:
Use
attach_hook/4on any of the following lifecycle stages::handle_params,:handle_event,:handle_info,:handle_async, and:after_render. To attach a hook to the:mountstage, useon_mount/1.
4
hubertlepicki
cvkmohan
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