I’m new to Phoenix (and Elixir in general); I’m coming to Phoenix from a Javascript background (I’m the author of ReactQL, to give you an idea on the typical stack I’m used to.), so forgive me if the naïve/novice query.
One thing that stumped me immediately in Phoenix was the implicit templates/layout/app.html.eex. I’m developing a pretty typical app which is chunked into several sections - a public front-end, the user app itself, an admin area, an API. Having a default central layout doesn’t serve the requirements of this app, so I spent the first little while trying to figure out how to disable it.
What I wound up with was just a plug in the :browser pipeline, pointing to a private function that disables the default layout. I then deleted templates and layout_view.ex. Finally, in my controllers, I created a second plug for specifying routes connections to that particular controller.
Whilst this was fairly trivial to do (and I’m not even sure that’s the only - or right - way to go about it), the notion of first disabling the layout and then setting a new one seems a bit like a code smell to my novice Phoenix nose. In other frameworks I’ve worked with, layouts don’t tend to be assumed until explicitly set; I’ve found they’re often not required.
So for my introductory question to this board (and thanks in advance for helping to further my currently very basic understanding of Phoenix!), I’m curious what prompted the design decision to make layout/app.html.eex (and LayoutView) an implicit choice? My first instinct was to search Phoenix generated code to look for a specific reference to “app.html”, assuming that I’d just need to comment out the default line to prevent it… but it looks like LayoutView is hard-coded in lib code.
Again, I’m new here so I may be missing something obvious, but this did strike me as a tad opinionated and I’m curious what may have led to it.
I would say that in general Phoenix is an opinionated framework that makes a lot of opinionated decisions in order to provide a particular experience that fits the majority of web apps.
Whether this is the best way if a matter of personal preference. I think myself I would prefer it to be explicit and in the generated code, as you’ve suggested.
…I think myself I would prefer it to be explicit and in the generated code, as you’ve suggested.
Agreed. I found it slightly out of step with other generated code.
For example, this being the default :browser pipeline:
pipeline :browser do
plug :accepts, ["html"]
plug :fetch_session
plug :fetch_flash
plug :protect_from_forgery
plug :put_secure_browser_headers
end
… makes it really simple for a newbie like me to see, at a glance, exactly what’s provided out-the-box.
If I want to disable or add anything new, it’s clear where to make the change.
Whereas layouts being handled by default outside of generated code, obfuscates behind a bit of background magic that wasn’t immediately clear how to override.
I wound up figuring out it was just a simple :put_layout, false (thanks @hlx for simplifying my superfluous private func), but that feels a bit like monkey-patching the core.
From my very limited/early impression, I would have preferred to see an explicit :put_response, {LayoutView, "app.html"} in generated code, so I could instead comment it out rather than override.
A small detail, but just some feedback on something that stumped me on first glance.
I feel I need to mention this in case you haven’t thought of it, in your controller you can also simply call put_layout/1 instead of using a separate plug for it:
# contollers/page_controller.ex
def MyAppWeb.PageController do
use MyAppWeb, :controller
plug :put_layout, {MyAppWeb.PageLayoutView, :page}
def index()
end
I feel I need to mention this in case you haven’t thought of it, in your controller you can also simply call put_layout/1 instead of using a separate plug for it:
Thanks @hlx, I thought of that after seeing your original example disabling it – appreciated!