T
TanStack•3y ago
other-emerald

Removing callbacks from useQuery

Is this the right patch to remove the callbacks from useQuery's options? 
diff --git a/src/types.ts b/src/types.ts
index 9426089293bb7b217e4aa156a6ec21c79a8e4c19..1d2ef5e8628069f8f8928e392ea8f32c6d7d1339 100644
--- a/src/types.ts
+++ b/src/types.ts
@@ -202,24 +202,6 @@ export interface QueryObserverOptions<
    * By default, access to properties will be tracked, and the component will only re-render when one of the tracked properties change.
    */
   notifyOnChangeProps?: Array<keyof InfiniteQueryObserverResult> | 'all'
-  /**
-   * This callback will fire any time the query successfully fetches new data.
-   *
-   * @deprecated This callback will be removed in the next major version.
-   */
-  onSuccess?: (data: TData) => void
-  /**
-   * This callback will fire if the query encounters an error and will be passed the error.
-   *
-   * @deprecated This callback will be removed in the next major version.
-   */
-  onError?: (err: TError) => void
-  /**
-   * This callback will fire any time the query is either successfully fetched or errors and be passed either the data or error.
-   *
-   * @deprecated This callback will be removed in the next major version.
-   */
-  onSettled?: (data: TData | undefined, error: TError | null) => void
   /**
    * Whether errors should be thrown instead of setting the `error` property.
    * If set to `true` or `suspense` is `true`, all errors will be thrown to the error boundary.
diff --git a/src/types.ts b/src/types.ts
index 9426089293bb7b217e4aa156a6ec21c79a8e4c19..1d2ef5e8628069f8f8928e392ea8f32c6d7d1339 100644
--- a/src/types.ts
+++ b/src/types.ts
@@ -202,24 +202,6 @@ export interface QueryObserverOptions<
    * By default, access to properties will be tracked, and the component will only re-render when one of the tracked properties change.
    */
   notifyOnChangeProps?: Array<keyof InfiniteQueryObserverResult> | 'all'
-  /**
-   * This callback will fire any time the query successfully fetches new data.
-   *
-   * @deprecated This callback will be removed in the next major version.
-   */
-  onSuccess?: (data: TData) => void
-  /**
-   * This callback will fire if the query encounters an error and will be passed the error.
-   *
-   * @deprecated This callback will be removed in the next major version.
-   */
-  onError?: (err: TError) => void
-  /**
-   * This callback will fire any time the query is either successfully fetched or errors and be passed either the data or error.
-   *
-   * @deprecated This callback will be removed in the next major version.
-   */
-  onSettled?: (data: TData | undefined, error: TError | null) => void
   /**
    * Whether errors should be thrown instead of setting the `error` property.
    * If set to `true` or `suspense` is `true`, all errors will be thrown to the error boundary.
currently trying to trigger something that will lint or typecheck with an error whenever I use those callbacks - I added https://github.com/gund/eslint-plugin-deprecation, but it seems the react queries are too complicated for it to detect those doc comments...
12 Replies
other-emerald
other-emeraldOP•3y ago
looks like the eslint plugin i used doesn't support detecting deprecated object property assignments, just consumption of those deprecated properties https://github.com/gund/eslint-plugin-deprecation/issues/13
GitHub
No warnings about setting a deprecated property · Issue #13 · gund/...
type T = { new?: string; /** @deprecated */ old?: string; }; const myT: T = { // I'd expcect an ESLint warning here, but there is none old: 'value' }; console.info(myT.old); // I only g...
other-emerald
other-emeraldOP•3y ago
cc @TkDodo 🔮 if i can poke :p was trying to use pnpm patch to remove the callbacks from the useQuery options type before upgrading to v5, but I seem to not have the right patch
stormy-gold
stormy-gold•3y ago
yeah that diff looks right
other-emerald
other-emeraldOP•3y ago
🙈 somehow it still typechecks
other-emerald
other-emeraldOP•3y ago
No description
other-emerald
other-emeraldOP•3y ago
applying the above patch w/ pnpm :shrug:
No description
other-emerald
other-emeraldOP•3y ago
oh well, ig i'll just manually work on it / eventually upgrade to v5
stormy-gold
stormy-gold•3y ago
Ah you probably shouldn't patch the src dir
other-emerald
other-emeraldOP•3y ago
derp yup that did it 🙈 tyyy is there an ergonomic way to replicate this w/o callbacks? 
 // If we fetched new data, let's cache the prior data under the prevCursor, so it's fast to go back
    onSuccess(newResponse) {
      // Check if we went forward a page
      if (
        newResponse.metadata?.hasPrevPage &&
        relaysQuery.data?.metadata?.page &&
        newResponse.metadata.page?.start === relaysQuery.data.metadata.page.start + relaysQuery.data.metadata.page.count
      ) {
        // `relaysQuery.data` and `relaysQuery.metadata` still refer to the prior data
        queryClient.setQueryData(relayQueryKeys.list(newResponse.metadata.prevCursor, pageSize, filters), {
          data: relaysQuery.data.data,
          metadata: relaysQuery.data.metadata,
        });
      }
    },
 // If we fetched new data, let's cache the prior data under the prevCursor, so it's fast to go back
    onSuccess(newResponse) {
      // Check if we went forward a page
      if (
        newResponse.metadata?.hasPrevPage &&
        relaysQuery.data?.metadata?.page &&
        newResponse.metadata.page?.start === relaysQuery.data.metadata.page.start + relaysQuery.data.metadata.page.count
      ) {
        // `relaysQuery.data` and `relaysQuery.metadata` still refer to the prior data
        queryClient.setQueryData(relayQueryKeys.list(newResponse.metadata.prevCursor, pageSize, filters), {
          data: relaysQuery.data.data,
          metadata: relaysQuery.data.metadata,
        });
      }
    },
basically we have an opaque prevCursor & so we serialize the last request as a cache data under that cursor... kinda hacky tbh but it works with our particular setup ah... 
 const { isSuccess, data: newResponse } = query;
  const [previousResponse, setPreviousResponse] = useState(newResponse);

  useEffect(() => {
    // If we fetched new data, let's cache the prior data under the prevCursor, so it's fast to go back
    if (isSuccess) {
      // Check if we went forward a page
      if (
        newResponse.metadata?.hasPrevPage &&
        previousResponse?.metadata?.page &&
        newResponse.metadata.page?.start === previousResponse.metadata.page.start + previousResponse.metadata.page.count
      ) {
        // `hostsQuery.data` and `hostsQuery.metadata` still refer to the prior data
        queryClient.setQueryData(lighthouseQueryKeys.list(newResponse.metadata.prevCursor, pageSize, filter), {
          data: previousResponse.data,
          metadata: previousResponse.metadata,
        });
      }
      setPreviousResponse(newResponse);
    }
  }, [filter, isSuccess, newResponse, pageSize, previousResponse?.data, previousResponse?.metadata, queryClient]);
 const { isSuccess, data: newResponse } = query;
  const [previousResponse, setPreviousResponse] = useState(newResponse);

  useEffect(() => {
    // If we fetched new data, let's cache the prior data under the prevCursor, so it's fast to go back
    if (isSuccess) {
      // Check if we went forward a page
      if (
        newResponse.metadata?.hasPrevPage &&
        previousResponse?.metadata?.page &&
        newResponse.metadata.page?.start === previousResponse.metadata.page.start + previousResponse.metadata.page.count
      ) {
        // `hostsQuery.data` and `hostsQuery.metadata` still refer to the prior data
        queryClient.setQueryData(lighthouseQueryKeys.list(newResponse.metadata.prevCursor, pageSize, filter), {
          data: previousResponse.data,
          metadata: previousResponse.metadata,
        });
      }
      setPreviousResponse(newResponse);
    }
  }, [filter, isSuccess, newResponse, pageSize, previousResponse?.data, previousResponse?.metadata, queryClient]);
would be cool if this was a "feature flag" in the current releases, so people could remove these callbacks before v5
other-emerald
other-emeraldOP•3y ago
other-emerald
other-emeraldOP•3y ago
thx for the help again 💜
other-emerald
other-emeraldOP•3y ago
https://twitter.com/TkDodo/status/1653418107103264774/photo/2 oooh
Dominik 🇺🇦 (@TkDodo)
💁‍♂️React tip: I think most implementations of usePrevious will write to a ref in an effect and return it, but the rules of react advise us to not read refs during render. Here is my implementation, based on what I learned in the new react docs (https://t.co/JltAPkVKi4):
Likes
286
From Dominik 🇺🇦 (@TkDodo)
Twitter
From An unknown user

Did you find this page helpful?