executeQuery return value

[josduj]

I'm using useQuery from react package, and I noticed that executeQuery doesn't return anything. I'm wondering if you are open to the idea of returning a promise or a source?

This is briefly what I'm looking to achieve

import { useQuery } from 'urql';

const Foo = () => {

  const [{ data }, executeQuery] = useQuery(...);

  const refetch = () => {
    executeQuery().then(() => {
      ...
    });
  }

}

And this is the proposed change

diff --git a/packages/react-urql/src/hooks/useQuery.ts b/packages/react-urql/src/hooks/useQuery.ts
index 2bc1a494..47956f08 100644
--- a/packages/react-urql/src/hooks/useQuery.ts
+++ b/packages/react-urql/src/hooks/useQuery.ts
@@ -1,7 +1,7 @@
 // eslint-disable react-hooks/exhaustive-deps
 
 import { DocumentNode } from 'graphql';
-import { Source, pipe, subscribe, onEnd, onPush, takeWhile } from 'wonka';
+import { Source, pipe, subscribe, onEnd, onPush, takeWhile, take, toPromise } from 'wonka';
 import { useState, useEffect, useCallback, useMemo } from 'react';
 
 import {
@@ -200,6 +200,8 @@ export function useQuery<Data = any, Variables = object>(
         const nextResult = computeNextState(state[1], snapshot);
         return state[1] !== nextResult ? [source, nextResult, state[2]] : state;
       });
+
+      return pipe(source, take(1), toPromise);
     },
     [client, request, getSnapshot, args.requestPolicy, args.context]
   );

[kitten]

This unfortunately won't work 😅 either you update the hook's state and programmatically start a new execution or you want to get to the result; having both in one really isn't desirable.

For instance, the change diff you posted here would internally start two operations. Now, this isn't bad, but it's also not expected. Instead, it's also possible to directly use client.query(...).toPromise() in these cases, which is recommended for imperative queries.

In other cases it's more desirable to use the hook's existing state as needed as it'll lead to more consistent effects. Particularly because its lifecycle is more in line with reacting to changes from the client (rather than showing a one off result)

A promise-based return value on executeQuery is unfortunately confusing. For instance, for cache-and-network and cache-first it doesn't give the user a lot of insight and control when the promise may resolve. Ultimately, promises are a bad abstraction for anything but explicit, imperative, atomic operations.

[josduj]

Ah, yes, that makes sense. Thanks for the explanation!

I'm doing the react-apollo to urql migration, so I was trying to make it go as smooth as possible, but I guess client.query(...).toPromise() will have to do