I’ve written up my solution here: An example of nested forms, nested changesets, and error handling Possibly the most useful bit is I have a set of integration-style tests that can be used as a checklist for cases to cover.

@marick - I built a slim example app using some of the language of your app. There is a single commit that shows the diff between mix phx.new and my additions at… Add LiveView and example · baldwindavid/crit@4d1688a · GitHub

I skipped a lot of stuff, but this might give you a basic idea of the mechanics of using LiveView for this kind of thing.

You should be able to create an animal via a regular controller create and then be dropped into a LiveView for editing. On that page you can update the animal name and create, update, and delete service gaps. All of these are updates to single resources via separate events and without a page update.

The liveview is mounted within the edit template, but it could also have been mounted from the controller or router.

The animal and service gap forms all validate upon interacting with inputs and save upon clicking a button. There are a lot of ways this can be done and rate limiting can easily be added. It would also be trivial to change the forms to save upon editing and removing the submit buttons.

Most of the action takes place in CritWeb.Animal.EditLive and hopefully you’ll see that a good bit of it is boring, yet simple, repetitive code. For simplicity, the service gaps are queried upon just about any event to keep them up to date. Rate limiting or only updating upon submission would cut down on queries. The only slightly complex thing is replacing a changeset from the list of service gap changesets in some cases. Maybe this is a hacky way to do it, but seems to work… crit/lib/crit_web/live/animal/edit_live.ex at 4d1688aa7edaae180621a6ed01394224c874b28b · baldwindavid/crit · GitHub

If you have multiple people editing at the same time, you might want to introduce some pubsub that live updates via actions that others make, but that was a step further than I went here.

I’m no expert in LiveView, but it is already providing me with the blocks to build some interfaces that I probably would have not done before because of the amount of JS involved. I am also one of those people that tries to avoid frontend work. I didn’t write any JS here. The only JS you’ll see in the diff is straight out of the installation docs… https://hexdocs.pm/phoenix_live_view/installation.html

Does that help? Let me know if you have any issues getting it running.

It doesn’t feel like what you are doing is wrong but it also feels what you are doing is all UI concerns - which would explain (at least to me) why Ecto doesn’t take care of it. But Ecto does provide the groundwork for handling those scenarios.

For example, for handling an empty form, you can check if all params are empty and retturn :ignore by the cast_assoc changeset function.

Your function also works great but I would keep it as part of the UI functionality - if you don’t already do it. If memory serves me right, the functions in Phoenix.HTML for working with nested associations does support a prepend option, exactly for use case like yours, but I am unsure if it does exactly what you did.