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

Simplified the MockedProvider #1882

Merged
merged 4 commits into from Apr 2, 2018

Conversation

Projects
None yet
3 participants
@excitement-engineer
Copy link
Collaborator

excitement-engineer commented Apr 2, 2018

This PR aims to simplify the usage of the MockedProvider.

Note, that the changes that I am proposing are breaking!

1. Remove removeTypename prop.

Whenever I am writing a test I want to simply be able to write

import { Query } from “./some_component”;

const mocks = [{
    request: {
         query: Query
    },
    result: someData
}]

renderer.create(
<MockedProvider mocks={mocks}>
   <Component />
</MockedProvider>
);

However, by default the MockedProvider adds typenames to everything in the cache. This caused the example above to fail and forces the user to write:

import { Query } from “./some_component”;


const mocks = [{
    request: {
         query: Query
    },
    result: someData
}]

renderer.create(
<MockedProvider mocks={mocks} removeTypename>
   <Component />
</MockedProvider>
);

This PR removes the removeTypename prop and simply forces the cache to not add typenames to documents it receives.

I hope that this change will simplify the usage of the MockedProvider and prevent users from having to worry about whether to remove typenames or not.

Are there any use-cases that I am missing by removing this prop? Would love to hear them. I couldn’t come up with a reason for this prop being there.

2. Remove the client prop

The MockedProvider allows the user to pass a custom client prop. However this client is passed straight to the the ApolloProvider. So I removed this prop and instead of letting the user do this:

<MockedProvider client={client} />

The user can use the normal ApolloProvider:

<ApolloProvider client={client} />

excitement-engineer and others added some commits Apr 2, 2018

James Baxley

@jbaxleyiii jbaxleyiii merged commit 884d81f into apollographql:master Apr 2, 2018

11 checks passed

CLA Author has signed the Meteor CLA.
Details
bundlesize ./dist/bundlesize.js: 9.84KB < maxSize 11KB (gzip)(same as master)
Details
ci/circleci: Browser Your tests passed on CircleCI!
Details
ci/circleci: Commonjs Your tests passed on CircleCI!
Details
ci/circleci: Filesize Your tests passed on CircleCI!
Details
ci/circleci: Linting Your tests passed on CircleCI!
Details
ci/circleci: Node.js 8 Your tests passed on CircleCI!
Details
ci/circleci: Node.js 9 Your tests passed on CircleCI!
Details
ci/circleci: Preact Your tests passed on CircleCI!
Details
ci/circleci: Server Your tests passed on CircleCI!
Details
ci/circleci: Typecheck Your tests passed on CircleCI!
Details
@rylanc

This comment has been minimized.

Copy link

rylanc commented Apr 25, 2018

I'm having trouble using fragments with this change.

When testing a component that uses fragments in its query, I'm getting the following warning from the HeuristicFragmentMatcher:

You're using fragments in your queries, but either don't have the addTypename:
  true option set in Apollo Client, or you are trying to write a fragment to the store without the __typename.
   Please turn on the addTypename option and include __typename when writing fragments so that Apollo Client
   can accurately match fragments.

Even if I add __typename, I still get the warning (I'm guessing this is because the cache isn't storing the typename, since it wasn't requested). Am I missing something here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment