Request cancellation / prioritization

[albingroen]

Scenario

I have a query that looks something like this:

const { data: player ) = useQuery(user ? '/api/player' : null, {
  refreshInterval: 500
})

I use this data in order to show how far a song has been played (I'm using the Spotify API, proxied through Next.js API routes).

<Player progress={player.progress / player.item.duration} />

Now, I also have manual controls, for playing/pausing/volume etc. These execute a mutation to their according API routes (/api/play, /api/pause, etc.). I also do a optimistic update on these (/api/player) before I run the actual request, in order to faster update the UI.

Problem

If a user clicks on the play/pause button, it sometimes get reverted to its previous state, if a refresh started on in the same interval as the user clicked the button.

Here's a demo of the issue occurring. (On the second tap you will see the pause/play button jump back to its previous position, until it gets back to the correct one again):

CleanShot.2021-04-08.at.08.26.36.mp4

Here's a very simple illustration of what happens:

[shuding]

Thanks for the details, and the beautiful diagram!

My suggestion is to do the following when you want to do an optimistic update:

mutate(localState, false)      // update local state
mutate(async () => {
  await sendTheRequest()       // update server state
  return localState
})

The reason of the second mutate is, it blocks all revalidations (refresh) in the background. If there're ongoing mutations in SWR, the data will not be updated by background polling requests. And when the second mutate finishes, the data will be consistent in both server and client.

If the sendTheRequest request also returns the latest state, or it fails, you can even handle more logic here:

mutate(localState, false)
mutate(async () => {
  try {
    const newServerState = await sendTheRequest()
    return newServerState // might differ from `localState`
  } catch (err) {
    return oldState   // request failed, fallback to the previous state!
  }
})

Also make sure you are using the latest version of SWR, or the beta version swr@beta if you want to. Let me know if that helps!

[albingroen]

Thanks for getting back to me. Unfortunately, it doesn't really seem like this helps. As you can see in the video below, after clicking the volume-up button 5-6 times, you can see it jump back to its previous position before it jumps ahead to the correct one.

CleanShot.2021-04-08.at.21.52.46.mp4

I will also include the entire function for changing volume, so you can see how I implemented your suggestion.

  const adjustVolume = (level: number) => {
    // New local state
    const newState = {
      ...player,
      device: {
        ...player.device,
        volume_percent: level,
      },
    };

    // Update local state
    mutate("/api/player", newState, false);

    // Function for upadting on the server
    const makeRequest = async () => {
      return axios
        .put("/api/volume", {
          volume_percent: level,
        })
        .then(() => undefined)
        .catch(() => alert("Something went wrong"));
    };

    mutate("/api/player", async () => {
      // Updating on the sever
      await makeRequest();

      // Retuning local state
      return newState;
    });
  };