LiveView DOM patching in webcomponents with slotted content

carlosescri

Hi all!

I’ve been working on some RAW (no framework) web components for one of our projects to see how well they behave with Phoenix LiveView.

At the time I have:

Custom tooltips (no problem)
Phone Input with country dropdown picker (no problem), Form Associated Custom Element (FACE), so it works with forms as any other input.
Custom Select (with search and a slot to put custom HTML nodes). FACE too.

I had some problems with the slotted elements in the custom select because they were not patched by morphdom.

With a bit of help from Claude y proposed a fix in the live view repo.

You can get more details here:

github.com/phoenixframework/phoenix_live_view

fix: patch children of focused Form-Associated Custom Elements (FACEs) (#4323)

main ← carlosescri:carlos/fix-face-webcomponents-children-patching

opened 09:10PM - 08 Jul 26 UTC

carlosescri

+259 -0

I hope this helps someone. ## Problem When a Form-Associated Custom Elemen…t (FACE) has focus, `onBeforeElUpdated` in `dom_patch.ts` identifies it as a focused form input via `DOM.isEditableInput()` and returns `false`. This tells morphdom to skip the element **and all its children**. For native inputs (`<input>`, `<select>`, `<textarea>`) this is correct, their value lives in the DOM and we don't want morphdom to overwrite what the user is typing. But FACEs are fundamentally different: they store their value in `ElementInternals` via `setFormValue()`, not in DOM attributes or children. Their light-DOM children are structural (e.g. slotted elements, in my case is a custom select web component with slotted elements) and must be patched normally. ### How to reproduce 1. Create a FACE with `static formAssociated = true` that has light-DOM children managed by LiveView (e.g. a slotted button with a `phx-click` attribute whose payload changes on each render). 2. Give the FACE focus (click on it). 3. Trigger a server re-render that updates the children (e.g. via `phx-change`). 4. The server sends the correct diff (visible in WebSocket inspector), but the children in the DOM are never updated. ### Root cause ``` document.activeElement === <my-face-element> (always true for shadow DOM hosts) DOM.isEditableInput(<my-face-element>) → true (formAssociated = true) isFocusedFormEl → true return false → morphdom skips children ``` ## Solution A new helper `DOM.isFormAssociatedCustomElement()` detects FACEs. When a focused FACE is encountered, the patch returns the element instead of `false`, which tells morphdom to update attributes and descend into `morphChildren` as usual. Native inputs retain their existing behavior. ## Notes - `delegatesFocus: true` on the shadow root does not help — `document.activeElement` is always the host element regardless of this setting. - LiveView already has explicit FACE support (`isFormAssociated()`, `isEditableInput()`), and FACEs participate correctly in form serialization via `FormData`. This fix completes that support by ensuring their children are also patched. - All existing JS tests pass (252/252).

If any of you is interested on this topic because you suffered from this problem too, would be great if you can give a try so @steffend can get some feedback because this is actually a bit tricky.

I encourage you to take a look at the PR. It’s up to date to 1.2.6 version of LV and it has some tests. More details in the PR.

Thank you for your time.

4 comments

/phoenix #liveview #webcomponents #morphdom

3 682 4

2026-07-24 16:19:25 UTC

Showing Posts 1 to 4

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

krasenyp

I had a perfectly running web component with slotted elements, at 1.1.9. After I updated to the newest LiveView, at the time it was 1.2.2, everything stopped working. I had to rewrite my components as stateless components… I hope your fix gets approved and we can write our web components without worry.

Post #1

carlosescri

Thanks for your response… if you have means and time, would be great if you could try your web components (or some of them) with the JS in the PR to check if they work again… Thank you in any case.

Post #2