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!

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.

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.