reexecuteQuery for jotai/urql

[etodanik]

Do I understand correctly that there is no mechanism at all to reexecute a query in jotai/urql? In the regular urql hooks there is this method:
https://formidable.com/open-source/urql/docs/basics/react-preact/#reexecuting-queries

const Todos = ({ from, limit }) => {
  const [result, reexecuteQuery] = useQuery({
    query: TodosListQuery,
    variables: { from, limit },
  });

  const refresh = () => {
    // Refetch the query and skip the cache
    reexecuteQuery({ requestPolicy: 'network-only' });
  };
};

Not being able to reexecute queries seems like a rather big limitation.

[dai-shi]

I wasn't aware the reexecute feature. I don't know how I missed it. We have "refetch" feature in jotai/query. So, we should follow the pattern.

[dai-shi]

Actually, it doesn't work like jotai/query. 🤔

[etodanik]

In urql it gets returned separately from the result object.

…

On Fri, Aug 20, 2021, 06:39 Daishi Kato ***@***.***> wrote: Actually, it doesn't work like jotai/query. 🤔 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#666 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPBB6CHUIQQIVHXQK7PR6LT5XFAHANCNFSM5COK5IYQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[etodanik]

I'd be happy to contribute code if we can agree on a spec. For now in my app I had to comment out Jotai and replace it with a pure urql query for the specific place where I needed refetch. So Im available to contribute On Fri, Aug 20, 2021, 09:48 Danny Povolotski ***@***.***> wrote:

…

In urql it gets returned separately from the result object. On Fri, Aug 20, 2021, 06:39 Daishi Kato ***@***.***> wrote: > Actually, it doesn't work like jotai/query. 🤔 > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#666 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAPBB6CHUIQQIVHXQK7PR6LT5XFAHANCNFSM5COK5IYQ> > . > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> > . >

[dai-shi]

Please try if https://ci.codesandbox.io/status/pmndrs/jotai/pr/668 works.

[dai-shi]

So Im available to contribute

Well, I should have asked for your help from the beginning. Next time.

I will merge #668 soon.

[etodanik]

@dai-shi I'll test it today & let you know that it works!

[dai-shi]

Okay, I will wait. (I was about to cut a release.)

[dai-shi]

Well, I think we can release it, and if something goes wrong, we'll fix it ASAP.

[etodanik]

I tested it, the refetching it self seems to work, but if I understand correctly, I now can't know about the fact that it is refetching/refreshing? In vanilla urql there is the fetching variable which is part of the result. What would be the pattern to know we're refetching in this new update?

[dai-shi]

Yeah, that was my question too actually. For now, it will throw a promise, so it suspends on refetch just like the first fetch, right? This behavior is consistent with atomWithQuery in jotai/query.
I think we never used fetching variable in favor of Suspense. Does vanilla urql have fetching?

[etodanik]

@dai-shi vanilla urql indeed has fetching returned as part of the result object (https://formidable.com/open-source/urql/docs/api/urql/#usequery). I can think of quite a lot of use cases where for a query having a fetching variable would be useful vs. a thrown Promise, especially on second and subsequent loads. A degree of control (suspend vs. non-suspend) could be useful, what do you think?

For example, in my current use-case with React Native, the actually has a refreshing prop (https://reactnative.dev/docs/flatlist#refreshing) that triggers a much more sophisticated experience than just eliminating the list and showing a loading indicator fallback. It implements the whole "drag to refresh" dynamic.

Another example is when an initial load is done on something like a feed & you'd want to fetch in the background and only re-rendering if new items appear without indicating a loader to the user.

[dai-shi]

Yeah, fetching is in react-urql.
jotai atoms are designed for Suspense and useTransition, which might be too futuristic for now.
I understand that distinguishing between the initial fetching and refetching is important in the real use case. We hope to come up with some ideas for both jotai/urql and jotai/query.
btw, you might be interested in the new util at #672. Actually, it could solve refetching issue there.

Apart from jotai, I wonder how drag to refersh and background refetch will be implemented as best practices in Suspense era.

[etodanik]

That util would be the perfect temporary measure for now, until the world figures out new design patterns 👍 You're absolutely right, this is a case of a future pattern not yet having gone through enough discovery to find all the right use cases. However, combined with a util like that one, this makes it perfectly usable in the real world. I'll jump over there and see what the state of it is.

…

On Thu, Aug 26, 2021, 06:56 Daishi Kato ***@***.***> wrote: Yeah, fetching is in react-urql. jotai atoms are designed for Suspense and useTransition, which might be too futuristic for now. I understand that distinguishing between the initial fetching and refetching is important in the real use case. We hope to come up with some ideas for both jotai/urql and jotai/query. btw, you might be interested in the new util at #672 <#672>. Actually, it could solve refetching issue there. Apart from jotai, I wonder how drag to refersh and background refetch will be implemented as best practices in Suspense era. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#666 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPBB6ANMLCQ7HAAQTYYB6DT6W3QDANCNFSM5COK5IYQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .