TanStack Query in React Native - A Rick & Morty server-side filtering question (interactive example inside)

[spasmodiumspam-web]

I prepared an interactive/editable single file expo-snack example that you can run in the browser (or simply download the expo go app on your phone, scan the QR code and you're ready to go)

I have a Rick and Morty CRUD app with server-side filtering (multiple filters that can be applied at once) and infinite scrolling. We apply filters from a modal and those are status and gender. In the past I'd do this manually manually which was a nightmarish mess. Maintaining all those error, loading states and everything. But I recently discovered useInfiniteQuery from TanStack Query and it seemed perfect. But while trying to implement it, I also discovered some pitfalls and I'm here asking you how to avoid them and what is good design in this scenario.

In the code above (which has console.logs, by the way, to make it easier to follow):

1. We enter the app, we're on the Home tab. We switch to MyList tab.
2. Data is fetched (no filters applied yet) - log API {"page":1,"filters":{"name":"","status":"","gender":""}}
3. We select Filters button in the upper right button, select "Dead" and "Male" and hit "Apply" button - an API call is made - log API {"page":1,"filters":{"name":"","status":"dead","gender":"male"}}
4. First item should normally be "Adjudicator Rick", we click , change his status from "Dead" to "Alive". We hit "Save Changes" and that will mock a PUT request that only returns a 200 status for succes, because this Rick and Morty API is a public API that doesn't allow us to change data, we'll just pretend it happened - log API UPDATE {"characterId":8,"updates":{"status":"alive","gender":"male"}}.

Right now, the thing you'd normally do is invalidate the query and basically refetch the data with the existing filtering params, right?

But I don't wanna do that. Because this is a case in which I know exactly that the API will only change one thing - the status property. Not the order, not anything else. So I'd ideally want to spare a GET API call and only update the interface. In the past, without TanStack query, I'd just update the state, looking for the element with the ID I just clicked and modifying it or taking it out of the list or whatever. However, now I have to do something like this:

const handleSaveUpdates = async (characterId, updates) => {
  try {
    // 1️⃣ Persist updates on the backend
    await updateCharacter(characterId, updates);

    // 2️⃣ Get all cached queries starting with ['characters']
    const queries = queryClientInstance.getQueriesData({ queryKey: ['characters'] });

    queries.forEach(([queryKey, oldData]) => {
      if (!oldData) return;

      // 3️⃣ Extract this query's filters
      const queryFilters = queryKey[1];

      // 4️⃣ Update this specific cache entry
      queryClientInstance.setQueryData(queryKey, {
        ...oldData,
        pages: oldData.pages.map(page => ({
          ...page,
          characters: page.characters
            // 5️⃣ Update matching character
            .map(c =>
              c.id === characterId
                ? { ...c, status: updates.status, gender: updates.gender }
                : c
            )
            // 6️⃣ Remove updated character if it no longer matches filters
            .filter(c => {
              if (c.id !== characterId) return true;

              const matchesStatus =
                !queryFilters?.status ||
                c.status.toLowerCase() === queryFilters.status.toLowerCase();

              const matchesGender =
                !queryFilters?.gender ||
                c.gender.toLowerCase() === queryFilters.gender.toLowerCase();

              const matchesName =
                !queryFilters?.name ||
                c.name.toLowerCase().includes(queryFilters.name.toLowerCase());

              return matchesStatus && matchesGender && matchesName;
            }),
        })),
      });
    });

    console.log('CACHE UPDATED INTELLIGENTLY', { characterId, updates });
  } catch (error) {
    console.error('UPDATE FAILED', error);
  }
};

Needless to say, this is ugly as a sin, extremely verbose and I can't help myself but wonder...is this the wrong approach and I'm playing with fire? If we have even more complex filters, won't this become extremely tangled, hard to follow and write? Will new developers introduce bugs without ever knowing?

Questions:

1. By modifying the cache like this, do I risk bugs? For example, if user starts infinite scrolling on the list after an update like we did above? Because we just took an element out of the cache, maybe TanStack's internal mechanism and pagination logic still see n elements, not n-1?
2. Is it a better idea to just modify the element (eg: the status) in the current filtered list cache and not remove it, even if it doesn't belong to the current filter after the modificatins and just let the user pull to refresh or something for fresh data?
3. Is it a better idea just to call it a day and refetch? Although, with the previous approach, if we have 50.000 users (for example) we could spare the API additional GET requests after a successful mutation.

I genuinely feel that with with all the staleTimes and options (some enabled by default) that TanStack Query has and me being a total beginner to the library, I'm just plotting for a disaster/subtle bugs to happen right now because, as I understand, every filtering combination is kept in a cache as a separate list and I have to know precisely what cache to update. And suddenly, this infinite scrolling hook which was supposed to simplify things is making the entire logic way more complicated that it initially seemed.

Am I totally doing it wrong?

Thank you in advance!

[TkDodo]

In the past, without TanStack query, I'd just update the state, looking for the element with the ID I just clicked and modifying it or taking it out of the list or whatever.

You’re still basically just doing that. The code gets verbose because you have to know that you have to take it out of the list instead of just updating a value.

The thing you are doing that I think is “too much” is to iterate over all lists and update all of them. The only list that matters for the update is usually the one the user is currently on. Without TanStack Query, you only have the current data in state, so you don’t have the chance to manually update other lists, like ones with different filters.

But you don’t have to do that. What I would do is:

• only update the list with the current filters:

queryClientInstance.setQueryData({ queryKey: ['characters', filters] }, prev => ... do update logic here)

- invalidate all inactive `character` lists without refetching them:

queryClientInstance.invalidateQueries({ queryKey: ['characters'], type: 'inactive', refetchType: 'none' })

since `do update logic here` should be largely the same lines of code than with normal state (if you store them in a paginated structure, yes, the iterating over `.pages` is a bit cumbersome but we don’t have a flat structure in the cache), the main additional code is like a one liner of invalidating.

This means if users switch filters and they have cached data, they will see a quick flash without the update before they get the update, but this is usually a good enough trade-off to make.