fetching initially false?

[tlrobinson]

All the documentation and code examples suggest if you check that fetching is true and error is falsey then you can assume data is not null.

e.x.

const YourComponent = () => {
  const [{ fetching, data }] = useQuery({ query: `{ todos { id } }` });
  return fetching ? <Loading /> : <List data={data.todos} />;
};

https://github.com/FormidableLabs/urql#quick-start-guide

However, that's not what I'm seeing. fetching is initially false:

This happens for both the Query component and useQuery hook. Unless you explicitly check that data is not null then these examples will crash.

Or am I missing something?

Version: 1.0.5

[luisrudge]

I'm having the same issue right now 😬

[d3vhound]

Yeah doesn't really make sense. It's cumbersome to have to work around fetching always being false at initial render. Hope this isn't intentional.

[kitten]

the PRs #250 and #256 ensure that the initial state you receive from useQuery will always reflect what's going on internally.

They also lay the ground work necessary to implement SSR. So you can expect all of this to ship in v1.1

[larsbs]

I still don't understand the reasoning behind this, because now, we can't just simply rely on fetching to know if we should render a loading state or the final component removing the possibility of having one single source of truth.

Also, that always generates an extra rendering cycle for every component. First, fetching = false and data = undefined, and then fetching = true and data = whatever.

[kitten]

@larsbs as posted above though, this will be fixed in the next version.

[larsbs]

@kitten Oh sorry, I understood actually the opposite, that it was expected behavior and it would ship in the final version. Thanks.

[kitten]

@larsbs sorry, I'll post a more extensive explanation 😅

Basically this was fixed by the two linked PRs which happened to set up some preliminary behaviour for the SSR PR as well.

During initial mount they cause effects and state changes to run synchronously due to two special hooks. Since our exchange pipeline is built to be mostly synchronous this means that the initial state will match the ongoing / completed operation more closely.

When it starts fetching the state change setting it to true will immediately be applied on mount without an additional render.

But additionally this also means that you will immediately get the data you queried if it has already been cached before

[larsbs]

That's perfect, so I guess that would also fix the other issue I had #267 good job 👍