I’ve just scaffolded a new Phoenix 1.8 app to see what a new app structure looks like.
I was trying to identify and see how everything is now wired together, but I could not find any initial usage of the function [MyApp.Layouts.app/1]( phoenix/installer/templates/phx_web/components/layouts.ex at 19f81cc2fc5e9f8e2c73921622d1b18dd0d96544 · phoenixframework/phoenix · GitHub ). It feels like it’s just illustrating a potential use but not actually being used as part of a new app.
Is this assumption correct and if so, should it really be shipped as part of a new scaffold?
Initially it is indeed unused, but once you generate for example a live view with mix phx.gen.live you will find it being used in every generated page.
1 Like
Ah I tried that command now and it did make use of it, makes sense.
Question is, if you don’t supply the `–no-live` argument during initialisation of new project, should a controller config really be added. I feel like if you want a live project it should only ship with that config and if you want a controller based config it should only ship with that. Then if you need to add support for one or the other you can add that config afterwards. My guess is that this would make a new project easier for new devs and senior devs to see the design patterns and philosophy of the Phoenix dev team.
But I dont have the full context of this, maybe I am missing some details?
I have never given it much thought. Am not entirely sure what you mean by controller config too.
Most of my projects contain both live views and controllers, although the controller actions tend to be webhooks, downloads, etc.
That’s also my feeling. I think the community is moving to only using Live View for building actual apps and then controllers as a “REST API” option for when you need to perform specific actions like to your point webhooks etc etc.
It would be interesting to see a further simplification to the base configuration where Live View is the focus and only what is needed and recommended by the framework maintainers to build a live view app is what ships. I find that it can be hard at times to see how projects should be structured when we host live view and controller templates in the same code base.
The layout component is the replacement for the old root/app layout system. It’s not just for generators, it’s meant for use by you in your templates. Like much of what Phoenix generates, it’s boilerplate for you to customize.
It’s interesting that it’s not used in the generated homepage, but I guess that’s because the homepage isn’t a part of your app. It’s just a Phoenix landing page meant to be thrown away.
1 Like
If you have any kind of auth you’re going to need controllers (even if all they do is respond to POST requests and redirect) as you cannot manipulate session data over websockets.
As for templates, so long as you always use functional components then there is effectively no difference between template for controllers and templates for LiveViews. Otherwise, the “standard” way is to put templates for controller actioins in lib/my_app_web/controllers/<my_controller>_html/ or define them as function components in lib/my_app_web/controllers/<my_controller>_html.ex and people tend to put reusable components in lib/my_app_web/components/. Again, so long as they are functional components, both classic views and LiveViews can use them.
See here for related discussion.
2 Likes
More precisely you cannot use JS to set httpOnly cookies which are preferable for security reasons (in case of XSS).
1 Like
I’m very aware of that you need a full HPPT request cycle to set a session cookie and work with auth. But given that is just an API you dont really need any template at all. You can simply issue a redirect to the controller, perform your auth logic and then redirect to another live view.
It’s interesting that it’s not used in the generated homepage, but I guess that’s because the homepage isn’t a part of your app. It’s just a Phoenix landing page meant to be thrown away.
I agree and I think this is what’s confusing to me, the boilerplate is what any new dev and myself look at when I scaffold a new project to see how the maintainers expect a typical app to be setup. If I generate a new Phoenix app with live view I sort of expected that live view would be used and that the layouts is consumed, not the older controller based way.
