Stop delivering previous data in unrelated loading results.

[benjamn]

Ever since apollographql/react-apollo#1639, Apollo's React functionality has preserved a strange and nonsensical policy of falling back to the previous data for loading: true results, even though the previous data may have nothing to do with the current request, as #6039 demonstrates. Results with loading: true may provide data from the cache (if any), but they should never simply reuse data from a previous result, which may have been derived using different variables. Instead, result.data should be undefined for loading states that do not have any partial cache data to provide.

This is potentially a breaking change for code that blindly relied on result.data being defined whenever result.loading is true, but I believe the bugs this change will fix are much more serious than the inconvenience of checking the truthiness of result.data before using it. Still, I wish I'd gotten to this sooner.

Fixes #6039, as verified by the reproduction provided by @davismariotti (thanks!).

[benjamn]

I suppose we could default result.data to an empty object here, if we think that will help reduce the risk of this (admittedly late-breaking) change. However, that logic would only apply for React code using QueryData class.

[hwillson]

Storing empty objects in data has gotten us into trouble in the past (as outlined in apollographql/react-apollo#3388), so I'm all for keeping this as is.

[hwillson]

Looks great @benjamn! (I'm surprised / happy so few tests needed to change for this 🎉)

[hwillson]

Storing empty objects in data has gotten us into trouble in the past (as outlined in apollographql/react-apollo#3388), so I'm all for keeping this as is.

[jfrolich]

Might be nonsensical, but it's actually very useful in user interfaces with a filter UI. You'd almost never want to completely go back to a global spinner when a filter is changed. We use this a lot in our app, and it's completely broken after this release. Is this coming back as an option?

I don't think it is unreasonable to do it explicitly in user code. But this would be the largest breaking change that probably nobody expects in Apollo Client 3. So it would be very important to highlight very largely in the release notes.

[macrozone]

@jfrolich absolutly agree! I was blaming all the breakings on the new cache, but a lot of issues was due to this change and its not mentioned as breaking change (or i did not see it)

@jfrolich as a workaround you can do:

// store previous data in a ref
 const previousData = useRef<AssortmentFilters["search"]>();
// your query
  const { data, error, loading } = useQuery<
    AssortmentFilters,
    AssortmentFiltersVariables
  >(QUERY, {
    variables: { assortmentId, searchQueryString, filterQuery },
    skip: skip || (!assortmentId && !searchQueryString),
  });

  if (data?.search) {
    previousData.current = data.search;
  }
  const filters = (data?.search ?? previousData.current)?.filters ?? [];

  return { filters, error, loading };

[maapteh]

For our application this was a big surprise, for the same reason above. Given new arguments to same query now results in total empty data :( Its oke to make the software better, but please mention it in the migration doc.

[robertsmit]

Is it possible to get the old behavior. For example when typing in a searchField en changing the searchText, it is ok to get the old results for the possible options....

[kliakos]

Would be nice to optionally have the old behavior back somehow.

[eranimo]

This should have been disabled by default instead of removed entirely. This is a huge breaking change that is not easy to fix. This upgrade is turning out to be quite the headache.

[akornato]

In an async world it is "nonsensical" to think a user never wants to see old data while they wait for new data. I'm sure there's exceptions, but that's what loading is for. Fortunately we wrap useQuery anyway, thanks @macrozone for the hint how to work around this new behaviour.

[hwillson]

Just a heads up, previousData is now available alongside data in @apollo/client@next (see #7082). 3.3 will be officially published early next week.

[ctataryn]

@hwillson FYI I have added this PR to update the v2 -> v3 migration guide, as this breaking change was a challenge to track down.