React refactorings

[brainkim]

This PR eliminates the XData class-based abstractions which were used to implement the React hooks, in favor of hooks which are more “idiomatic” to React. The old class-based abstractions generated an immense amount of mental overhead, insofar as it attempted to abstract over React hooks by defining two methods execute() and afterExecute() which are called by the hook body and in a useEffect() hook respectively.

This PR should make the following issues easier to fix:

• useLazyQuery polling? #5140
• Using useQuery with pollInterval triggers onCompleted only once #5531
• Query Functionality with onCompleted is broken in v3.0.0 release (CodeSandbox repro) #6636
• TypeError: undefined is not an object when calling refetch from useQuery hook #6816
• useLazyQuery doesn't work with cache-and-network fetch policy #7171
• useLazyQuery loading and networkStatus when call refetch. fetchMore send two requests #7243
• Random testing results when using useLazyQuery and useEffect #7388
• previousData is lost when useLazyQuery's executor is called #7396
• useLazyQuery run after component rerender #7484
• useLazyQuery: cannot read property 'subscribeToMore' of undefined when attempting to resubscribe #7543
• useQuery with fetchPolicy: 'standby' returns loading state as true when there is no loading happening #7564
• Calling refetch fires off a network request when skip is true #8270
• onCompleted gets called after loading state has been changed..  #8350
• onError and onCompleted callbacks do not work in useQuery hook #8313

[benjamn]

This is really exciting!

Could you rebase against the release-3.5 branch, so we can put out a beta release with these changes?

[benjamn]

Are these state updates automatically batched because they're in a useEffect callback?

[brainkim]

I’m not sure, but my guess is no. There are a lot of subtle timing changes which this PR inevitably produces as we refactor state calls.

[benjamn]

@brainkim Maybe let's use unstable_batchedUpdates then, just in case? Or are you saying it's important to preserve the timing of the separate updates?

[brainkim]

@benjamn
It is impossible to preserve the exact timings of the old React hooks implementation, insofar as it used a useReducer/forceUpdate pattern, which, among other things, would in many circumstances, cause state changes to be happen directly in the render function, which is apparently a bad thing to do (we still do it in useQuery just so some specific edge cases don’t produce confusing unit test results). And I’m still not sure what the effect of “batching” the two state updates would have, given that the result and observable are two independently updating pieces of state.

I’m not familiar with unstable_batchedUpdates. Have you adopted it somewhere in this codebase?

• What is availability of unstable_batchedUpdates across React versions?
• Is it okay that it seems to be defined on ReactDOM, when none of the hooks require the ReactDOM package previously, especially given that some of our poor users are using React Native?
• Is it a merely an optimization, or does it actually affect the logic of the hook?
• Would it hamper preact support?

[benjamn]

Are we losing this functionality, or is it no longer needed after the refactoring?

[brainkim]

I’m not sure; I’ll have to look into it. We don’t call side-effects from the render function for the most part anymore, except for certain edge cases where I could not get the tests working.

[brainkim]

@benjamn Can I get a review for this commit which would solve #8137

This last commit is failing some tests...

NEVER MIND I’M PUTTING IT IN A SEPARATE PR.