LiveUpdate re-render children when updates come from the same owner

[jairo-campos-JD]

<LiveUpdate> reload children components when the sender is the same, LiveUpdate should ignore updates from the same sender or have an option to disable it, this will avoid issues from users and unnecessary components re-renders.

We can add a new prop called clientId(unique per user), this will come with a timestamp and document URI message from WebSockets.

Let me know, what do you think about it @RubenVerborgh .

Thanks,
Jairo

[RubenVerborgh]

Not sure I fully follow. What does “when sender is the same” mean? When the websocket update is triggered by the current, then ignore it?

If this is what you mean, doing it the way you describe is not possible as the client id is not known. Furthermore, if multiple components on the page need live updates, they wouldn’t update.

[james-martin-jd]

One of the root problems we've had using LiveUpdate is changing data too quickly or changing multiple fields at once (such as through an autofill form). This triggers multiple updates, but with different sets of data. We have some basic conflict resolution we're using, and multiple simultaneous updates trigger conflicts even though we sent all of the data so there should be no actual conflicts.

In other words, in something like a form with multiple fields in the same document, liveupdate triggers too much without any context for what the change is, so we're forced to assume it's a change we don't know about.

[jairo-campos-JD]

@RubenVerborgh the idea to have a connection ID is to identify who update the document so we can decide if we need to re-render or not a component into Liveupdate, we can avoid unnecessaries re-renders on components also if user 1 made an update doesn't need to receive the new updates because these updates are in your local store. This will avoid a lot of issues, for example, right now we have an autosave form(field save on tab or onBlur), when user updates the field 1(send updates on field 1 to POD) then tab and start writing field 2 before field 1 was saved on POD field 2 values will lose, why? because when field 1 is saved on Document, LiveUpdate will re-render the component because LiveUpdates detect changes.

[RubenVerborgh]

@james-martin-jd Check, thanks, we're aligned on the problem indeed.

However, I'm afraid that the currently proposed solution will not do.

the idea to have a connection ID is to identify who update the document

I currently cannot imagine how to implement this, since LiveUpdate does not know who updated something.

if user 1 made an update doesn't need to receive the new updates

This would require server-side support, or some guessing (if we just updated x.txt, and we get a message that x.txt was updated, ignore it).

However, this approach (even if we could implement it) would fail if there are multiple LiveUpdate instances.

Unless you see a clear implementation strategy, I'm afraid the necessary elements are just not there.

---

However, I can see alternatives. For instance, we might want to temporarily LiveUpdate when something inside of the <LiveUpdate> is being edited. To make this work, LiveUpdate could expose a setEnabled function that we could call, or something similar. Would such a route be acceptable?