<.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

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.