Update SWR's Cache with a Server-side Response

Sam Selikoff
InstructorSam Selikoff
Share this video with your friends

Social Share Links

Send Tweet
Published 4 years ago
Updated 3 years ago

We can use the mutate() hook again to update our client-side cache using the canonical ID from the server response.

Sam Selikoff: [0:00] Next we need to make the POST request. Let's grab our existing code here where we create a todo and try this out. Test.

[0:21] There we see the POST request. If we reload the app, we see that our data has persisted in our server. The app seems to be working, but the input field feels unresponsive again because it's disabled while the POST request is going out.

[0:37] That's because we're setting the saving state here to true, and then we're now waiting the POST request and then we're setting it back to false. Let's just comment that out for now.

[0:50] If we restart the server and give this another shot, A, we'll see that we're also resetting the input state here after the POST request as well. Let's move this up to right after we have optimistically updated the cache. Now if we try this, One fish, Two fish, red fish and blue fish, everything's fast again and there's no delay in our typing.

[1:30] We can also come down here and remove this code that focuses the input since we never disable the input anymore.

[1:38] Let's reset the server and look at one more thing. If we inspect the DOM here, we'll see that each one of these list items has a data-todoId equal to the id of the todo. If we were to create a new Test todo, we'll see that our new todo has our temporary id right here.

[2:05] We did send out that POST request, we did create that todo and if we were to look at the response here, the server did come back with the new canonical id based on our real server response. Ideally, that would also end up in the UI.

[2:20] SWR will actually re-validate when you re-focus the window and so, you'll see right there our list re-rendered with the new id, but that's because we made a new GET request. Ideally, we would just update our cache with the JSON right after this step because at this point, we already know what the new id is.

[2:41] We can get rid of the rest of this old code. We can just call mutateTodos again after the fact to update our cache. Except this time, our todos collection is going to be our current data.todos with the exception of the todo we just created.

[3:02] We can map this collection and check if the todo.id === tempId. If it is, we're going to replace this with json.todo. Otherwise, we'll just use the existing todo.

[3:21] Now, if we look at our list item here, and we create A new todo, we see it was appended with the temporary id and then it was replaced with the server side id once the POST request came back with a success. Let's look at another one. Our client-side cache is consistent as soon as the todo is created.

~ an hour ago

Member comments are a way for members to communicate, interact, and ask questions about a lesson.

The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io

Be on-Topic

Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.

Avoid meta-discussion

  • This was great!
  • This was horrible!
  • I didn't like this because it didn't match my skill level.
  • +1 It will likely be deleted as spam.

Code Problems?

Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context

Details and Context

Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!

Markdown supported.
Become a member to join the discussionEnroll Today