Define a module with fixture functions that wrap factories, like:
def user_scope_fixture do
insert(:user)
end
1 Like
Nice release with a lot of interesting changes and improvements!
Scopes remind me of let_me and I think it’s a fantastic move to promote this to a Phoenix level concern.
3 Likes
Awesome release! Thanks to everyone working on Phoenix and related projects!
Special thanks to @steffend for numerous bug fixes, for always assisting folks with various questions in this forum, reviewing PRs and so much more! 
It’s great to be part of this community!
7 Likes
That thread was about building a mobile app and comparing native stacks, Flutter, etc.
As I see it, Phoenix and LiveView are for the web, and then there’s LiveView Native which attempts to bring that experience to mobile apps. I never tried it, and don’t know how far along it is, though.
Congratulations to the entire Phoenix team! I’ve explored various libraries over the years and started some projects with Phoenix + LiveView. During this process, I noted points that I found complex as a new user, and I’m happy to see that many of them have been fixed.
Previously, implementing layouts was complicated, and I often felt like I was doing more than necessary to get specific features. This has been extremely simplified in this new version, which makes me very satisfied.
The introduction of scopes in authentication was amazing! This approach is truly important, and I appreciate how the team implemented it in such a simple way for us to create new scopes.
Adding PubSub in contexts as state notifiers and how they interact with LiveView is really exciting.
I confess I’m on the team that would like a “–no-daysui” option to create projects without DaisyUI, but that’s just a minor detail.
Overall, I’m very pleased with LiveView and what was introduced in this new version. There are many features I haven’t explored yet, but I certainly will soon.
Thank you very much! 
You’re right about the topic of the thread, but Jose did say in the thread something to the effect that LiveView wasn’t mobile ready yet, with, I surmised, the implication that it might be eventually.
LiveView Native isn’t close to ready yet, but is certainly of great interest to lots of folks. In the meantime, it would be useful and desirable to run LiveView apps on both phone platforms. I’d be curious to know what needs to be done to make LiveView mobile ready.
2 Likes
You’d need to be more concrete at what you understand “being module ready” to be tbh.
LV really can be broken down in two essential parts – an elixir server running the webserver portion and a client (implemented in js) being able to turn html and changes to html into rendered and live updating websites.
LVN went the route of creating a shared custom client, which together with some iOS and android native parts can render an html-like markup language as native UI components of those platforms.
There’s also experiments by LVN to include the approach of elixir-desktop uses of running the server side parts on the local device – so elixir on the device itself.
Contrary to LVN elixir-desktop doesn’t come with a new/custom client though. It uses a small native shell as an app, which executes a webview – really an embedded browser.
So my question is what you’d expect to be able to happen short of the efforts taken by those tools, which would make LV something to be considered mobile ready. Moving the server requires being able to run the beam wherever the server shall be moved to. Having the client not run in a browser needs both a way to render the markup shared as well as the client written in a language able to run in the target environment – or a browser for rendering a website and running the existing client.
This is not to say LVN or elixir-desktop would be ready solutions to be easily picked up, but it’s also not the case that the LV team could somehow do the same work more easily or faster – to the contrary I doubt it’s their intent to move in that direction at all. Wherever José mentioned LV to not be there “yet” it likely referenced the work happening by the LVN team.
For a real blog with public pages, I’d start by doing the following:
- move the routes from phx.gen.live to an admin prefix, e.g.
/admin/posts,/admin/posts/new, etc. - add a new
list_posts/0function that does not require a scope and just returns all (published) posts - create separate LiveViews for the public parts of the blog
To keep the generators simple, we offer either scoped resources or completely unscoped resources (passing --no-scope to the generators).
6 Likes
Well, I can’t be more concrete since I don’t know what was meant by Jose when he said LiveView wasn’t yet mobile ready. I simply accepted this on faith, and started down another path, i.e. React Native, Expo, Firebase. I’m sure I’ll get there with these, but they are all new to me and the learning curve so far seems fairly steep. I already know Phoenix/LiveView and like it very much, so that would have been my preferred route.
As you can probably guess, LVN would be of great interest to me, but from what I can gather, it’s not sufficiently ready.
My target app will automate pool (i.e. billiard) league functionality for both players and league admins. It will have significant persistence requirements, will need push notifications, real time screen updates. Having users run the app in a mobile browser is totally fine.
Are there significant hurdles that argue against targeting Phoenix/LiveView for my application?
One last question. Does LVN also have both a client and server and client components? Or, do I have to write an API server of some sort?
2 Likes
I’ve played with the code already and can tell removing daisyUI when you so wish shouldn’t be too time consuming. Grepping through the code will reveal the small footprint - two vendored JS bundles, and a few lines of configuration in app.css.
Other than that, well, update css class names that refer to daisyUI components.
Another interesting thing I learned recently about daisyUI is that v5, which is the one shipping with Phoenix 1.8, will automatically compile down to only the classes you use, similar to Tailwind itself, thus keeping the final CSS bundle small, free of unused components - awesome!
4 Likes
I appreciate the response. Also, we may have a different idea of blog in mind, so let me flesh out my question a bit.
In most of the blogs and content systems I’ve had and/or worked on in the past, the vast majority of authenticated users are not admins and on publicly accessible view pages of content there are some actions (liking, bookmarking, commenting, etc) that are restricted to authenticated users.
For LiveViews where it is the case that some actions require authentication and others do not, is there a specific high level approach or pattern that’s encouraged?
Yeah, that completely makes sense. My inclination is to nearly always use the scoped generators and open up only what needs to be opened up manually.
3 Likes
Yes, a client piece and a server piece… but most of the actual app dev work is done on the server-side like traditional LiveView…
LVN’s strategy-- not technically exactly described-- is basically:
- The Native Client – eg. written in SwiftUI – compiles in the appropriate Native-client-side SDK; your native client code instantiates a native “LVN ui view component” that points to a server-side LiveView URL – this view takes the markup+data from the server and instantiates local native UI components.
- On the server-side, you’re writing LiveViews but use a different render markup language that is basically geared for the native platform you’re targeting (basically mapping SwiftUI on the swift side).
So no actual “API” in the traditional graphql or REST vein… it’s the same mental model of writing LiveView where events are sent from client to server and event handlers on the server takes action to return new UI to the client… as far as I understand.
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.
1 Like
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.
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 Likes
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 Likes
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” 
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 Likes
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.
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.
