Skip to content
This repository has been archived by the owner on Apr 13, 2023. It is now read-only.

Query: Fix data is undefined on error #1983

Merged
merged 8 commits into from
Aug 22, 2018

Conversation

TLadd
Copy link
Contributor

@TLadd TLadd commented May 15, 2018

If the query fails on the first result, the query result data was being returned as undefined
Now this case will result in data being an empty object

Fixes #1977

If the query fails on the first result, the query result data was being returned as undefined
Now this case will result in data being an empty object
@apollo-cla
Copy link

@TLadd: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Meteor Contributor Agreement here: https://contribute.meteor.com/

@hwillson hwillson self-assigned this Jun 20, 2018
@hwillson
Copy link
Member

Thanks for working on this @TLadd! I agree with your assessment that the data result should be an empty object. Your changes look great, but I'm a little concerned that this is a breaking change. Some people have likely noticed that data is undefined when there is an error, and are leveraging that fact in their error handling logic. Rolling this change out could affect that since their !data checks will now fail. Hmmm - we'll need to think about this a bit more ... 🤔.

@TLadd
Copy link
Contributor Author

TLadd commented Jun 20, 2018

Using !data to check for errors would be pretty brittle anyways, since it only happens if there isn't already a previous result. Certainly could be possible that there is code out there depending on it though.

@alamothe
Copy link

The typings say data is either TData or undefined - never empty object:

data: TData | undefined;

So which one is it?

Copy link
Member

@hwillson hwillson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this @TLadd - I've added a note regarding the potential issues around data now always being an object. This is a good change though, so hopefully that's enough ... 🤞. LGTM!

@hwillson hwillson merged commit 27cc028 into apollographql:master Aug 22, 2018
@TLadd
Copy link
Contributor Author

TLadd commented Aug 22, 2018

Thanks for getting it across the finish line!

@@ -94,7 +94,7 @@ export interface QueryResult<TData = any, TVariables = OperationVariables>
// I'm aware of. So intead we enforce checking for data
// like so result.data!.user. This tells TS to use TData
// XXX is there a better way to do this?
data: TData | undefined;
data: TData | {};

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🥇

williamboman added a commit to williamboman/react-apollo that referenced this pull request Aug 29, 2018
* master: (112 commits)
  chore(deps): update dependency danger to v3.8.8
  chore(deps): update dependency enzyme to v3.5.0
  chore(deps): update dependency apollo-client to v2.4.1
  chore(deps): update dependency apollo-cache-inmemory to v1.2.9
  chore(deps): update dependency apollo-cache to v1.1.16
  chore(deps): update dependency @types/react to v16.4.12
  chore(deps): update dependency rollup-plugin-commonjs to v9.1.6
  chore(deps): update dependency @types/node to v10.9.2
  chore(deps): update dependency react-scripts to v1.1.5
  chore(deps): update dependency ts-jest to v23.1.4
  Avoid importing lodash directly (apollographql#2045)
  type graphql.options.skip HOC property (apollographql#2208)
  Replace duplicate ObservableQueryFields types defined in apollo-client (apollographql#2281)
  Make mock links mock parameter readonly (apollographql#2284)
  test-utils: allow passing a custom cache object to `MockedProvider` (apollographql#2254)
  Query: Fix data is undefined on error (apollographql#1983)
  Don't mutate options object when calculating variables from props (apollographql#1968)
  Feature: add onSubscriptionData callback to <Subscription> (apollographql#1966)
  Changelog update
  Example of a mutation including tests (apollographql#1998)
  ...
@danilobuerger
Copy link
Contributor

@hwillson @TLadd this should be reverted, see #2424 . This PR promised:

instead of `data && data.user` you can just check `data.user`

instead it made things worse. Now a type guard is required to discriminate between TData and {}.

@tomitrescak
Copy link

Yes please, revert this change. It makes this VERY difficult to use in Typescript ;(

@hwillson
Copy link
Member

@danilobuerger @tomitrescak Rolling back and we'll have a new release out this morning - thanks!

@kallaspriit
Copy link

So what ise the solution? Also the TypeScript example does not seem to work (any more) and it uses the old method of:

examples/typescript/src/Character.tsx

if (!data) return <div>no data</div>;

@hwillson
Copy link
Member

@kallaspriit For now we'll roll this back, then we'll come up with another solution afterwards (we really didn't want breaking changes in this release). The examples are in the process of being updated and will be available shortly. We're also going to wire the example app tests into CI, to help keep them healthy.

@kallaspriit
Copy link

Wrote my comment seconds before seeing your reply. Sounds great :)

hwillson added a commit that referenced this pull request Sep 28, 2018
hwillson added a commit that referenced this pull request Sep 28, 2018
* Revert 27cc028 (#1983)

* Changelog adjustments

* Grammer fix

* Preserve some test changes
hwillson added a commit that referenced this pull request Sep 28, 2018
#1983 introduced breaking changes that were missed by the current test suite. These changes were rolled back in #2432, but this test change should help prevent this same issue from happening
again.

Reference: #2424
@fenok
Copy link

fenok commented Nov 15, 2018

This should be re-reverted. #2424 can be fixed by replacing

data: TData | {};

with

data: Partial<TData>;

Which is essentially the same, but don't break types.

@tomitrescak
Copy link

@fenok that is not true. Those are fundamentally different concepts and would validate very differently. Your example also allows partial objects, while the former allows only complete objects or empty objects

@fenok
Copy link

fenok commented Nov 15, 2018

Valid point, I was trapped in my partial results world. I also found that the idea of Partial has already been discussed and rejected. Sorry for the interruption 😅

@evenfrost
Copy link

So, what's the current status of it?

@lucasconstantino
Copy link

lucasconstantino commented Apr 7, 2019

@evenfrost it was changed, but it's changed back from the previous change, which actually changed to keep things the same they were before the change, so that we don't really change what was changed before.

Edit: jokes apart, current state is:

data might be undefined if query errored and cache has no previous valid data.

@IanVS
Copy link

IanVS commented Apr 19, 2019

Thank you so much for clarifying, @lucasconstantino. I was getting really lost in trying to understand where things stand. 💫

Note, I just discovered that data can also be undefined when using components and setting skip={true} if there is no cache. This bit me because in the older hoc-based approach, the config.props function wasn't called at all, and turns out I was relying on that in one case. Just leaving a note here in case it's helpful for others.

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

Successfully merging this pull request may close these issues.

If initial Query errors, data is undefined instead of empty object