LiveView Form With Nested LiveView Fields

barkerja

We are currently experiencing an issue with a form we recently created that has several nested LiveView fields. Our form is currently defined as such:

<%= f = form_for @changeset, "#", [class: "liveview-container", phx_change: :validate, phx_submit: :save] %>

The primary issue we are experiencing is our nested LiveView fields are remounted on the parent’s state change; it does not matter what changed on the socket’s assigns, it will cause a full re-render of the form.

This is particularly problematic for our nested LiveView fields because we load data on mount, which the form’s on change exacerbates. In addition to this, we are also seeing all of the static and dynamic bits being sent on every change. I assume this might be an issue with how diffs are handled with something like the changeset?

A link to the parent template (ignore .eex extension, had to use it instead of .leex for GitHub to highlight): live_view_form.html.eex · GitHub

7 comments

/phoenix #forms #liveview

0 3250 7

2019-09-05 15:04:24 UTC

Showing Posts 1 to 7

Show Best Posts
Show All (oldest first)
Show All (newest first)

alexgaribay

Phoenix Core Team

This is by design for nested LiveViews. Since the session being passed is technically changing, you get a new LiveView process on each change.

Is there a way you can do this without a nested LiveView? I’d recommend adding any event handlers in the parent and having a function that renders each field.

Post #1

barkerja

It is possible to bring the nested LV fields into the main parent LV. These fields are dropdowns that support search with varying datasources, so it made sense to try and isolate those concerns and allow them to manage their own state.

Post #2

AndyL

I ran into problems with nested fields that were difficult to debug. After reducing levels of nesting to two levels everything worked a-ok. Sorry I can’t offer actual guidance - just a data point from a fellow newbie.

Post #3

barkerja

@alexgaribay Is this assumption correct? I initially thought it was due to the comprehensions, but I removed those and still saw the same behavior. I assumed due to the fact the changes were contained within the changeset, there was no dirty tracking happening and that’s why we see a full form re-render on any change.

Side note, I enjoyed your ElxirConf talk! Thank you for putting that together.

Post #4

barkerja

What sort of issues did you experience?

Post #5

AndyL

I have a clock component that updates every second. When I embed it three levels deep, it fails intermittently, like once every ten page refreshes. Couldn’t figure out why. Then I wrote the clock logic into the second-level component, and it runs perfectly. Also experienced problems when I had live-views embedded in the page layout (header and footer), with a live view rendering in the body. The initial render would go fine, but when I used push-state and the back button, the body live-view was rendered in the header. Probably newbie error, and maybe subtle bugs in the new tech. Even with these teething problems I’ve written probably the best live-UI of my life. More to come. I hope that eventually we can create libraries of live-components that can be deeply nested.

Post #6

alexgaribay

Phoenix Core Team

With the way it was structured, any change to the underlying changeset will cause a new nested LiveView to spawn for your fields. Every time that happens, the full rendered struct with the statics and dynamics will be sent to the client.

I’m glad you enjoyed it!