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