How to avoid letting an async thunk that is no longer useful (the app is not expecting it anymore) from being able to update the state?

Question

I have the following pattern on my single page app (React + Redux).

It runs every time a load a page on the app. User navigates to a specific page, and the loadPageThunk is dispatched. The initial state of the page shows a spinner to the user. This is used for example, in a blogpost page.

That thunk will get some async data (the blogpost), and then will show the page with that data.

It works fine. When the user navigates away from the page. A useEffect dispatches a RESET action to reset the state back to its initial value.

My question is:

What if the async call takes too long to complete and the user navigates away? It will create a problem because now there's a pending promise that will complete in an unexpected time. How can I prevent that completion from updating my state?

Imagine the following steps for an async call that is taking 10 seconds to complete:

#### FIRST PAGE LOAD ####

USER VISITS blog/slug-1
loadPageThunk() IS DISPATCHED
blogPost1 STARTS GETTING FETCHED (WILL TAKE 10 SECONDS)
USER NAVIGATES AWAY

#### SECOND PAGE LOAD ####

USER VISITS blog/slug-2
blogPost2 STARTS GETTING FETCHED (WILL TAKE 10 SECONDS)
USER IS STILL SEEING SPINNER
blogPost1 (FROM THE PREVIOUS VISIT) HAS COMPLETE AND WILL UPDATE THE STATE
USER NOW SEES blog/slug-2 WITH THE DATA FROM blogPost1 WHICH IS AN ERROR
blogPost2 WILL EVENTUALLY COMPLETE AND USER WILL SEE A CONTENT FLICKER ON THE PAGE

QUESTION

How can I avoid pending promises that are no longer useful from being able to update the state?

This problem is not currently happening in my app, but I think that a good design should account for that.

Should I add an ID for my LOAD_PAGE cycle, so I can check the ID of the current cycle before allowing callbacks / async code from updating the state when IDs don't match? How do people usually handle this?

Answer 1

Personally I store blog data as entities (posts, comments, etc.) keyed by id and collections. The collection is just the array of post ids on a particular page.

For example,

{
  entities: {
     posts: {
       1: {...},
       2: {...}
     },
     comments: {
        123: {...},
        999: {...}
     }
  },
  collections: {
     "blog/slug-1": [99,98,97...],
     "blog/slug-2": [89,88,87...],
  }
}

This sort of structure means that every page can save its data in the correct place regardless of whether it is the current page or not. It also means that every page can select its own data and can see whether that data already exists in the state.