Concrete examples of when to use live_patch, live_redirect, push_redirect, push_patch?

I’m interested in this as well, I haven’t been following LiveView too closely and haven’t worked with these functions too much.

For push_patch however, I do have an example. You’re correct that it is used on the server side to update the state of the LiveView. An interesting trick I learned in this blog post was using handle_params/3 along with a server side state change to generate modals.

The blog post hasn’t been updated for the navigation changes in LiveView 0.7 but I have updated my implementation to use the new navigation functions. This example app is deployed and linked on the Github, you just have to manually navigate to the /room/<room_name>/admin route to see the modals in action…

Also, on a related topic, when should you use live_component vs making a regular live view, and are live components without state the same as template partials in a non-LV app?

So many questions! Answers related to practical examples would be great. The docs are very much written from a POV of describing the API, not applying it. It makes it kind of hard to understand while learning LV.

This is also basically a question I have. Live view applications can totally use regular partials, so when is it important to use a stateless component vs a regular partial? Is it purely an optimization / code organization thing?

Do you use render in that case and put the partial in your templates/ directory? This wasn’t ever mentioned in the docs. I didn’t even think it was possible, because we have live_render too, I thought that was supposed to replace render to some extent.

It is 100% possible, and it is 100% unchanged from ordinary views. live_render is not a replacement for render at all. live_render is used when you want to embed a new / sub liveview in a page.

This is something on the back of my mind as well, and these are my thoughts after having implemented an LiveView application for a hackathon this past weekend.

As all good answers, it depends. I’ll first explain a bit of what I did and how I structured it, and then we’ll discuss some use cases I came up with while tinkering with LiveView/Components.

Disclaimer: it’s my first experience with LiveView so I’m open to scrutiny/suggestions! Take this with a grain of salt

What I did was basically a full blown single-page-application with 5 screens. I used the LiveView layout to render a live_component that contained the live_redirect to 5 different LiveViews.

# Component that renders the live_redirects
defmodule MyAppWeb.NavComponent do
  use GaminvestWeb, :live_component

  def render(assigns) do
    ~L"""
      <%= live_redirect to: Routes.live_path(@socket, MyApp.PageOneLive) do %>
        Page 1
      <% end %>
      <%= live_redirect to: Routes.live_path(@socket, MyApp.PageTwoLive) do %>
        Page 2
      <% end %>
    """
  end
end

# lib/myapp_web/templates/layout/live.html.leex
<div class="layout">
    <%= live_component @socket, MyApp.HeaderComponent, classname: "layout__header", page_title: @page_title %>

    <div class="layout__main">
        <%= @inner_content %>
    </div>

    <%= live_component @socket, MyApp.NavComponent, classname: "layout__navbar", page_title: @page_title %>
</div>

I feel that you should reach for a LiveComponent when you want to separate a complex piece of UI from the main LiveView and you need to share data between the main LiveView and the Component. I say this because the above could have been achieved without using LiveComponent at all through render/2 as stated in LiveView docs, my most viewed and loved page of the weekend <3.

# lib/myapp_web/templates/layout/live.html.leex
<div class="layout">
    <%= render "header.html", assigns %>

    <div class="layout__main">
        <%= @inner_content %>
    </div>

    <%= render "navbar.html", assigns %>
</div>

Why did I use LiveComponent? Well, I overlooked this and LiveComponent just worked, so I moved on. But in hindsight, it made more sense to use render/2 for this particular example. However, the advantage of using LiveComponent is it’s hability to handle events and have state!

Think of LiveComponents as a kind of function that encapsulates a complex piece of UI under a parent LiveView. They can be stateless or stateful, but they are always tied to a parent LiveView. This complicates things a little bit, since you can send data up to the parent.

Most of the time, you’ll want to pass data from the LiveView down to the LiveComponent. This is how I learned in React, and imo makes your interactions easier to reason about. However, unlike React, Phoenix gives you a “event bus” through PubSub! So you could trigger changes using PubSub and read those changes up in the parent LiveView. These are all documented in the LiveComponent docs.

If you’re familiar with React, you can think of LiveComponents as being React components. LiveComponents with an :id are stateful, akin to React components that use setState or useState, and LiveComponents without an :id are akin to “dumb” React components, that is, components with no state.

Tl;dr: IMO a LiveView should have one concern to worry about. Group functionality that is closely related domain-wise under a LiveView, and use LiveComponents to handle complex piece of functionality under your LiveView. live_redirect means changing domains, i.e. is related to other LiveViews, and live_patch means changing functionality in the same LiveView, i.e. is related to LiveComponents.

Partials and stateless components are pretty much the same.

At the end of the day, regardless if you invoke link/2, live_patch/2,
and live_redirect/2 from the client, or redirect/2, push_patch/2,
and push_redirect/2 from the server, the user will end-up on the same
page. The difference between those is mostly the amount of data sent over
the wire:

• link/2 and redirect/2 do full page reloads

• live_redirect/2 and push_redirect/2 reloads the LiveView but
  keeps the current layout

• live_patch/2 and push_patch/2 updates the current LiveView and
  sends only the minimal diff

An easy rule of thumb is to stick with live_redirect/2 and push_redirect/2
and use the patch helpers only in the cases where you want to minimize the
amount of data sent when navigating within the same LiveView (for example,
if you want to change the sorting of a table while also updating the URL).

Where does mount come into play between redirect and patch?

For example, in the docs I read mount only gets executed once when loading a LV, and if you patched between content A and B in the same LV (such as your sorting example), mount wouldn’t get run a 2nd time.

But does that mean it’s not possible to live_patch between 2 different LVs since each of them have their own mount? How would that work in practice?

Is there anything worth thinking about for the “pretty” part of that. Like, performance wise or any gotchas? Also from the docs, it’s not clear where the partial’s file should live. Should it be in the same directory as the LV? Typically partials are in the templates directory.

It is remounted on redirect, not remounted on patch. That’s the main distinction between them.

So you can’t patch across different LiveViews. If the client emits a patch but it is another LiveView, it falls back to a redirect.

They have to be in the templates directory, since the partial belongs to a View (and not the LiveView). I will clarify this.