Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

updating from v0.4.5 to v0.5.0 breaks query #192

Open
barbalex opened this issue Jul 16, 2019 · 2 comments
Open

updating from v0.4.5 to v0.5.0 breaks query #192

barbalex opened this issue Jul 16, 2019 · 2 comments

Comments

@barbalex
Copy link

barbalex commented Jul 16, 2019

This query: https://github.com/barbalex/vermehrung/blob/0a7bc911e9d5e5dcd8493e4c5e091833802e99d6/src/components/TreeContainer/index.js#L41
works fine in v0.4.5.

It breaks in v0.5.0 with this error, before the query is run:

index.js:112 Uncaught TypeError: Cannot convert undefined or null to object
    at Function.keys (<anonymous>)
    at TreeContainer (index.js:112)
    at index.module.js:205
    at index.module.js:183
    at trackDerivedFunction (mobx.module.js:1154)
    at Reaction../node_modules/mobx/lib/mobx.module.js.Reaction.track (mobx.module.js:1694)
    at useObserver (index.module.js:181)
    at wrappedComponent (index.module.js:205)
    at renderWithHooks (react-dom.development.js:12939)
    at updateFunctionComponent (react-dom.development.js:14628)
    at updateSimpleMemoComponent (react-dom.development.js:14574)
    at updateMemoComponent (react-dom.development.js:14493)
    at beginWork (react-dom.development.js:15690)
    at performUnitOfWork (react-dom.development.js:19313)
    at workLoop (react-dom.development.js:19353)
    at HTMLUnknownElement.callCallback (react-dom.development.js:150)
    at Object.invokeGuardedCallbackDev (react-dom.development.js:200)
    at invokeGuardedCallback (react-dom.development.js:257)
    at replayUnitOfWork (react-dom.development.js:18579)
    at renderRoot (react-dom.development.js:19469)
    at performWorkOnRoot (react-dom.development.js:20343)
    at performWork (react-dom.development.js:20255)
    at performSyncWork (react-dom.development.js:20229)
    at requestWork (react-dom.development.js:20098)
    at scheduleWork (react-dom.development.js:19912)
    at dispatchAction (react-dom.development.js:13600)
    at Vermehrung.js:72
    at _callee$ (auth.js:76)
    at tryCatch (runtime.js:45)
    at Generator.invoke [as _invoke] (runtime.js:271)
    at Generator.prototype.<computed> [as next] (runtime.js:97)
    at asyncGeneratorStep (asyncToGenerator.js:3)
    at _next (asyncToGenerator.js:25)
    at asyncToGenerator.js:32
    at new Promise (<anonymous>)
    at asyncToGenerator.js:21
    at auth.js:51
    at auth0.min.esm.js:8
    at callback (auth0.min.esm.js:8)
    at auth0.min.esm.js:8
    at F../node_modules/auth0-js/dist/auth0.min.esm.js.F.validateAccessToken (auth0.min.esm.js:8)
    at auth0.min.esm.js:8
    at auth0.min.esm.js:8
    at auth0.min.esm.js:8
    at auth0.min.esm.js:8
    at auth0.min.esm.js:8

When the error occurs the query has not been run, judging by the network panel. The return value from the query is:

data: undefined
error: undefined
loading: true

Seems that data was not undefined before? Because undefined breaks my next line of code:

if (Object.keys(data).length > 0) {
    setNodes(buildNodes({ store, data, loading }))
}

When setting it to:

if (!loading && Object.keys(data).length > 0) {
    setNodes(buildNodes({ store, data, loading }))
}

it works again.

Yep, if I set react-apollo-hooks back to v0.4.5 the output of my console.log is:

data: {}
error: undefined
loading: true

So data used to return as an empty object and is now returned as undefined.

Don't know if returning an empty object was non-standard behaviour?

@darrikonn
Copy link

darrikonn commented Jul 19, 2019

These are braking changes!
If this is the expected behaviour, then the major version should have been bumped.
I normally destruct the data object for "cleaner" code:

const {data: {human}} = useQuery(...);

Any news on this?

@barbalex
Copy link
Author

@darrikonn Before version 1.0.0 any version may break, as far as I know. But if this is really a breaking change that should be mentioned in the release notes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants