It might be referring to the morphdom patching. In livebook, they set attributes and ask morphdom to leave 'em alone.

https://github.com/livebook-dev/livebook/blob/main/assets/js/dom.js

This is a bit of a crazy ramble so if it doesn’t make sense, that’s my fault…

Watched that talk, very interesting. He reaches a conclusion similar to my premise, there shouldn’t be connections to the server for merely UI changes, the difference is that he still finds liveview convenient for coordinating client-side state between separate components, I don’t share that. So far I am happy using pub/sub between separate components to keep state, I just need to get it to play nice with LV…

Here is an interesting bit I found about morphdom in the readme:

Because morphdom is using the real DOM, the DOM that the web browser is maintaining will always be the source of truth. Even if you have code that manually manipulates the DOM things will still work as expected.

which is exactly what I want, but counter-intuitively LiveView gets rid of this benefit.

The ShadowDom seems really interesting to accomplish this, I need to read more about that though.

One of the reasons I don’t like phx-update=ignore is that you are unable to use phx-update in the child nodes, although I suppose the child-nodes could use the push function to communicate with the server… but how would they receive information? they couldn’t receive diffs from the server, but these nodes might desire to send new input data events to validate, then the issue becomes receiving the server response.

Sidenote: I am overcomplicating myself if Shadow Dom has the same effects… I guess shadow dom would be more capable if it is capable of nesting normal-dom inside shadow-dom, which would be a little crazy and cool. (TODO: research this).

Event listening for server pushed events feels a bit messy because you have to keep track of the event-name and it has to be listened-to “globally” on the client-side, I wonder if I can listen to the server event that happens with a “socket assign” update in a given element (e.g. result from handle_event("validate"...), that would be what I need but I haven’t seen information about it, I think the usual render result from a live_view only sends the computed diff, no option to attach additional payload to that message.

I have not given server-pushed events a good test-run so I might come back to them later. However, making special events for every client-side component sounds a bit exhausting when ideally one would use the same “validate” event for the entire form.

So I guess, ideally there would be “assigns” that are sent to the client as plain JSON and then the client is in charge of “diffing” it (showing an error or a validation), and ideally the client JS would also be able to eavesdrop on these messages to get the values for its own operations, as opposed to the default client-side logic that simply “diffs”. So I wonder if I can receive the changeset struct from a phx-change="validate" in the client side, on top of the usual diff. I might have to explore handleEvent client hook on a beforeUpdate maybe.

I was also wondering how LiveView JS commands could achieve “DOM-patch aware” DOM manipulations, so I just tried to read the source code of liveview js lib a few days ago. And here is my understanding:

When LiveView executes a JS command on the client-side, for example, a JS.set_attribute operation, it not only sets the attribute of that specific element, but also puts some private information into the element properties. It is shown in the code snippet below in the DOM.putSticky function:

https://github.com/phoenixframework/phoenix_live_view/blob/v0.18.3/assets/js/phoenix_live_view/js.js#L206-L218

And you can also inspect these private properties in Chrome DevTools.

image982×476 66.5 KB

All these executed JS commands will be stored in this phxPrivate.sticky property, so that when DOM-patching happens, these DOM changes made by JS commands will remain intact.

So if you want to achieve something similar to JS commands, here is a kind of tricky approach: just executing LiveView JS commands from JavaScript. Here’s how you can do it:

In your heex template, store JS commands in a data attribute:

<div id="my-element" data-js={JS.set_attribute({"aria-expanded", "true"})}>
</div>

And on the JavaScript side:

let liveSocket = new LiveSocket()

const el = document.getElementById("my-element")
liveSocket.execJS(el, el.dataset.js)

I think this approach is also used in GitHub - fly-apps/live_beats · GitHub

https://github.com/fly-apps/live_beats/blob/master/assets/js/app.js#L10-L12