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

Update graphql dependency to graphql 15 #140

Closed
wants to merge 27 commits into from

Conversation

hagmic
Copy link

@hagmic hagmic commented May 21, 2020

This MR updates the graphql dependency to the production release of 15.0.0.

See: apollographql/apollo-client#6328

hwillson and others added 27 commits January 19, 2020 09:51
Adds `@apollo/client` and removes all other Apollo related packages
that are no longer needed.
`apollo-client`, `@apollo/react-hooks`, `@apollo/react-testing`,
`apollo-link`, `apollo-link-http`, `apollo-cache-inmemory`, and
`graphql-tag` references have all been replaced with `@apollo/client`.

A few important notes:

- This commit includes the removal of
  `final/client/src/pages/__tests__/__generated__/IsUserLoggedIn.ts`,
  which appears to have been added by codegen. This file isn't needed,
  and it's being picked up by Jest when trying to run tests, and
  leading to a test error (since it isn't a test file). I've removed
  the file for now, but we might want to also either update the
  `apollo:codegen` command to exclude this file from codegen, or
  add a custom create-react-app Jest override that excludes this
  file from testing.
- It looks like launch ID's are now `string`'s in the Typescript types
  instead of numbers, which means some of the existing tests were failing
  due to a mismatch of trying to use both numbers and strings for
  launch ID's in mocked responses. I'm not sure if the `string`
  launch ID type change was intentional, but I've adjusted the launch
  ID's in failing tests to be strings to make the tests pass.
Small refactoring prep step as we'll be replacing resolvers
completely with AC3's Type/Field Policy API.
Introduce the new Type/Field Policies API by handling `cartItems`
outside of the cache, using `makeLocalVar`. This is a stepping
stone commit that updates the local resolvers in place, but they
will eventually be removed.
This commit introduces the use of a reactive `makeLocalVar`
variable to track cart items, instead of using the cache
through local resolvers. Doing this reduces the need to make
`@client` based queries against the cache, and completely
removes the need to use local resolvers.
Stop writing/reading `isLoggedIn` directly from the cache, using
a `isLoggedInVar` created `makeLocalVar` variable instead. Note
that this commit introduces temporary redirects to update the
app to properly show a logged in / logged out state. Eventually
this won't be necessary as `makeLocalVar` changes will broadcast
and trigger the re-running of queries automatically, meaning
the logged in / logged out state will update automatically.
After cancelling a trip the cached user object still retained a
reference to the trip that was cancelled, making it look like
the user was still booked on that trip. This didn't cause any
issues when using the application as a manual `refetchQueries`
was being triggered, which in turn pulled new user details in from
the network, and overwrote the old trip data in the cache. This
is a good oppoprtunity to demonstrate how the new `cache.modify()`
API works by removing the manual `refetchQueries` call and instead
just removing the cancelled trip directly from the user object
in the cache, after the trip was cancelled.

Note that to accomplish this we need to persist the user's `id`
(so it can be used when looking up the current user object in the
cache). This tutorial was setup to persist the user token in
`localStorage`, so we're now also storing the user `id` in
`localStorage`. A better option would be to adjust the schema so
we can get the current user `id` back in the trip cancellation
response (and thereby avoiding `localStorage`), but for now this
is the easiest option (and the user `id` is not really the focus
of this tutorial).
When `makeLocalVar` is updated to broadcast, `refetchQueries`
will no longer be needed to refresh the cart. We'll use a
temporary redirect to simulate the behavior for now.
These changes demonstrate how to use the `merge` function to
combine incoming cache data with existing cache data. They
replace the need to use `updateQuery` after firing a `fetchMore`
to get more results.
Remove all user details from the cache when logging out,
using a combination of `cache.modify()` and `cache.gc()`.
When `makeLocalVar` is updated to broadcast, using `useState`
to trigger a re-render here won't be necessary.
The function name was changed in the most recent
`@apollo/client@beta`.
`@apollo/[email protected]` supports broadcasting watches
from `makeVar`, which means we're getting closer to having
`makeVar` changes propagate through the app reactively. Since
we're getting closer, we can now call
`client.queryManager.broadcastQueries()` manually (instead of
doing a redirect), to get the behavior we want. Again, this
step is temporary - we'll be able to drop this manual call
very soon.
This shows how `cache.evict()` works, and we're alreay showing
how `cache.modify()` works in another part of the application.
Also, using `evict` in this case is much more succinct.
Manually triggering `QueryManager.broadcastQueries()` is no
longer needed with recent version of the `@apollo/client`
beta.
Refactor the tutorial to use the new AC3 cache API
@hwillson hwillson force-pushed the apollo-client-3 branch 2 times, most recently from ae36116 to d1d900e Compare June 13, 2020 14:35
@hwillson hwillson closed this Jul 20, 2020
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

Successfully merging this pull request may close these issues.

3 participants