How does :if heex attribute work?

The processing is happening on the server side ..
The beauty of this is security ..

The merging of what’s in the DOM vs what is supposed to be in the DOM is handled by morphdom in the browser. The phoenix liveview javascript does all the reconsiliation of dynamic and static parts, but from there the template is passed to morphdom for applying any changes to the DOM.

Benjamin - so I understand this precisely too .. can you explain this a bit simpler .. what CPU is processing the :if ? Is it the server or the client (browser) ?
My interpretation was that the conditional processing etc. (heex template => html/css) is done on the server side ? Do I have it wrong ?

That’s not completely correct. The :if condition is indeed checked on the server, but there isn’t plain html sent to the client. There’s an optimized diff sent to client, which either includes content or doesn’t. There’s more code on the client to figure out what that diff means, and the result is applied by morphdom, which takes some html and updates the DOM to match that html.

I understand/know the morphdom and diff management .. however, one of the strengths of elixir/phoenix vs. javascript that I thought was a big plus was that conditional code isn’t pushed to the client side. So, in effect, the client browser would never ever see what is behind the

> <div :if={false}> **secret stuff** </div>

.. that isn’t sent over the websocket .. right ?

With javascript, your code is basically distributed to and running on the browser (I know I am oversimplifying .. ), free to be inspected by anyone ..

My current mental model of how conditional rendering works in LiveView:

When the :if condition is false by default, then browser won’t receive the content guarded by the :if. Then if the :if condition subsequently switches from false to true, the server sends an optimized diff representing the addition of that guarded content to the client which updates the DOM via morphdom.

When the :if condition is true by default, then browser will receive the content guarded by the :if. Then if the :if condition subsequently switches from true to false, the server sends an optimized diff representing the removal of that guarded content to the client which updates the DOM via morphdom.

Exactly.

I think this is what the OP was asking about. The diff doesn’t contain any content and also doesn’t seem to contain any instructions for deleting content, so something on the client needs to be able to understand that such a diff means “removal of what is there”.

As much as I enjoy Elixir/Phoenix, that’s a server side rendering advantage and not language/ecosystem specific.

Right, because the :if condition defaults to false, your secret stuff is safe so long as that condition never turns true. There’s a caveat though, it’s pretty common to set the :if condition to an assign and when doing so, it is important to note that if there’s an unguarded handle_event/info defined that toggles that assign, a malicious user could reveal your secret stuff.

Thanks for explaining it .. I think you nailed it for me.
I had not yet understood the scenario where the conditional was based on an assign. Makes sense ..

Kind regards.

You’re welcome! For posterity’s sake, here’s a simple naive example of what I meant by the caveat above.

defmodule MyAppWeb.SecretsLive do
  use MyAppWeb, :live_view

  def mount(_params, %{"current_user_id" => user_id} = _session, socket) do
    user = MyApp.Accounts.get_user!(user_id)
    socket =
      socket
      |> assign(socket, :admin, user.admin?}
      |> assign(socket, :show, false)  # aka hide by default
    {:ok, socket}
  end

  def render(assigns) do
    ~H"""
      <div :if={@admin}>
        <button phx-click="toggle_secrets">Toggle Secret Stuff</button>
      </div>
      <div :if={@show}> **secret stuff** </div>
    """
  end

  # even though non-admins will not have a button that triggers this event
  # a malicious non-admin user that knows about this unguarded event handler
  # could directly trigger and exploit this event handler to reveal your secret stuff
  def handle_event("toggle_secrets", _value, socket) do
    {:noreply, assign(socket, :show, !socket.assigns.show)}
  end
end

To learn more about this and the importance of authorization/permission when it comes to LiveView events, check out this guide on the Security considerations of the LiveView model.