How to merge AlpineJS x-for with HEEX templating.

Welcome @AGURRU! I think it would be helpful to know why you want to use Alpine.js to render a list of elements rather than just using the Elixir/EEX code you already have? The code you have is great and gets the job done. What you’re asking for is possible though. If @investments is a list of maps, you will have to encode the whole list to JSON first

<ul x-data={"{ investments: #{Jason.encode!(@investments)} }"}>
  <template x-for="investment in investments">
    <li x-text="investment.investment_name"></li>
  </template>
</ul>

But if @investments is a list of Ecto schema structs, which is very likely if the data is coming from your database, then that will not work because you cannot encode structs to JSON. You can convert them to maps first but you’d still have a problem because you cannot encode the :__meta__ field or any associations either, so you’d have to drop those keys from the map, e.g.

<ul x-data={"{ investments: #{Jason.encode!(Enum.map(@investments, &(Map.from_struct(&1) |> Map.drop([:__meta__, :account]))))} }"}>
  <template x-for="investment in investments">
    <li x-text="investment.investment_name"></li>
  </template>
</ul>

This could be refactored into a helper function but even then it’s quite complicated and verbose. If you only need the investment_name you could just map over that field and simplify it a little, but then you lose flexibility to access the rest of the record if you need to

<ul x-data={"{ investment_names: #{Jason.encode!(Enum.map(@investments, &(&1.investment_name)))} }"}>
  <template x-for="investment_name in investment_names">
    <li x-text="investment_name"></li>
  </template>
</ul>

Overall, this is all going against the grain of the framework, and doing simple rendering work in the client that is much more easily done on the server in a clearer and more idiomatic way. I would suggest only using Alpine.js for interactive elements that server-rendering can’t perform, like drop-downs, hide/show elements, animation etc.

Just to clarify where the merger between HEEX and Alpine comes in, the outer curly braces in x-data={ ... } are required in order to interpolate the Elixir code into your HTML.

Thank you so much for your really in-depth answer. You are right it’s an ecto struct and your ways of doing this maybe could work but I think it’s over-complicating it. Your answer is helping me understand what is going on better which is invaluable. I’ve changed tack a little since my initial post and I think I can achieve what I want using just HEEX functions and CSS.

I’m not a frontend dev and I’m completely new to HTML/CSS/JS in terms of actually coding but needs must whilst we are hiring a new front end team member.

I am trying to have three (dynamic from a list) cards that act as radio inputs for a form. The tailwind playground I have copied below is a simplified version of what I am trying to achieve.

In terms of what this looks like using HEEX.

<li>
  <%= radio_button(:payment, :investment_id, 1 , class: "sr-only peer") %>

<%= label(:payment, :investment_id_1, "Investment 1" , class: "flex p-5 bg-white border border-gray-300 rounded-lg cursor-pointer focus:outline-none hover:bg-gray-50 peer-checked:ring-green-500 peer-checked:ring-2 peer-checked:border-transparent") %>
    <div class="hidden w-5 h-5 peer-checked:block top-5 right-3">
      1
    </div>
</li>

<li>
  <%= radio_button(:payment, :investment_id, 2 , class: "sr-only peer") %>

<%= label(:payment, :investment_id_2, "Investment 2" , class: "flex p-5 bg-white border border-gray-300 rounded-lg cursor-pointer focus:outline-none hover:bg-gray-50 peer-checked:ring-green-500 peer-checked:ring-2 peer-checked:border-transparent") %>
    <div class="hidden w-5 h-5 peer-checked:block top-5 right-3">
      2
    </div>
</li>

As you can see, I had to hardcode the radio input value, Label name and also the label field (this is to make sure the label-for value matches the radio input.)

I feel like I am part of the way there but in my head - I should be able to combine this with

<%= for investment <- @investments do %>
<% end %>

and not hardcode so many parts of the form, especially the value and label.

I haven’t even begun to think about how I can add content to each card beyond just the label but that’s another bridge I need to cross.

What does the investments data look like?

I’m glad it was helpful @AGURRU .

Yes I think the HEEX and CSS route is simpler and more maintainable. To simply translate the template code you have posted to a dynamic iteration of @investments it would look something like this:

<.form let={f} for={:payment} action="/payments/new" >
  <%= for investment <- @investments do %>
    <li>
      <%= radio_button(f, :investment_id, investment.id, class: "sr-only peer") %>

      <%= label(f, :"investment_id_#{investment.id}", "Investment #{investment.id}", class: "flex p-5 bg-white border border-gray-300 rounded-lg cursor-pointer focus:outline-none hover:bg-gray-50 peer-checked:ring-green-500 peer-checked:ring-2 peer-checked:border-transparent") %>
      <div class="hidden w-5 h-5 peer-checked:block top-5 right-3">
        <%= investment.id %>
      </div>
    </li>
  <% end %>

  <%= submit("Submit") %>
</.form>

A couple notes and assumptions about the line: <.form let={f} for={:payment} action="/payments/new" >

• I made an assumption about your route "/payments/new", you would likely replace this with the appropriate route helper e.g. Routes.payment_path(@conn, :new) or whatever is correct for your app
• instead of coding :payment into the form fields e.g. radio_button(:payment, ...), you assign it to the form struct with <.form let={f} for={:payment} ... > and pass it around the form with the f variable e.g. radio_button(f, ...).
• In most cases you will have a Payment changeset that you are working on, which would be assigned to a @changeset or maybe @payment assign, in which case you should actually be doing this <.form let={f} for={@changeset} ... >

This certainly has done the trick.

I kept my original <%= form for => code as it was working fine - I had tried having the @changeset before but because of the way I have set up my pages it’s not in the assigns for this particular page same goes for @payment.

I still feel like I am a little blind to the inner workings of what is going on at times - I had tried something nearly identical to this but was using an @ symbol in front of the variables I wanted to use. How do you know where to use interpolation vs @ vs an atom?

<.form ...></.form> is a newer function component that plays nicer with LiveView as I understand it, so I usually default to that since I also default to LiveView No need to change what you have for a regular view.

To hopefully clear up some of your confusion:

• Use @ for assigns that you pass into the template on the Plug.Conn, e.g. @investments
• The caveat is assigns itself, which is available in the template without @
• Don’t use @ for regular variables that you declare inside the template, e.g. f in form_for and investment in for investment <- @invesments do
• You always need to interpolate Elixir code into your template. With HEEX there are now two ways to do this for different scenarios. The original EEX way <%= ... %> must be used to generate raw output e.g. <p class="foo"><%= :foo %></p>. For tag attributes use curly braces e.g. <p class={:foo}>foo</p>. This works with both HTML tags and Phoenix function components. You can also do something like <p {assigns}> if you just want to pass an entire map or keyword list to the element/component as attributes.
• An atom is just a value, not a variable, so when you are doing <%= form_for :payment ... %> you are just declaring that this is the "payment" form for the "payment" params, sending to your controller as %{"payment" => payment_params} = params. If you have a Payment changeset in your assigns then this name will be inferred for you when you write <%= form_for @changeset ... %> and you will still end up with %{"payment" => payment_params} = params with the added benefit of validations and error reporting