When it’s ready I gave our rundown of what we want to tackle for 1.0 in the talk, so follow the issues tracker to stay up to date. Now would be a great time to jump in!

This was my favorite Phoenix talk in a long time. During the last 1/3 of the talk, it felt almost like Chris had seen my code and built one solution after another for each headache I’ve encountered with LiveView the past several weeks!

Is there a link anywhere to the form demo repo?

I just spent a bunch of time going back and forward watching the video trying to implement the nested forms thing, and I got stuck trying to solve some issues. This post is about my findings.

Check out the video, it’s just ~15 sec. There are two bugs:

1. After the first click “Add status” (add row), the checkbox stays selected, so when we “Add a role” (column), both a row and a column are added since both were checked. This is actually quite natural behavior, why would phoenix send updates on a static element? Actually I’m quite baffled it even worked in the demo at all.

The “Add Status” btn is similar to lines 45-48

Screenshot 2023-05-06 at 14.01.262290×1558 215 KB

2. When I deleted row indexed 1, phoenix re indexed all the rows down, giving me a new indexed 1 checkbox and for some reason proceded to check this new index 1 checkbox (the button is similar to lines 36-39 in the picture). Then when I click to delete row 0, both row 0 & 1 are deleted. I’m not sure if this is a browser thing (tested on firefox & safari), a phoenix js thing or a morph dom thing.

What I do know now, is that all this bugs are solved IF… drum rolls please

IDs. Maybe some other attribute will work to, but ids are fine. We need something that triggers an update when we need a fresh new element, that includes a marker that helps whoever is confusing these elements.

For the elements outside inputs_for (add rows & cols), I’m using this:

n_rows = Phoenix.HTML.Form.inputs_for(form, :field_name) |> length()
...

~H""" 
<input [..] id={"add-row-#{@n_rows}"} />
"""

For the inside ones, it’s simpler. LiveView’s inputs_for (different from the Phoenix.HTML.Form one), adds a very self explanatory field _persistent_id to every nested form, which can be accessed like this:

<.inputs_for :let={f_status} field={@statuses_field}>
   <input type="checkbox" [...] id={"row-delete-#{f_status.id}"} />
</.inputs_for>

So, how is your weekend going?

He says in the talk that he will

yes an no. What you get currently optimistic UI wise is js commands and phx-disable-with, which allow you to provide immediate feedback when the user creates and deletes todos, but in a limited capacity. For example, check out the TodoTrek demo where I delete a todo, and it fades out immediately for 200-300ms, which would mask day to day latency. phx-disable-width also allows you to swap the content of a button to show loading states. You can also use JS.show|hide|toggle do to react-style loading placeholders. So you can do a reasonable amount of instant feedback on the client today, but it will be limited. For example, what you can’t do is dynamically render some server template on the client to for example make the todo look as if it’s inserted when it hasn’t yet made the round trip.