Phoenix 1.6 to 1.7 upgrade with optional phoenix_view removal

My little experiment of merging index.ex and show.ex from the standard live generator ended up looking like this:

  embed_templates "*"

  @impl true
  def render(assigns) do
    assigns =
      assigns
      |> assign_new(:live_action, fn -> :unknown_live_action end)
      |> assign_new(:patch, fn ->
        patch(assigns.live_action, assigns.user)
      end)

    ~H"""
    <%= cond do %>
      <% @live_action in [:index, :new, :index_edit] -> %>
        <.index.index
          streams={@streams}
        />
      <% @live_action in [:show, :show_edit] -> %>
        <.index.show
          user={@user}
        />
      <% true -> %>
        <ProjectWeb.Util.inspect_value v={binding()} />
    <% end %>

    <.modal
      :if={@live_action in [:new, :index_edit, :show_edit]}
      id="user-modal"
      show
      on_cancel={JS.push("cancel") |> JS.patch(@patch)}
    >
      <.live_component
        module={ProjectWeb.UserLive.FormComponent}
        id={@user.id || :new}
        title={@page_title}
        user={@user}
        action={@live_action}
      />
    </.modal>
    """
  end

where index.index and index.show correspond to index.index.html.heex and index.show.html.heex files.

Maybe something like:
<%= ChartView.show(assigns) %>

From Migrating to Phoenix.Component | Phoenix.View:

Remove def view and also remove the import Phoenix.View from def html in your lib/my_app_web.ex module. When doing so, compilation may fail if you are using certain functions:

• Replace render/3 with a function component. For instance, render(OtherView, "_form.html", changeset: @changeset, user: @user) can now be called as <OtherView.form changeset={@changeset} user={@user} />. If passing all assigns, render(OtherView, "_form.html", assigns) becomes <%= OtherView._form(assigns) %>.
• If you are using Phoenix.View for APIs, you can remove Phoenix.View altogether. Instead of def render("index.html", assigns), use def users(assigns). Instead of def render("show.html", assigns), do def user(assigns). Instead render_one/render_many, call the users/1 and user/1 functions directly.

And from Compartmentalize state, markup, and events in LiveView | Phoenix.LiveView:

However, sometimes you need to compartmentalize or reuse more than markup. Perhaps you want to move part of the state or part of the events in your LiveView to a separate module. For these cases, LiveView provides Phoenix.LiveComponent, which are rendered using live_component/1:

<.live_component module={UserComponent} id={user.id} user={user} />

As a heads up, this is a known pitfall:

Due to the scope of variables, LiveView has to disable change tracking whenever variables are used in the template…
…
Similarly, do not define variables at the top of your render function:

def render(assigns) do
  sum = assigns.x + assigns.y

  ~H"""
  <%= sum %>
  """
end

Instead explicitly precompute the assign in your LiveView, outside of render:

assign(socket, sum: socket.assigns.x + socket.assigns.y)

source: Pitfalls | Assigns and HEEx templates | Phoenix LiveView v0.18.18

Thank you! Does modifying assigns fall under this category? I saw this pattern in core components

Hmm, that’s a good point – not sure if modifying assigns would fall under this. Maybe it’s fine for core components since they’re invoked within the ~H sigil… ¯\_(ツ)_/¯

If I’m understanding the intent correctly, it might still make sense for those assign_new calls to be outside render as the assigns that it ensures exists shouldn’t change across re-renders.

FWIW, Phoenix View is not deprecated and we are committed to keeping it working in the long term. I will make the docs clearer.

After a bit of fiddling with the syntax, the following seems to work (thanks @codeanpeace , your suggestion was pretty close).

  use AppWeb, :live_component

  import AppWeb.ChartView # for all the rendering helper functions
  embed_templates "../templates/chart/*"

  def render(assigns) do
    ~H"""
    <div>
    <%= show(assigns) %>
    </div>
    """
  end

The existing template has a root div element, however, without wrapping the ~H in a div, we " Stateful components must have a single static HTML tag at the root".

Still not sure how to do conditional rendering yet.

I’m relieved as I’m not sure how risky this upgrade is to be honest. Might have a lot of little gotchas and needs extensive testing.

So just to reiterate, since core_components define stateless components, and they modify assigns for themselves to render correctly (here’s an example):

image713×181 20.3 KB

This differs from my conditional rendering because it implemenets the render callback of a :live_view?

image567×373 34.4 KB

I’m just trying to formulate a rule of a thumb for such scenarios.

By the way, the suggested

    ~H"""
    <%= cond do %>
      <% @live_action in [:index, :new, :index_edit] -> %>
        <%= index_index(assigns) %>
      <% @live_action in [:show, :show_edit] -> %>
        <% index_show(assigns) %>

strangely does not include <% index_show(assigns) %> at all, just shows an empty page, although it sees embedded component functions. Anything else put within condition shows up, but not the <% index_show(assigns) %>. And all I did was rename the files to eliminate the ..

The main issue from my understanding is ensuring updates and change tracking works correctly. In this case, the table is adding row ids based on changing data. The rest of the code isn’t there, but there are two possibilities:

1. liveview replaces the entire html element
2. it may not matter what the row number is on a change and it doesn’t change the rendering.

Without testing it, I think your code should work for change tracking. The reason the second conditional doesn’t render is that it needs a <%= , not <% to display.

LOL you are right! Thanks!