Weird query lifecycle transitions about graphql-react HOT 9 CLOSED

Yeah, weird. Let me try to reproduce the issue in a codesandbox. If I'm doing something wrong I'll probably find out then. I'll keep you posted.

from graphql-react.

Thanks for your quick reply.

internally two useState values are being set, one immediately after the other, which in React can result in two very fast "renders"

Actually as you can see in this codesandbox example, that's not the case: https://codesandbox.io/s/green-architecture-023dc
Doing 2 following setState still will trigger 1 single render with both setState applied at the same time (not one after the other).

Anyway I will try to have a look at the source code of the useGraphQL see if I find something. Good luck with your new contract!

from graphql-react.

I'm not sure why at first you're getting loading: false, since in the tests that does not happen:

from graphql-react.

@jaydenseric I was able to reproduce it in this codesandbox.

from graphql-react.

Bear with me, but I think this may be working as intended.

It's been a while since I dove deep into React hooks, exploring all the gotchas (console.log debugging hooks is confusing), but here are my rusty thoughts…

The first log of loading: false is correct; because that state only updates once it actually starts loading, which is not until after it mounts. The first console.log can be from a render that happened before the useEffect triggers loading. Note that in the situation where the exact same query is already loading in the client (triggered by something somewhere else) at the time the component mounts, the first log may be loading: true.

Now my memory may be hazy/wrong, but when multiple useState values are updated internally there can be multiple re-renders, but you don't actually see each re-render happen in the real DOM if they happen quickly.

You do need to make sure you nest any JSX using cacheValue.data in a conditional that checks data actually exists first.

from graphql-react.

Closing because I'm pretty sure everything is working as intended; the general rule is to account for cacheValue sometimes not being defined, as documented in all the useGraphQL examples:

const { loading, cacheValue = {} } = useGraphQL({
  // …
})

https://github.com/jaydenseric/graphql-react/tree/v9.1.0#examples-8

I always do cacheValue = {}, and haven't had any problems in all my apps.

It's potentially useful to be able to tell when rendering if there is no cache for a particular query, so it's probably good to leave the API the way it is and not default cacheValue to an empty object.

from graphql-react.

I'm having the same issue and I did a reproductible example with the doc snippet fetching a Pokemon: https://codesandbox.io/s/gracious-leakey-hisdk

As described by @olistic there is a state that imo should not happen:

1. loading starts: { loading: true, data: undefined }

2. loading is finished but data is still undefined?? { loading: false, data: undefined }
   This state does not make sense because it then trigger the if condition displaying "Error!" in the CodeSandbox (it's not visible on the example since it's instantly removed).

3. One tick later, finally the data is there: { loading: false, data: {…} }

As you can see in that CodeSandbox I don't think there is any external hook hijacking the render loop in the middle that could cause that. So it seems to come from graphql-react.
In my app this is actually causing an issue since I'm displaying an error message with a transition animation so even if the wrong state is really short, it stills trigger the in/out animation creating a flash of the error state.

from graphql-react.

@Grsmto are you using console.log to debug the hook return value? A quick guess is that internally two useState values are being set, one immediately after the other, which in React can result in two very fast "renders", but only one change to the DOM.

I plan to look into how these lifecycle gotchas can be improved when I start work on the next version; I've been working hard on other projects lately (several new testing related packages, and graphql-upload v10), and now I've got full time contract work to contend with.

from graphql-react.

This should be improved in v10.0.0 🚀

from graphql-react.