Setting dynamic layouts in LiveViews that correspond with the hostname

I’m assuming you have a fixed number of subdomains since you probably aren’t going to have an infinite number of layouts

There are a few ways to do this. My current project is an online store which has a “retail” layout (for the main domain) and an “admin” layout (for the backoffice admin. subdomain).

I’m currently doing it like this:

In MyAppWeb, ie, in lib/my_app_web.ex I have:

  def admin_live do
    quote do
      use Phoenix.LiveView,
        layout: {MyAppWeb.Layouts, :admin}

      unquote(html_helpers())
    end
  end

  def retail_live do
    quote do
      use Phoenix.LiveView,
        layout: {MyAppWeb.Layouts, :retail}

      unquote(html_helpers())
    end
  end

In lib/my_app_web/components/layouts/ I add an admin.html.heex and retail.html.heex. The :admin in {MyAppWeb.Layouts, :admin}, for example, corresponds to admin.html.heex.

Then in my LiveView, instead of use MyAppWeb, :live_view I do use MyAppWeb, :retail_live and use MyAppWeb, :admin_live.

They do both share the same root layout which is very generic.

I’m happy with my solution but I’d also be interested in hearing how others do this!

Sorry, I think I may have misunderstood what you’re asking. Do you have multiple domains pointing the same LiveView and want the layout to change based on that? In that case I’m not sure it’s possible as I believe the only place to set it is when calling use LiveView, layout: {Mod, :file}. I could be wrong but can’t find anything in the docs and there is this post from José. It’s 2 years old so maybe something’s changed?

There may be a way. What does your router look like?

I’m assuming you have a fixed number of subdomains since you probably aren’t going to have an infinite number of layouts

I have a theoretically infinite set of domain names, not just subdomains, to support, but they map to a small, fixed set of themes.

The docs state the layout can be set from the router in the live_session, and from the mount(). I detailed why the mount() approach hasn’t panned out in the OP, and I’m not sure how to get the host information I need into the router to do it from the live_session.

My router right now mostly has the admin routes defined which are exempt from this whole thing. I’ve been working on them while searching for a way to accomplish this. Nothing but a test liveview defined for the public area, and the helpers that I’ve confirmed grab the host and the configuration from my database.

scope "/", MyAppWeb do
    pipe_through [:browser, :do_config]

    # login not required
    ash_authentication_live_session :authenticated_optional,
      on_mount: [
        {MyAppWeb.LiveUserAuth, :live_user_optional},
        {MyAppWeb.AssignUrl, :save_request_uri},
        {MyAppWeb.AssignConfiguration, :assign_configuration}
      ] do

      live "/", PublicLive.Index, :index
    end
    ...
    # other routes
    ...
end

I was using plugs when I had this idea working a while ago in deadviews. The same strategy hasn’t worked in 1.7+ and with LiveViews.

I’m sure there’s some way!

So apart from :temporary_assigns, it looks like mount/3 also accepts a :layout option! So I think you could figure out the layout in your on_mount then grab it from the socket in mount/3 and return it like: {:ok, socket, layout: socket.assigns.layout}. I haven’t actually tried this or anything but that is my best guess. The only thing is that you’ll have to repeat that for every LiveView which probably isn’t the biggest deal.

That’s what I’m currently attempting to do, but it looks like mount/3 happens before handle_params which is where my helper is grabbing the url

defmodule MyAppWeb.AssignUrl do

  def on_mount(:save_request_uri, _params, _session, socket),
    do:
      {:cont,
       Phoenix.LiveView.attach_hook(
         socket,
         :save_request_path,
         :handle_params,
         &save_request_path/3
       )}

  defp save_request_path(_params, url, socket) do
    socket =
      socket
      |> Phoenix.Component.assign(:current_uri, URI.parse(url) |> Map.get(:path))
      |> Phoenix.Component.assign(:current_host, URI.parse(url) |> Map.get(:host))

    {:cont, socket}
  end

So the information I need (the current host) isn’t yet accessible during mount. Unless there’s another way to access it than the current strategy I found here (in a discussion about styling the active nav link)

Can you not set up a plug that puts the host in the session?

Wellllllll ****. Could you add it to the session from a plug so it’s available in mount? Maybe not ideal. I don’t think I can be much help here as I’ve never actually done this myself. I’m interested, though, so hopefully someone else can help!

(and yes, I also read that same thread and how I set the current URL too )

EDIT: Ha, re: post that beat me to the punch

This actually works! Thank you both! Let me clean it up a bit and make sure I understand it and then I’ll post the full working thing. Are there any downsides or ramifications I should be aware of with regards to storing this in the session? Is this session data modifiable by the user? Going through the docs now

My proof of concept right now is using String.to_atom which i understand comes with some concerns, but layout: demands an atom in Phoenix 1.7+

Session is definitely modifiable by user so if that’s a concern that prob won’t work. It’s further less desirable with String.to_atom as it opens you up to an attack.

The other option here is to use components instead of the layout files. You could load the layout name in handle_params then have a component that delegates to the proper layout component.

attr :name
slot :inner_block
def layout(assigns) do
  ~H"""
  <%= case @name do %>
    <% "admin" -> %><.admin_layout><%= render_slot(@inner_block) %></.admin_layout>
    <% "some_other" -> %><.some_other_layout><%= render_slot(@inner_block) %></.some_other_layout>
    <% ... %>
  <% end %>
  """
end

then in your LiveView:

def render(assigns) do
  ~H"""
  <.layout name={@layout_name_set_in_handle_params}>
    <h1>Hi!</h1>
  </.layout>
  """
end

I would probably pattern match in function heads over that case statement, but you get the gist.

If you were using Surface you could use dynamic components though I’ve never used those so can’t give an example.

EDIT: Just for completeness I meant this as an alternative to the case:

def layout(%{name: "admin"} = assigns) do
  ~H"""
  <.admin_layout>
    <%= render_slot(@inner_block) %>
  </.admin_layout>
  """
end

def layout(%{name: "some_other"} = assigns) do
  ~H"""
  <.some_other_layout>
    <%= render_slot(@inner_block) %>
  </.some_other_layout>
  """
end

And to be clear I meant like they could potentially manipulate the session based on the hostname. If you are whitelisting hostnames then it’s no problem.