Update react-apollo to the latest version 🚀

[greenkeeper[bot]]

Version 2.1.9 of react-apollo was just published.

Dependency	react-apollo
Current Version	1.4.16
Type	dependency

The version 2.1.9 is not covered by your current version range.

If you don’t accept this pull request, your project will work just like it did before. However, you might be missing out on a bunch of new features, fixes and/or performance improvements from the dependency update.

It might be worth looking into these changes and trying to get this project onto the latest version of react-apollo.

If you have a solid test suite and good coverage, a passing build is a strong indicator that you can take advantage of these changes directly by merging the proposed change into your project. If the build fails or you don’t have such unconditional trust in your tests, this branch is a great starting point for you to work on the update.

---

FAQ and help

There is a collection of [frequently asked questions](https://greenkeeper.io/faq.html). If those don’t help, you can always [ask the humans behind Greenkeeper](https://github.com/greenkeeperio/greenkeeper/issues/new).

---

Your Greenkeeper bot :palm_tree:

[greenkeeper[bot]]

Version 2.1.11 just got published.

Update to this version instead 🚀

[greenkeeper[bot]]

• The dependency react-apollo was updated from 1.4.16 to 2.2.0.

Update to this version instead 🚀

Release Notes for 2.2.0

2.2.0 (September 26, 2018)

New Functionality

• The <Subscription /> component now allows the registration of a callback
  function, that will be triggered each time the component receives data. The
  callback options object param consists of the current Apollo Client
  instance in client, and the received subscription data in
  subscriptionData.
  @jedwards1211 in #1966
• The graphql options object is no longer mutated, when calculating
  variables from props. This now prevents an issue where components created
  with graphql were not having their query variables updated properly, when
  props changed.
  @ksmth in #1968
• When a query failed on the first result, the query result data was being
  returned as undefined. This behavior has been changed so that data is
  returned as an empty object. This makes checking for data (e.g.
  instead of data && data.user you can just check data.user) and
  destructring (e.g. { data: { user } }) easier. Note: this could
  potentially hurt applications that are relying on a falsey check of data
  to see if any query errors have occurred. A better (and supported) way to
  check for errors is to use the result errors property.
  @TLadd in #1983
• Avoid importing lodash directly.
  @shahyar in #2045
• Make sure <Subscription />, <Query /> & <Mutation /> all support
  using an Apollo Client instance configured in the context or via
  props.
  @quentin- in #1956
• Adjust <Query /> onCompleted and onError callbacks to be triggered
  via the componentDidUpdate lifecycle method. This ensures these callbacks
  can be used when data is fetched over the network, and when data is
  fetched from the local store (previsouly these callbacks were only being
  triggered when data was fetched over the network).
  @olistic in #2190
• Import lodash/flowRight using ES import to allow for treeshaking.
  @Pajn in #2332
• Added a new partialRefetch prop (false by default).
  When a Query component is mounted, and a mutation is executed
  that returns the same ID as the mounted Query, but has less
  fields in its result, Apollo Client's QueryManager returns the
  data as an empty Object since a hit can't be found in the cache.
  This can lead to application errors when the UI elements rendered by
  the original Query component are expecting certain data values to
  exist, and they're all of a sudden stripped away. The recommended way to
  handle this is to use the mutations update prop to reconcile the mutation
  result with the data in the cache, getting everything into the expected
  state. This can definitely be a cumbersome process however, so to help
  address this the partialRefetch prop can be used to automatically
  refetch the original query and update the cache.
  @steelbrain in #2003

Bug Fixes

• When the Query skip prop is set to true, make sure the render prop
  loading param is set to false, since we're not actually loading
  anything.
  @edorivai in #1916
• Fixed a regression where variables passed in graphql HOC options were
  not merged with mutation variables.
  @samginn in #2216

Testing

• Added an example app that shows how to test mutations.
  @excitement-engineer in #1998
• Allow a custom cache object to be passed into the test-utils
  MockedProvider.
  @palmfjord in #2254
• Make the MockedProvider mocks prop read only.
  @amacleay in #2284

Typescript

• Improved TypeScript Typings:
  Deprecated MutationFunc in favor of MutationFn.
  Added missing onCompleted and onError callbacks to MutationOpts.
  @danilobuerger in #2322
• Remove duplicate FetchMoreOptions and FetchMoreQueryOptions types, and
  instead import them from Apollo Client.
  @skovy in #2281
• Type changes for the graphql HOC options.skip property.
  @jameslaneconkling in #2208
• Typescript: use Partial<TData> instead of TData | {}, for the
  QueryResult data property.
  @tgriesser in #2313

Infrastructure

• No longer building against Node 9
  @hwillson in #2404

[greenkeeper[bot]]

• The dependency react-apollo was updated from 1.4.16 to 2.2.1.

Update to this version instead 🚀

[greenkeeper[bot]]

• The dependency react-apollo was updated from 1.4.16 to 2.2.2.

Update to this version instead 🚀

Release Notes for 2.2.2

2.2.2 (September 28, 2018)

• When using React.createContext and SSR, we now make sure the context
  provider value is reset to the previous value it had after its children are
  walked.
  @mitchellhamilton in #2304
• Revert:
  When a query failed on the first result, the query result data was being
  returned as undefined. This behavior has been changed so that data is
  returned as an empty object. This makes checking for data (e.g.
  instead of data && data.user you can just check data.user) and
  destructring (e.g. { data: { user } }) easier. Note: this could
  potentially hurt applications that are relying on a falsey check of data
  to see if any query errors have occurred. A better (and supported) way to
  check for errors is to use the result errors property.
  #1983

[greenkeeper[bot]]

• The dependency react-apollo was updated from 1.4.16 to 2.2.3.

Update to this version instead 🚀

[greenkeeper[bot]]

• The dependency react-apollo was updated from 1.4.16 to 2.2.4.

Update to this version instead 🚀