Gotchas with an auto-save field

[mvasin]

Hi!

I'm trying to implement an input field that would "flush" its value to the backend as soon as possible. The server I'm working with is sluggish and responds with random delays. It also returns errors from time to time, but I'll leave that out of scope.

First, the naive approach: useMutate to submit the data to the server, useQuery to get it back, and queryClient.invalidateQueries to in the former to trigger update in the latter. Here's the codesandbox reproduction. The fake backend response delay randomly varies up to 2 seconds, and the user experience is horrible - the input filed is freezing, race conditions overwrite the value of the input field.

Well, that's expected, let's move on to the optimistic updates.

I did it by the book: added await queryClient.cancelQueries and queryClient.setQueryData in async onMutate. Here's the optimistic updates version on codesandbox. Surprisingly, there are still nasty race conditions (try typing into the field).

[TkDodo]

I think your code looks fine, and there isn't much react-query (or the frontend in general) can do here (except debounce the mutations maybe): queries can be cancelled to not override outgoing mutations, but if you fire off two mutations at the same time, I think it's the server's responsibility to handle concurrent modifications (ignore them or queue them).

In your example, given a serverState of "a", I typed "b" and then "c" and got the following log output (I also added the values to the logs):

- started POSTing ab to the server (this will overwrite a on the server) with a delay of 1s 
- started POSTing abc to the server (this will overwrite a on the server) with a delay of 0.3s 
- finished POSTing abc to the server (this will overwrite a on the server) with a delay of 0.3s abc 
- started GETting abc from the server with a delay of 1.3s 
- finished POSTing ab to the server (this will overwrite a on the server) with a delay of 1s ab 
- finished GETting abc from the server with a delay of 1.3s ab 
- started GETting ab from the server with a delay of 1.3s 
- finished GETting ab from the server with a delay of 1.3s ab 

The ab mutation arrives first on the server, and then the abc post arrives, but this one finishes first. Then, we invalidate and get the latest value, which will be abc. But only then, the ab mutation finishes and sets the server value to ab.

So technically, the latest value is then ab and that is reflected. If this were a real database, I would have expected an update lock on the row when we try to write ab to the database, so that we cannot, at the same time, also write abc.

[lukesmurray]

While I agree some of this is the responsibility of the server, I think the developer experience of writing synced state could be improved. @TkDodo I was inspired by your blog post which separated the data into a draft/server state. I put together a hook which can be used to automatically poll data from the server and post data to the server when the data has changed.

code sandbox demo

In the demo I have the same "form" replicated twice on the page which shows how local state can be displayed in multiple places, and if you open up a second browser tab you can see that the state is synced to a server.

The implementation for the hook is in useAutoSyncQuery. The hook creates a nice abstraction where the user can call useAutoSyncQuery and receive value, setValue which let them treat the synced value as if it is local state.

The hook does rely on zustand but I Hope this helps other people trying to implement this type of functionality in the future!