I took what José said to mean that LV was ready to be used in a “mobile first”/offline mode/PWA type situation. I didn’t take it to mean that LV wasn’t ready to be used as a mobile web application.
jswanner
CharlesIrvine
That is a very important clarification for me. My unfamiliarity with much of the technical context probably prevented me from gaining a proper understanding. I’ll go reread the thread. Thank you.
0
sreyansjain
I have one question regarding the scope. Normally when we create a foreign key using references, we generate an index for it. But the new scope doest not generate an index by default.
I think it would be a good idea to generate an index for the scope column in every new table that gets generated and has a scope. What do you think?
2
woylie
We’ve been using a %Session{} struct in one application, but that term is overloaded as well. I considered naming the struct %Context{} in another application, which would align with the naming used in the Absinthe documentation, but I settled on %AuthSession{} to be more specific. The struct contains the current user, AAL (authenticator assurance level), remote IP, session start time, and token ID in our case.
3
sodapopcan
Ha, yes the first time I ever used this pattern (to clean up the application I mentioned above with both company and user being god objects that were checked everywhere) I called it UserSess basically stealing it from one of Device’s controllers and shortening it (which I generally dislike doing) to make it “a little less ambiguous” 
0
thiagomajesk
Just getting back to the forum after a while, what a great announcement!
The idea of scopes reminds me a bit of the CQS pattern (or at least the “design by contract” part if you will). I’ve done my fair share of DTOs during my .NET days, and although being too strict can be annoying, it’s an approach that really helps consolidate your data access patterns (and it makes your system dependencies more predictable). Also love the changes around generators and layouts!
Congrats to everyone involved in the release! 
2
byu
I wasn’t part of developing scopes, and don’t have an opinion yet.
My response wrt LiveViewNative is just as a very interested party that did a deep dive rabbit hole into the code and watched their tech talks.
So, apologies, you might need to direct your inquiries to others in this thread.
0
sreyansjain
I am sorry I didn’t mean to reply to your comment. But accidently it happened and by the time I realised I was not allowed to delete the comment. Sorry.
0
steffend
Phoenix Core Team
https://github.com/phoenixframework/phoenix/pull/6186
It was an oversight, here’s a PR to change it.
5
steffend
Phoenix Core Team
I see. I was mainly talking about the management part, similar to how you have /wp-admin in Wordpress for managing. Despite the name it’s not only for admins.
For mixed pages that show some content based on the user being authenticated, I’d probably still use different live_sessions to clearly separate the “management” from the “mixed” part of the app. On the mixed pages, the live_session would then assign the current_scope, and you can conditionally render the elements that are only available to authenticated users. That said, having one live session and doing the checks in each LiveView also works, but you need to be more careful.
1