Preserving UI state in Live Layout

Phoenix Forum Questions / Help
, , ,
1

Hello,

I’m a total Elixir and Phoenix beginner, coming from js and react world.

I was wondering if anyone could help me solve an issue I can’t get my head around.

I’m building an admin dashboard type of project and I have the same layout (navbar and sidebar) for lots of live pages. The admin dashboard will have “Toast notifications”. So what I did is, I’ve wrote some js code to generate the toast, added it to the js hooks, and I’m triggering the toast with a “push_event” (“toast”) on a click of a button.
The toasts then appear in the root container div, that I’ve put in the “admin” layout.

The toast root lives here in the “admin_layout”:

<main class="mx-auto px-2 pt-11 lg:px-6 2xl:ml-56 overflow-auto max-h-screen">
  <.flash_group flash={@flash} />
   <%= @inner_content %>
<div id="notifications-root" phx-hook="Notifications"></div>
</main>

What I did is put all of those pages in a live_session with the same “admin_layout”;

  scope "/", Web do
    pipe_through([:browser, :require_authenticated_user])
    live_session :require_authenticated_user,
      layout: {Web.Layouts, :admin_layout},
      on_mount: [{Web.UserAuth, :ensure_authenticated}] do
      live("/users/settings", UserSettingsLive, :edit)
      live("/users/settings/confirm_email/:token", UserSettingsLive, :confirm_email)
      live("/office", OfficeLive)
    end
  end

So when I press the button and a toast appears, everything works correctly. However when I live navigate to a different admin view, for example from “summary” to “users”, the toasts dissapear and the console shows an error:

phx-F4H9jaHF_fjKQwji destroyed: the child has been removed from the parent - undefined

I don’t understand why that happens, as the root div continues living in the layout when I change the page (the layout is unchanged), but the toasts living in the root div get removed.

Is there a way to make this work correctly? Thank you for your time

2

Hello and welcome to the forums!

LiveView doesn’t track changes, or even know about, the root layout. Moving your toast code to app.html.heex layout will fix this.

This section of the docs, particularly the last paragraph, will give more insight as to why!

3

Hello, thank you very much for your reply.

However, I should say that the layout I posted (admin_layout) is not the root_layout.

The problem exists in the admin_layout (might as well be the app.html.heex). When I put the toast root div in the root_layout, everything works fine (because then this toast root div is not touched by the live navigation and sockets mounting / unmounting). So if the toast root div is in the root_layout, the toast remain on screen after live navigating, which is the behavior I want.

However I would like to have this same behaviour when putting the toast root div inside the admin_layout (which is the equivalent of the app.html.heex you’ve mentioned). The problem is that if I do it like that, all the children of the toast root div (the toasts) get removed, as if the whole layout has re-rendered.

I also tested your recommendation, and I’ve put the div inside the app.html.heex layout, however the problem persists.

4

Oh, yikes, my bad! I read “root” and assumed you meant meant it was a root layout though from your code it’s obvious :grimacing: You’ve also thrown how I think about the root layout for a loop, lol. Sorry about that!

Have you modified flash or flash_group components at all? If so could you share them? Otherwise I’ll have to let someone else chime in as I don’t see anything wrong with your code. I took a look at a few of my projects and they all look like yours with custom admin layouts and all.

5

You could use a nested liveview, in charge of all notifications.

BTW, there is root, app layouts, and also live layout

6

Dont worry about the mixup :slight_smile:

No, I didnt touch the flash_group or flash components at all.

I will try more hacky solutions for now. Thank you for your time.

1 Like
7

Thank you for your reply. From a short google search, nested liveviews seem to be exactly the solution. However, I was unable to find any docs of how to implement them. Can you point me to where i could find some instructions?

Also, can you maybe make a short explanation of what is the difference between root, app and live layout? I know its a hassle so if you can only address the question about nested liveviews that would be great as well

8

Root is shared between both normal and live views. It is also the start of the layout.
App is for normal views
Live is for live views

I use something like this in the live layout. I had to activate it, because it’s not there by default I think.

<main>
    <.flash_group flash={@flash} />

    <%= live_render @socket, ArenaWeb.NestedLive.Notification,  id: "nested-notifications" %>

    <%= @inner_content %>
</main>

I use this because I want to delegate notifications to the nested liveview.

Also…
root and app use @conn, while live use @socket

9

Take a look in your lib/my_app_web.ex, specifically at the :controller and live_view helpers. If you wanted your live views to use live.html.heex for live views, then you would chang

use Phoenix.LiveView, layout: {MyAppWeb.Layouts, :app}

to

use Phoenix.LiveView, layout: {MyAppWeb.Layouts, :live}

and create live.html.heex in lib/my_app_web/components/layouts/.

The root layout is specified in the router (look for put_root_layout).

Really the docs I link do a good job of explaining the difference between root and app layouts (live is considered an “app” layout), especially the last paragraph:

At this point, you may be wondering, why does Phoenix have two layouts?

First of all, it gives us flexibility. In practice, we will hardly have multiple root layouts, as they often contain only HTML headers. This allows us to focus on different application layouts with only the parts that changes between them. Second of all, Phoenix ships with a feature called LiveView, which allows us to build rich and real-time user experiences with server-rendered HTML. LiveView is capable of dynamically changing the contents of the page, but it only ever changes the app layout, never the root layout. We will learn about LiveView in future guides.

10

Thank you for the reply. I should say that I found out that what im trying to do is not possible (at least I think) with the built in live layouts.

As far as I was able to deduce, the layout always uses the same process of the current liveview. The problem arrives when live navigating from one liveview to the other, as this starts a new liveview process. Because the built in layout is always the part of the current process, it loses the state when navigating between liveviews.

So as far as I can tell the only saving grace is to have the layout (navbar and sidebar) be a child liveview process with the sticky option set to true, so it lives in a world of it’s own.

This is a very strange design (?) I might say. I would have thought, that giving that liveview is kind of aimed at providing a SPA experience, this basic feature would have been worked out better.

11

It is indeed funny how the scope creeps. Originally the goal was explicitly not to take on SPAs, the goal was just to enable some dynamic content on a page without resorting to JS.

Definitely over time that line has gotten blurrier.

2 Likes
12

Yep, one process == LiveView. There are no other user-dedicated processes started by the framework, it’s up to you to start more, which I think is a fair design. I also appreciate being able to implicitly throw away state by switching to another LiveView. If you want to be more SPA-like you can make use of many LiveComponents inside a single LiveView. I’ve never gone too far down that route myself so I’m not sure how hairy it would get.