data-phx-ref support

[bcardarella]

From @chrismccord:

we annotate the DOM nodes with data-phx-ref while we await an ack from the server
this prevents any inflight updates from touching those parts of the UI until that latest ack is received

@simlay we may need to jump on a call with Chris at some point to break this down a bit more but I'll dig into the source and see if I can familiarize myself with this behavior

[bcardarella]

Summary from chat with @simlay and @chrismccord this morning:

What Phoenix LiveView does

When any phx-* event is triggered the client will apply a data-phx-ref attribute to that target element. One of the phx event classes will be appended to the target element's class list.

No diffs will be applied to the target element or its children until an ACK from the server is received. The client will remove data-phx-ref from the target element and remove the phx event class from the class list. Then diffs can be merged again into the target element.

What we should consider

We want as much of this behavior to live in Core as possible.

Triggering the event from the client

• When a LVN client is triggering a phx-* event it should also include along with it a way to identify the target element the phx-* event was triggered from. Likely that should come in the form of a selector path for fast document querying.

• Core will block any inbound messages from the server.

• Core applies data-phx-ref to the target element in it's cached DOM

• Core will look up, from the event name, the correct phx-*-loading class and append it to the class list of the target element.

• Core will send the new DOM to the client to merge into its view tree

• Core unblocks inbound messages from the server

• Core will not apply any diffs to elements that have or have a parent that has data-phx-ref applied

Receiving the ACK from the server

• Core will block any inbound messages from the server

• Core removes the data-phx-ref from the target element

• Core removes the event's loading related phx-*-loading class from the target element

• Core sends the new DOM to the client

• Core unblocks inbound messages from the server

• Core resumes applying diffs to the target element that no longer has data-phx-ref applied

[bcardarella]

The challenging parts I think may be:

1. how in the clients do we generate the correct selector path to find the target element in Core
2. ensuring that we can toss out diffs that are applied to target elements and their children

[carson-katri]

Regarding 1, we could use the NodeRef instead of a selector. This will give core the exact ID of the element that is sending the phx-* event.

Sending this data around would be easier once we use core for networking in the client. It could possibly expose a method with a signature that accepts the event and sender:

func sendEvent(event: String, payload: Payload, sender: NodeRef?) async throws -> Payload?

If a sender is specified and event is a known phx-* event, core can perform any changes needed to support data-phx-ref.

[bcardarella]

Sending this data around would be easier once we use core for networking in the client

Agreed, we shouldn't implement this until after we bring in more of Core in v0.4

[simlay]

ensuring that we can toss out diffs that are applied to target elements and their children

Yeah. This is might be challenging. The data structure in Core does keep track of ID which is the nodeRef on swift side. The patching apply logic is a bit more complicated.

I do think that when the clients uses the phoenix-channes-client, this will be easier and more generic.