Synchronous Local-State Resolvers Don't Return Data Synchronously

Intended outcome:

Admittedly, this might fall into feature request territory, but here goes.

I have a local state resolver that returns something synchronously. Whenever I go to query it, though, it always returns data: undefined at first then an instant later returns the actual data.

I suspect that this is because Apollo will always await the result of a local resolver, even if it returns a non-thennable. This mandates an event loop tick and thus the component is rendered with an initial value of null.

Actual outcome:

See above.

How to reproduce the issue: https://codesandbox.io/s/quizzical-firefly-oyxwn?file=/src/App.js

Open the console and see that component is initially rendered with appVersion: null.

Versions See reproduction. :^)

[travigd]

I appreciate your feedback, and I respectfully disagree. Your code snippet is a decent workaround but is also a fair amount of boilerplate. It also makes it hard to use hooks that depend on the data returned due to the early return rule.

const { data, loading } = useQuery(...);
if (loading) return null;
if (!data) throw new Error(...);

// Uh-oh, can't do this because of early return above
const foo = useFoo(data.bar);

One “solution” to that problem is allowing useFoo to take undefined, but that just starts to infect code like wildfire and is still just a workaround because data that is known synchronously isn’t returned synchronously. The workaround beyond that (which I do actually use in some places) is to have a presentational component that is rendered once all of the data is available, which I do in some places, but is even more boilerplate and redundant types I have to specify in my TS code. It feels very much like going back to the old style of Redux, which isn’t even recommended anymore (see edit at top).

I adopted Apollo to simplify my state management, and I’m simply advocating for a feature that I think would make it even better.

---

All that being said, I’d appreciate input from an Apollo contributor rather than disagreeing about the merits of a feature with a stranger. :^)

[travigd]

All valid points, but not my use case.

In particular, I’m putting a bit of data inside of Apollo just for simplicity and I’d rather it be available synchronously. I could do workarounds with state and context (or… god forbid… Redux), but I’d much rather be able to manage it all from inside Apollo. I don’t want to write fallbacks that I know I won’t need.