Is there a way to ignore LiveQuery events caused by the current client?

#1

Our app has many-to-many relationships which I manage with a join table. The front-end uses React/Redux and we use optimistic updates. That way if the user does something like re-order a list of 100 items, the UI doesn’t have to wait for the server to respond in order to show the user that the re-ordering worked.

I’m trying to implement LiveQuery so that if a user modifies something (say by re-ordering a list) then any other logged in user can see that updated reflected in their UI without refreshing the page. Or if the user has multiple windows open all looking at the same screen they automatically update to reflect the changes they made.

But with LiveQuery a client receives events even about updates made by that client. This can cause an issue if the user makes multiple updates in succession. For example:

  1. User re-orders a list (updated in Redux) and the client updates are pushed to the server
  2. User re-orders the list again (updated in Redux), pushing more updates to the server
  3. LiveQuery triggers an event from update (1) which reverts the Redux update from (2)
  4. LiveQuery triggers an event from update (2), which brings Redux back in line with (2)

This would create a pretty bad user experience.

So is there a way to ignore any events that were caused by the current client?

#2

In case anyone ever sees this and wants to do the same I found an inelegant solution.

I create a UUID for each client that I store in Redux which I call updateClient. Then when I go to save any Parse objects I do obj.set("updateClient",updateClient) using the value from Redux.

I’m already using rxjs to buffer updates from LiveQuery, so I use the filter operator to filter out updates that were made by the current client using the value stored in Redux.

It means adding an extra column to all of my classes but at least it works.

#3

Answering your question, by default there is no way to know who updated or ignore self updates in Live Query. Creating a column to store who updated the object would actually be the best way to later know who updated it before. But for your case I’d try to do something with the updatedAt or objectId columns. Basically on 3, before updating the Redux store, you could check these columns to see if it is an old update and discard it if it is the case.