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.
schwarz
3
rhcarvalho
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.
0
emanoelims
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! 
0
CharlesIrvine
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
LostKobrakai
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.
0
steffend
Phoenix Core 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
CharlesIrvine
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
rhcarvalho
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
AlchemistCamp
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