Update SWR's Cache with a Server-side 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.