profile
viewpoint
Ben Newman benjamn Meteor/Apollo (formerly: Facebook/Instagram, Quora, Mozilla) New York City http://twitter.com/benjamn

benjamn/ast-types 724

Esprima-compatible implementation of the Mozilla JS Parser API

amasad/debugjs 183

[Experimental] Lightweight JavaScript VM and stepping debugger in JavaScript

benjamn/arson 154

Efficient encoder and decoder for arbitrary objects

amasad/debugjs.com 95

Debug your JavaScript in the browser

benjamn/ast-path 5

Library for traversing syntax trees with easy access to an unbroken chain of parent references

benjamn/brigade 4

Bucket brigade for bundling browser modules

benjamn/brane 3

Efficient inter-Worker messaging with fantastic TypeScript support

benjamn/arduino-wearables 2

A collection of code powering wearable Arduino projects

benjamn/apollo-client 1

:rocket: A fully-featured, production ready caching GraphQL client for every UI framework and GraphQL server

benjamn/apollo-server 1

GraphQL server for Express, Connect, HAPI and Koa, written in TypeScript

pull request commentapollographql/apollo-client

feature: added support for automatic type inference with `typed-document-node`

Ok, these changes have been released in @apollo/client@3.2.0-beta.0! Please give this functionality a try, especially if you're already using GraphQL Codegen in your project. You can follow the progress of v3.2.0 in the Release 3.2.0 pull request.

Thanks again to @dotansimha for this amazing contribution!

dotansimha

comment created time in 6 hours

push eventapollographql/apollo-client

Ben Newman

commit sha c689897ca52382cef8dbf9454ec9d0911636da3b

Add beta tag to npm deploy script.

view details

Ben Newman

commit sha 15d6324dae263822d7aec8f667aad452174bd0b2

Mention PR #6720 in CHANGELOG.md.

view details

Ben Newman

commit sha b883fc6c35fffdbe2159757be620b8fa481335dc

Bump @apollo/client npm version to 3.2.0-beta.0.

view details

push time in 6 hours

PR opened apollographql/apollo-client

Release 3.2.0

This PR will serve to collect significant new features, deprecation warnings, and minor changes that we intend to release in @apollo/client@3.2.0.

So far the list includes:

  • [ ] Support for TypedDocumentNode<Data, Variables>, thanks to @dotansimha in #6720.

Until v3.2.0 is released, we can continue merging smaller changes into master and releasing them, without worrying about larger changes on the release-3.2 branch.

+625 -260

0 comment

23 changed files

pr created time in 7 hours

push eventapollographql/apollo-client

Dotan Simha

commit sha 7112d0330605f5f40c2093708bf188824160ee56

feature: added support for automatic type inference with typed-document-node

view details

Dotan Simha

commit sha 36dc45b460abbd2e772a5f832a2e25af0261f146

update typed-document-node to 1.0.0

view details

Dotan Simha

commit sha 9614c65aeda6e3a724446571f0ffd9cd43abfe58

update version, move to devDependency, added re-export

view details

Dotan Simha

commit sha c550dc37ed242cbe64f63bf6c80f442411debd34

update lockfile

view details

Ben Newman

commit sha af18c78494344934209051864b4e811f6098df36

Move TypedDocumentNode to src/core/types.ts.

view details

Ben Newman

commit sha 2e0c72584e4f2ac583d98579625ca6d40387b9e9

More tests of TypedDocumentNode and cache.{read,write}{Query,Fragment}.

view details

Ben Newman

commit sha 02528dd75102ab5a174f2ff075ccca1f4718db5b

Move @graphql-typed-document-node/core back to dependencies. When I `npm pack`ed @apollo/client and `npm install`ed it into a test application, I found it simpler if @apollo/client depended directly on @graphql-typed-document-node/core, so that I didn't have to install that package explicitly in the test application. We already get complaints from folks who don't realize they need to install the graphql package (a peer dependency of @apollo/client), so I can easily imagine how much confusion would be caused by needing to explicitly install graphql-typed-document-node/core, too. @dotansimha Enjoy that boost in download counts!

view details

Ben Newman

commit sha 081e604d7dbabcd92bf8fe48b7e18e37ab8ff2ec

Merge pull request #6720 from dotansimha/feature/typed-document-node feature: added support for automatic type inference with `typed-document-node`

view details

push time in 7 hours

PR merged apollographql/apollo-client

feature: added support for automatic type inference with `typed-document-node` :bulb: idea ⛑ TypeScript 🛠 tooling 🧞‍♂️ enhancement

Hi!

This PR adds support for typed-document-node interface as part of the core API and React support.

The idea behind it is to have TData and TVariables burnt into the DocumentNode, and allow TypeScript to automatically infer the result type and variables type, based on the query object passed.

TL;DR

  1. TypeScript types can be burnt into DocumentNode instead of being separated, and specified in each use.
  2. No need to specify any types manually, it's being defined once when TypedDocumentNode is declared, and then inferred automatically by TS.
  3. Simplifies integration of TypeScript and GraphQL.
  4. I also wrote an article with some examples here

Overview

It makes integration of GraphQL frontend consumers and TypeScript much easier, since types are located "inside" the DocumentNode. This simplifies work for developers, since they don't need to manually specify TData or TVariables in order to have typings for their operations, and the types are being defined within the operation itself.

It can be used with manual typings, but the core goal is to use GraphQL Codegen, in order to pre-compile .graphql files into DocumentNode, and generate and burn in the types, and produce TypedDocumentNode<TData, TVariables> that can be used.

Changes in this PR

This PR is not breaking any API, since it uses TData when possible (I added it to some interfaces where, as 2nd generic, with default any, so all APIs remains the same). Logic isn't effected at all, since it's all types. So does bundle-size, since the @graphql-typed-document-node/core package just contains types, and not code.

I added a unit tests, just for typings test, if something will break, the TS diagnostics will kick in and fail the test. The other alternative is to build a TS.Program and compile code to do tests, like done here, I can add tests like those, but it might be an overkill.

Code Examples

Without typed-document-node:

type Data {
  // ...
}

type Variables {
  // ...
}

const query: DocumentNode = gql` ... `;
// types must be specified manually
const result = client.query<Data, Variables>({ query, variables: { ... } });
// must specify types again
const moreData = client.readQuery<Data, Variables>({ query });

This can be misused, since developers can use SomeOtherData or SomeOtherVariables types incorrectly, and it will cause TS to pass build, but fail in runtime, since you might expect different results/variables.

With typed-document-node:

type Data {
  // ...
}

type Variables {
  // ...
}

const query: TypedDocumentNode<Data, Variables> = gql` ... `;

// Just by passing `query`, `variables` and result will be typed, without manually specify types
const result = client.query({ query, variables: { ... } });

// This is also typed, no need to repeat types
const moreData = client.readQuery({ query });
+625 -260

4 comments

23 changed files

dotansimha

pr closed time in 7 hours

create barnchapollographql/apollo-client

branch : release-3.2

created branch time in 7 hours

push eventdotansimha/apollo-client

Dotan Simha

commit sha 7112d0330605f5f40c2093708bf188824160ee56

feature: added support for automatic type inference with typed-document-node

view details

Dotan Simha

commit sha 36dc45b460abbd2e772a5f832a2e25af0261f146

update typed-document-node to 1.0.0

view details

Dotan Simha

commit sha 9614c65aeda6e3a724446571f0ffd9cd43abfe58

update version, move to devDependency, added re-export

view details

Dotan Simha

commit sha c550dc37ed242cbe64f63bf6c80f442411debd34

update lockfile

view details

Ben Newman

commit sha af18c78494344934209051864b4e811f6098df36

Move TypedDocumentNode to src/core/types.ts.

view details

Ben Newman

commit sha 2e0c72584e4f2ac583d98579625ca6d40387b9e9

More tests of TypedDocumentNode and cache.{read,write}{Query,Fragment}.

view details

Ben Newman

commit sha 02528dd75102ab5a174f2ff075ccca1f4718db5b

Move @graphql-typed-document-node/core back to dependencies. When I `npm pack`ed @apollo/client and `npm install`ed it into a test application, I found it simpler if @apollo/client depended directly on @graphql-typed-document-node/core, so that I didn't have to install that package explicitly in the test application. We already get complaints from folks who don't realize they need to install the graphql package (a peer dependency of @apollo/client), so I can easily imagine how much confusion would be caused by needing to explicitly install graphql-typed-document-node/core, too. @dotansimha Enjoy that boost in download counts!

view details

push time in 7 hours

issue commentapollographql/apollo-client

Infinite Loop using graphql.macro loader inline after upgradring from 3.0.2 to 3.1.2

this was an edge-case where we needed to load 'random' non-predefined queries during runtime

Totally reasonable, then!

Using different queries each time is more of an issue for the performance of repeated cache reads. I don't think it's the reason for the infinite loop, since useQuery should be able to use the same query ID each time you call useQuery from the same component (and the query ID is not sensitive to the exact query object reference). Instead, I think the fetchPolicy change in v3.1.0 is the primary source of this issue, so I'm glad to hear that nextFetchPolicy helps.

ivoiv

comment created time in 10 hours

issue commentapollographql/apollo-client

Wrong response when parsed by apollo

@jmsunseri The way to make Apollo smarter is to tell the InMemoryCache how to compute an ID for your objects, using keyFields or dataIdFromObject. This allows object fields to be safely merged, when (and only when) object identities match, which is exactly what you're saying you want.

Object identity is fundamentally an application-level concern, so it's not possible/appropriate for Apollo Client to pretend that objects with unknown identities might be the same object. Identity is something you (the application developer) must specify, using the tools that we've given you. The good news is that you only have to capture this information in one place, in the options you pass to the InMemoryCache constructor.

charles-mathieus-jomedia

comment created time in 13 hours

issue commentapollographql/apollo-client

🐛 useQuery doesn't work when there is both a @client directive and a normal query together

@buzinas Ok, great! Feel free to keep asking questions here if anything seems wrong/confusing.

buzinas

comment created time in 14 hours

issue commentapollographql/apollo-client

Infinite Loop using graphql.macro loader inline after upgradring from 3.0.2 to 3.1.2

@ivoiv Given the version range and your use of network-only, I'm guessing this is a consequence of #6712. Can you try the following code?

useQuery(query, {
  fetchPolicy: "network-only",
  nextFetchPolicy: "cache-first",
})

More generally, I think it's actually a good idea to declare your queries outside of your components, so that you don't end up reparsing/recreating the query every time the component renders. The specific DocumentNode object reference matters for some of the internal caching that we do, so pumping fresh (!==) objects into useQuery can have negative performance consequences.

ivoiv

comment created time in 14 hours

CommitCommentEvent

Pull request review commentapollographql/apollo-client-devtools

[WIP] Reconfigure data flow

+interface Message {+  to?: string+  message?: string+  payload?: any+}++interface CustomEventListener {+  (evt: CustomEvent): void;+}++class Relay extends EventTarget {+  private connections = new Map<string, (event: CustomEvent<Message>) => ReturnType<CustomEventListener>>();++  constructor() {+    super();+  }

If a constructor just calls super with the same arguments, you probably don't need to define a constructor method. However, if you specifically want to make sure it's impossible to pass arguments to the EventTarget constructor, this code will do that.

jcreighton

comment created time in a day

Pull request review commentapollographql/apollo-client-devtools

[WIP] Reconfigure data flow

+interface Message {+  to?: string+  message?: string+  payload?: any+}++interface CustomEventListener {+  (evt: CustomEvent): void;+}
type CustomEventListener = (event: CustomEvent) => void;

TypeScript has dedicated syntax for function types, though the interface style can be useful if you need to define other properties on the function.

jcreighton

comment created time in a day

push eventdminkovsky/apollo-client

renovate[bot]

commit sha 9af70a0bc7d0e2e8cdfaff13d6d25a0c4d49138a

chore(deps): update dependency @babel/parser to v7.11.0 (#6761) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha ca6c368109ce11a1cdd8952aabe882501ffa6531

chore(deps): update dependency jest to v26.2.2 (#6703) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha 64f7041e59ebecf9baa947f82bc5a9ada63d6a91

chore(deps): update dependency @types/node to v14.0.27 (#6705) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha dbeaacaedc3fbad0a186115a4a15d5e7107a19a6

chore(deps): update dependency rxjs to v6.6.2 (#6763) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha faf264bd9287718d24ea0589eebab3834e9a6d0f

chore(deps): update dependency ts-jest to v26.1.4 (#6764) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

renovate[bot]

commit sha 8209d4f91f0893973dc4a738ce16f67851169124

chore(deps): update dependency jest-junit to v11.1.0 (#6762) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

Dmitry Minkovsky

commit sha ac029f35de55ebbfcae8f5d876fa991ad5bc19b7

Add jscodeshift transform for v2->v3 migration

view details

Dmitry Minkovsky

commit sha 20ee098e1e6aa5756a9d4302f8fdcfb8dce6b385

Extracted common code and added remove `apollo-link` imports

view details

Jenn Creighton

commit sha 9da699b1303ca6c1930b6790fb5d72412bddf217

renameImport

view details

Jenn Creighton

commit sha 700f1b442c67256b3a602fd769b01e56f12f9935

move all specifiers unless explicitly noted

view details

Jenn Creighton

commit sha ce03c19187330ae4927d65491810bd08569a2562

modify jscodeshift to migrate 2 to 3

view details

Jenn Creighton

commit sha a3c5c7fdfb417933dc33cc86283f5a5b9400f737

move to src/utilities/codemods

view details

Jenn Creighton

commit sha d4f54b7b34f3539c62229253411855aecd513bdc

create apollo client import if there is none

view details

Jenn Creighton

commit sha fc54af5e5003c826d22a240c71702fe5aefd4516

Update src/utilities/codemods/jscodeshift-migrate-2-to-3.js Co-authored-by: Ben Newman <ben@benjamn.com>

view details

Jenn Creighton

commit sha ea22a22cd92d9dabd8b66e375000f7b73a19fbb8

move all specifiers to new import; check for v3 import of apollo client first

view details

Jenn Creighton

commit sha c616e3b6ea954a33974be6d209596295140c4688

rename apollo-link-* imports

view details

Jenn Creighton

commit sha d726d0b433d80933fe59efa70863b8f07b8f1cad

handle default imports

view details

Ben Newman

commit sha 4a780955eb964fa920de3b2da5f879f7c44aade5

Rename default specifier for apollo-link-schema, too.

view details

Ben Newman

commit sha f7a39ce78248158c741c1028f5857327ead27529

Use renameDefaultSpecifier to rename { default as Foo } imports. Default exports can be imported by name: import { default as Client } from "apollo-client" which is equivalent to import Client from "apollo-client" With this commit, both of these styles to get transformed to import { ApolloClient as Client } from "@apollo/client"

view details

Ben Newman

commit sha 2df1876fab3f579b0a3f08ebf6f3d982b8fe9bca

Add some example files to demonstrate the transform. Ideally we would have actual input/output tests, but for these examples seem like a good start.

view details

push time in a day

push eventdminkovsky/apollo-client

Renovate Bot

commit sha 49e2b65e643fbbfc09e70862f0154047e0ce4d44

chore(deps): update dependency gatsby to v2.24.23

view details

hwillson

commit sha c0ec90d9f8be521e1c1cb678002ecc209381da4e

Avoid making network requests when skip is true When skip is set to true but other updated options have been passed into `useQuery` (like updated variables), `useQuery` will still make a network request, even though it will skip the handling of the response. This commit makes sure `useQuery` doesn't make unnecessary `skip` network requests. Fixes #6670 Fixes #6190 Fixes #6572

view details

Hugh Willson

commit sha 3a65ed4837e8d380790a31fd9b09613b89da6876

Merge pull request #6752 from apollographql/issue-6670 Avoid making network requests when skip is true

view details

Ben Newman

commit sha cf1d2e7128d84636ba6dab9ae5c66dcc62ea8db1

Mention PR #6375 in CHANGELOG.md.

view details

Ben Newman

commit sha e30f12221928a380b435c7ddf00a304753ac03cb

Bump @apollo/client npm version to 3.1.2.

view details

Dmitry Minkovsky

commit sha 69d5f650ac4dee5cbcf208219bcaec2bbea80b64

Add jscodeshift transform for v2->v3 migration

view details

Dmitry Minkovsky

commit sha 32791ea85b5e17a2e21552ad8326ad6f67b23a6f

Extracted common code and added remove `apollo-link` imports

view details

Jenn Creighton

commit sha f849b0cb3550182dd89d3b9ae27c7e5af8b67a77

renameImport

view details

Jenn Creighton

commit sha 46f6715c8aff585866ce32ba654cc4de467ecc95

move all specifiers unless explicitly noted

view details

Jenn Creighton

commit sha 4f5e7e439b33a32264ffb80846e0b4e4d0d95f16

modify jscodeshift to migrate 2 to 3

view details

Jenn Creighton

commit sha 4c644a73f97fd352eb4008ffd5269883f6ede8d5

move to src/utilities/codemods

view details

Jenn Creighton

commit sha 2b942b3dfa91c0c3ef4f98c0cceb21f4942d9329

create apollo client import if there is none

view details

Jenn Creighton

commit sha 9959d05f45c329f26dd62249b2c9fb57e13b33ab

Update src/utilities/codemods/jscodeshift-migrate-2-to-3.js Co-authored-by: Ben Newman <ben@benjamn.com>

view details

Jenn Creighton

commit sha b767b2de808d078cf60fd061ca1f73cbaeae1e65

move all specifiers to new import; check for v3 import of apollo client first

view details

Jenn Creighton

commit sha 3eed27fff98bd4c638cbe477f27e3f0923c198fa

rename apollo-link-* imports

view details

Jenn Creighton

commit sha c0073f9981617cf9c141d248809f79582962e8b2

handle default imports

view details

Ben Newman

commit sha cc723dde937b4900f244fc7ef98700462f7a5539

Rename default specifier for apollo-link-schema, too.

view details

Ben Newman

commit sha 8b05f57a55d36ffc35e041a9339d99e376622b1a

Use renameDefaultSpecifier to rename { default as Foo } imports. Default exports can be imported by name: import { default as Client } from "apollo-client" which is equivalent to import Client from "apollo-client" With this commit, both of these styles to get transformed to import { ApolloClient as Client } from "@apollo/client"

view details

Ben Newman

commit sha cfa652f8e71a028157b42939ec4da400fd55f7f5

Add some example files to demonstrate the transform. Ideally we would have actual input/output tests, but for these examples seem like a good start.

view details

Ben Newman

commit sha a8a39fa8247bab9828966a517d81fa93036c763d

Fix old link package naming convention.

view details

push time in a day

issue commentapollographql/apollo-client

Query Functionality with `onCompleted` is broken in v3.0.0 release (CodeSandbox repro)

Those of you having problems with cache-and-network or network-only making unwanted network requests (especially if cache-first seems to fix things), please read this comment about the new options.nextFetchPolicy option introduced in v3.1.0: https://github.com/apollographql/apollo-client/issues/6760#issuecomment-668188727

3nvi

comment created time in a day

delete branch apollographql/apollo-client

delete branch : renovate/jest-junit-11.x

delete time in a day

push eventapollographql/apollo-client

renovate[bot]

commit sha 8209d4f91f0893973dc4a738ce16f67851169124

chore(deps): update dependency jest-junit to v11.1.0 (#6762) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

push time in a day

PR merged apollographql/apollo-client

chore(deps): update dependency jest-junit to v11.1.0 dependencies

This PR contains the following updates:

Package Type Update Change
jest-junit devDependencies minor 11.0.1 -> 11.1.0

Release Notes

<details> <summary>jest-community/jest-junit</summary>

v11.1.0

Compare Source

Added suitename support to classNameTemplate by @​dtom90 #​138

</details>


Renovate configuration

:date: Schedule: "every weekend" in timezone America/Los_Angeles.

:vertical_traffic_light: Automerge: Enabled.

:recycle: Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+4 -4

0 comment

2 changed files

renovate[bot]

pr closed time in a day

delete branch apollographql/apollo-client

delete branch : renovate/ts-jest-26.x

delete time in a day

push eventapollographql/apollo-client

renovate[bot]

commit sha faf264bd9287718d24ea0589eebab3834e9a6d0f

chore(deps): update dependency ts-jest to v26.1.4 (#6764) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

push time in a day

PR merged apollographql/apollo-client

chore(deps): update dependency ts-jest to v26.1.4 dependencies

This PR contains the following updates:

Package Type Update Change
ts-jest (source) devDependencies patch 26.1.3 -> 26.1.4

Release Notes

<details> <summary>kulshekhar/ts-jest</summary>

v26.1.4

Compare Source

Bug Fixes

</details>


Renovate configuration

:date: Schedule: "every weekend" in timezone America/Los_Angeles.

:vertical_traffic_light: Automerge: Enabled.

:recycle: Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+4 -4

0 comment

2 changed files

renovate[bot]

pr closed time in a day

delete branch apollographql/apollo-client

delete branch : renovate/rxjs-6.x

delete time in a day

push eventapollographql/apollo-client

renovate[bot]

commit sha dbeaacaedc3fbad0a186115a4a15d5e7107a19a6

chore(deps): update dependency rxjs to v6.6.2 (#6763) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

push time in a day

PR merged apollographql/apollo-client

chore(deps): update dependency rxjs to v6.6.2 dependencies

This PR contains the following updates:

Package Type Update Change
rxjs devDependencies patch 6.6.0 -> 6.6.2

Release Notes

<details> <summary>reactivex/rxjs</summary>

v6.6.2

Compare Source

v6.6.1

Compare Source

</details>


Renovate configuration

:date: Schedule: "every weekend" in timezone America/Los_Angeles.

:vertical_traffic_light: Automerge: Enabled.

:recycle: Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+4 -4

0 comment

2 changed files

renovate[bot]

pr closed time in a day

delete branch apollographql/apollo-client

delete branch : renovate/node-14.x

delete time in a day

push eventapollographql/apollo-client

renovate[bot]

commit sha 64f7041e59ebecf9baa947f82bc5a9ada63d6a91

chore(deps): update dependency @types/node to v14.0.27 (#6705) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

push time in a day

PR merged apollographql/apollo-client

chore(deps): update dependency @types/node to v14.0.27 dependencies

This PR contains the following updates:

Package Type Update Change
@types/node devDependencies patch 14.0.23 -> 14.0.27

Renovate configuration

:date: Schedule: "every weekend" in timezone America/Los_Angeles.

:vertical_traffic_light: Automerge: Enabled.

:recycle: Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+4 -4

0 comment

2 changed files

renovate[bot]

pr closed time in a day

delete branch apollographql/apollo-client

delete branch : renovate/jest-26.x

delete time in a day

push eventapollographql/apollo-client

renovate[bot]

commit sha ca6c368109ce11a1cdd8952aabe882501ffa6531

chore(deps): update dependency jest to v26.2.2 (#6703) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

push time in a day

PR merged apollographql/apollo-client

chore(deps): update dependency jest to v26.2.2 dependencies

This PR contains the following updates:

Package Type Update Change
jest (source) devDependencies minor 26.1.0 -> 26.2.2
@types/jest devDependencies patch 26.0.5 -> 26.0.8

Release Notes

<details> <summary>facebook/jest</summary>

v26.2.2

Compare Source

Fixes
  • [jest-cli] Use correct file name to override existing jest config on init (#​10337)
  • [jest-haste-map] Properly detect support for native find (#​10346)

v26.2.1

Compare Source

Fixes
  • [jest-worker] Make sure to work with Node TS typings v12 (#​10336)

v26.2.0

Compare Source

Features
  • [jest-core, jest-circus, jest-reporter, jest-runner] Added support for reporting individual test cases using jest-circus (#​10227)
  • [jest-config, jest-reporter, jest-runner, jest-test-sequencer] Add slowTestThreshold configuration option (#​9366)
  • [jest-haste-map] Watchman crawler now includes dotfiles (#​10075)
  • [jest-worker] Added support for workers to send custom messages to parent in jest-worker (#​10293)
  • [jest-worker] Support passing resourceLimits (#​10335)
  • [pretty-format] Added support for serializing custom elements (web components) (#​10217)
Fixes
  • [expect] Match symbols and bigints in any() (#​10223)
  • [jest-changed-files] Use git diff instead of git log for --changedSince (#​10155)
  • [jest-console] Add missing console.timeLog for compatibility with Node (#​10209)
  • [jest-haste-map] Check find binary supports the -iname parameter (#​10308)
  • [jest-snapshot] Strip added indentation for inline error snapshots (#​10217)
Chore & Maintenance

</details>


Renovate configuration

:date: Schedule: "every weekend" in timezone America/Los_Angeles.

:vertical_traffic_light: Automerge: Enabled.

:recycle: Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about these updates again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+713 -469

0 comment

2 changed files

renovate[bot]

pr closed time in a day

Pull request review commentapollographql/apollo-client

Add type/field policy code splitting docs section

 persistCache({ ```  For more advanced usage, such as persisting the cache when the app is in the background, and additional configuration options, please check the [README of `apollo-cache-persist`](https://github.com/apollographql/apollo-cache-persist).++## Code splitting++Depending on the complexity and size of your cache type/field policies, you might not always want to define them up front, when you create your initial `InMemoryCache` instance. If you have type/field policies that are only needed in a specific part of your application, you can leverage `InMemoryCache`'s `policies.addTypePolicies()` method to adjust your cache policy map at any point. This can be really useful when leveraging techniques like route based code-splitting, using something like `react-loadable`.++Let's say we're building a messaging app and have a `/stats` route that is used to return the total number of messages stored locally. If we use `react-loadable` to load our `Stats` component like:++```jsx+import Loadable from 'react-loadable';++import Loading from './components/Loading';++export const Stats = Loadable({+  loader: () => import('./components/stats/Stats'),+  loading: Loading,+});+```++and wait until our `Stats` component is called to add a new type/field policy (using `cache.policies.addTypePolicies()`):++```jsx:title=Stats.jsx+import React from "react";+import { gql, useApolloClient, useQuery } from "@apollo/client";+import gql from "graphql-tag";
import { useApolloClient, useQuery, gql } from "@apollo/client";
hwillson

comment created time in a day

Pull request review commentapollographql/apollo-client

Add type/field policy code splitting docs section

 persistCache({ ```  For more advanced usage, such as persisting the cache when the app is in the background, and additional configuration options, please check the [README of `apollo-cache-persist`](https://github.com/apollographql/apollo-cache-persist).++## Code splitting++Depending on the complexity and size of your cache type/field policies, you might not always want to define them up front, when you create your initial `InMemoryCache` instance. If you have type/field policies that are only needed in a specific part of your application, you can leverage `InMemoryCache`'s `policies.addTypePolicies()` method to adjust your cache policy map at any point. This can be really useful when leveraging techniques like route based code-splitting, using something like `react-loadable`.++Let's say we're building a messaging app and have a `/stats` route that is used to return the total number of messages stored locally. If we use `react-loadable` to load our `Stats` component like:++```jsx+import Loadable from 'react-loadable';++import Loading from './components/Loading';++export const Stats = Loadable({+  loader: () => import('./components/stats/Stats'),+  loading: Loading,+});+```++and wait until our `Stats` component is called to add a new type/field policy (using `cache.policies.addTypePolicies()`):++```jsx:title=Stats.jsx+import React from "react";+import { gql, useApolloClient, useQuery } from "@apollo/client";+import gql from "graphql-tag";++const GET_MESSAGE_COUNT = gql`+  {+    messageCount @client {+      total+    }+  }+`;++const newPolicy = {+  Query: {+    fields: {+      messageCount() {+        // calculate and return the number of messages stored locally ...+        return {+          total: 123,+        };+      },+    },+  },+};++export function Stats() {+  const client = useApolloClient();+  client.cache.policies.addTypePolicies(newPolicy);++  const { loading, data: { messageCount } } = useQuery(GET_MESSAGE_COUNT);

Since data can be undefined, we either need to avoid destructuring it, or provide a default = {} expression.

hwillson

comment created time in a day

Pull request review commentapollographql/apollo-client

Add type/field policy code splitting docs section

 persistCache({ ```  For more advanced usage, such as persisting the cache when the app is in the background, and additional configuration options, please check the [README of `apollo-cache-persist`](https://github.com/apollographql/apollo-cache-persist).++## Code splitting++Depending on the complexity and size of your cache type/field policies, you might not always want to define them up front, when you create your initial `InMemoryCache` instance. If you have type/field policies that are only needed in a specific part of your application, you can leverage `InMemoryCache`'s `policies.addTypePolicies()` method to adjust your cache policy map at any point. This can be really useful when leveraging techniques like route based code-splitting, using something like `react-loadable`.++Let's say we're building a messaging app and have a `/stats` route that is used to return the total number of messages stored locally. If we use `react-loadable` to load our `Stats` component like:++```jsx+import Loadable from 'react-loadable';++import Loading from './components/Loading';++export const Stats = Loadable({+  loader: () => import('./components/stats/Stats'),+  loading: Loading,+});+```++and wait until our `Stats` component is called to add a new type/field policy (using `cache.policies.addTypePolicies()`):++```jsx:title=Stats.jsx+import React from "react";+import { gql, useApolloClient, useQuery } from "@apollo/client";+import gql from "graphql-tag";++const GET_MESSAGE_COUNT = gql`+  {+    messageCount @client {+      total+    }+  }+`;++const newPolicy = {+  Query: {+    fields: {+      messageCount() {+        // calculate and return the number of messages stored locally ...+        return {+          total: 123,+        };+      },+    },+  },+};++export function Stats() {+  const client = useApolloClient();+  client.cache.policies.addTypePolicies(newPolicy);

I'd like to avoid re-adding the policies every time the component is rendered. I realize the component function gives us access to the client/cache, but maybe we can come up with a better pattern here? Maybe keep a Set of cache instances that we've seen, and only add the policies when we haven't seen this cache before?

hwillson

comment created time in a day

Pull request review commentapollographql/apollo-client

Add type/field policy code splitting docs section

 persistCache({ ```  For more advanced usage, such as persisting the cache when the app is in the background, and additional configuration options, please check the [README of `apollo-cache-persist`](https://github.com/apollographql/apollo-cache-persist).++## Code splitting++Depending on the complexity and size of your cache type/field policies, you might not always want to define them up front, when you create your initial `InMemoryCache` instance. If you have type/field policies that are only needed in a specific part of your application, you can leverage `InMemoryCache`'s `policies.addTypePolicies()` method to adjust your cache policy map at any point. This can be really useful when leveraging techniques like route based code-splitting, using something like `react-loadable`.
Depending on the complexity and size of your cache type/field policies, you might not always want to define them up front, when you create your initial `InMemoryCache` instance. If you have type/field policies that are only needed in a specific part of your application, you can leverage `InMemoryCache`'s `.policies.addTypePolicies()` method to adjust your cache policy map at any point. This can be really useful when leveraging techniques like route based code-splitting, using a tool like [`react-loadable`](https://www.npmjs.com/package/react-loadable).
hwillson

comment created time in a day

push eventapollographql/apollo-client

renovate[bot]

commit sha 9af70a0bc7d0e2e8cdfaff13d6d25a0c4d49138a

chore(deps): update dependency @babel/parser to v7.11.0 (#6761) Co-authored-by: Renovate Bot <bot@renovateapp.com>

view details

push time in a day

PR merged apollographql/apollo-client

chore(deps): update dependency @babel/parser to v7.11.0 dependencies

This PR contains the following updates:

Package Type Update Change
@babel/parser (source) devDependencies minor 7.10.5 -> 7.11.0

Release Notes

<details> <summary>babel/babel</summary>

v7.11.0

Compare Source

:eyeglasses: Spec Compliance
:rocket: New Feature
:bug: Bug Fix
  • Other
  • babel-helper-skip-transparent-expression-wrappers, babel-plugin-proposal-optional-chaining, babel-plugin-transform-spread
  • babel-helper-member-expression-to-functions, babel-plugin-proposal-class-properties, babel-plugin-proposal-logical-assignment-operators
  • babel-plugin-transform-typescript
  • babel-plugin-transform-runtime
  • babel-parser
    • #​11862 Correctly check reserved word for PropertyDefinition: IdentifierReference (@​JLHwung)
    • #​11847 fix: correctly set innerEndPos in CoverParenthesizedExpressionAndArrowParameterList (@​JLHwung)
  • babel-generator, babel-parser, babel-plugin-transform-typescript
  • babel-generator
:nail_care: Polish
:house: Internal
  • Other
  • babel-standalone
  • babel-compat-data, babel-helper-compilation-targets, babel-preset-env
  • babel-compat-data, babel-core, babel-helper-module-transforms, babel-helper-split-export-declaration, babel-parser, babel-plugin-proposal-object-rest-spread, babel-plugin-transform-classes, babel-preset-env, babel-traverse, babel-types
  • babel-types
  • babel-compat-data

</details>


Renovate configuration

:date: Schedule: "every weekend" in timezone America/Los_Angeles.

:vertical_traffic_light: Automerge: Enabled.

:recycle: Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.


  • [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

This PR has been generated by WhiteSource Renovate. View repository job log here.

+4 -4

0 comment

2 changed files

renovate[bot]

pr closed time in a day

delete branch apollographql/apollo-client

delete branch : renovate/babel-parser-7.x

delete time in a day

issue commentgraphql/graphql-js

Allow result type and variables type to be inferred from `DocumentNode`/`Source` using TypeScript type system

Apollo Client would gladly use this type, and we think it would be ideal for it to be provided by the same package that defines DocumentNode, though that's not an immediate blocker for us. See also https://github.com/apollographql/apollo-client/pull/6720#issuecomment-668203672.

dotansimha

comment created time in a day

pull request commentapollographql/apollo-client

feature: added support for automatic type inference with `typed-document-node`

@dotansimha This is a really fantastic improvement, and definitely the direction we want to take TypeScript code generation for Apollo Client. I could show you some Slack conversations proving that we've discussed something like this before, but you went ahead and implemented it, so you deserve all the credit here.

Thanks for bumping the major version of @graphql-typed-document-node/core—and I see you're already at 2.1.0!

Longer term, I would love to see TypedDocumentNode incorporated into the graphql package. I don't even think DocumentNode needs to change, since it's so widely used already. TypedDocumentNode can stand alone as a complementary type that makes it clear you're bundling the data/variables types with the document type.

In the short term, I think we (Apollo Client) would be happy to merge this PR, add a (dev) dependency on @graphql-typed-document-node/core, and re-export its TypedDocumentNode type from @apollo/client.

Would you be open to allowing your users to configure where the TypedDocumentNode type gets imported from? Ideally I'd like for Apollo Client users to be able to generate code that imports TypedDocumentNode from @apollo/client (which imports it from @graphql-typed-document-node/core), just so that nothing has to change in the future if TypedDocumentNode moves to a different package. This seems like the easiest way to make the source of TypedDocumentNode an implementation detail, but I'm open to any other ideas you have.

Thanks again for tackling this!

dotansimha

comment created time in a day

issue commentapollographql/apollo-client

query re runs after a a mutation and cache update

@tafelito Since @danfernand mentioned #6760, you might also want to check out my comment there: https://github.com/apollographql/apollo-client/issues/6760#issuecomment-668188727

tafelito

comment created time in a day

issue commentapollographql/apollo-client

query re runs after a a mutation and cache update

If I'm understanding the flow correctly, it sounds like you want those queries to start out with options.fetchPolicy === "cache-first", and then respond to cache updates after the first network request, but not make additional network requests, even if their data becomes incomplete?

If you update to @apollo/client@3.1.0 or later (3.1.2 is the latest version right now), you can take advantage of a new option, options.nextFetchPolicy (see #6712), which will switch fetch policies after the first request:

const { loading, data } = useQuery(THE_QUERY, {
  // This is the default fetch policy, so you don't usually have to specify it,
  // but I wanted to be explicit about it.
  fetchPolicy: "cache-first",
  // This means: stop making network requests for this query after the first
  // request, but keep listening to the cache. Explicitly refetching still works.
  nextFetchPolicy: "cache-only",
  // Tolerating partial cache data is probably useful if you can't fall back
  // to the network when cache data is incomplete.
  returnPartialData: true,
});

If you don't change the fetch policy with options.nextFetchPolicy, Apollo Client definitely will try to make a network request to refresh evicted/incomplete data, so the behavior you described is working as designed.

tafelito

comment created time in a day

issue commentapollographql/apollo-client

Apollo Client 3 reloading query after mutation update

@danfernand One of the things that changed in AC3 is that cache-and-network really means to read from the cache and make a network request, not just the first time, but whenever there's a cache update that affects this query.

Although I have a specific recommendation to achieve your desired behavior (verified with your reproduction—thanks!), there's a bit of history here that I think is worth understanding. PR #6221 was a big refactoring (released in -beta.46) that made FetchPolicy enforcement more consistent, and restored the -and-network part of cache-and-network, as described above. Realizing that this might not be the behavior folks actually want, we implemented (what we thought was) a clever trick to fall back to cache-first after the first network request, in PR #6353. This behavior was still in place when we released 3.0.0, but post-launch feedback convinced us to revert that PR in #6712, because modifying the options.fetchPolicy that you requested can be surprising and is not universally appropriate. In other words, your reproduction is making unwanted network requests because cache-and-network is being enforced literally.

However, PR #6712 did more than just revert #6353, because cache-and-network-followed-by-cache-first still seems like a very common hybrid policy that people may want to implement. To make achieving that behavior easy, we also introduced options.nextFetchPolicy (available in @apollo/client@3.1.0), so you can specify an initial fetch policy (via options.fetchPolicy, as before) and also request a different fetch policy next time.

Long story short, if you use options.nextFetchPolicy as follows, I believe you can get the behavior you're looking for:

export default function Todos() {
  const { loading, error, data } = useQuery(GET_ALL_TODOS, {
    fetchPolicy: "cache-and-network",
    nextFetchPolicy: "cache-first",
    variables: {
      _size: 10
    }
  });
  ...
}

This means the very first query will read from the cache and make a network request, but subsequent queries will make a network request only if the cache data has become incomplete.

danfernand

comment created time in a day

issue commentapollographql/apollo-client

🐛 useQuery doesn't work when there is both a @client directive and a normal query together

@buzinas Some questions:

  1. Can you share the code you're using to resolve the client field? I'm guessing it's a local resolver function?
  2. Does anything change if you add the planType field to the non-@client selection set?
  3. Is it possible to give your Organization objects an id field?
buzinas

comment created time in a day

issue commentapollographql/apollo-client

TypeError: Cannot set property 'getFragmentDoc' of undefined

Confirming @theneshofficial's answer (use new InMemoryCache()).

In strict mode, if you call a constructor function without new, this will be undefined. If you're using native class syntax rather than transpiling, constructor functions will throw an exception if you call them without using new, which helps prevent this problem, but most people are still transpiling class to function to support older browsers.

theneshofficial

comment created time in 2 days

issue commentapollographql/apollo-client

Using pagination with fetchMore and fetchPolicy involving network together causes bug where next page data is cleared

@jp928 @robertsmit Are you setting notifyOnNetworkStatusChange: true?

joonhocho

comment created time in 2 days

issue commentapollographql/apollo-client

toggling polling several times sends extra requests

I know this isn't the most helpful answer, but the way polling works has changed substantially in AC3, in case you were looking for more reasons to try upgrading. Specifically, all polling logic is now controlled by the Reobserver#updatePolling method.

healqq

comment created time in 2 days

created tagapollographql/apollo-client

tagv3.1.2

:rocket: A fully-featured, production ready caching GraphQL client for every UI framework and GraphQL server

created time in 2 days

push eventapollographql/apollo-client

Ben Newman

commit sha cf1d2e7128d84636ba6dab9ae5c66dcc62ea8db1

Mention PR #6375 in CHANGELOG.md.

view details

Ben Newman

commit sha e30f12221928a380b435c7ddf00a304753ac03cb

Bump @apollo/client npm version to 3.1.2.

view details

push time in 2 days

push eventdminkovsky/apollo-client

Ben Newman

commit sha 25169924ea8e938d00cd5404189b8eadcc740c2f

Add back author/contributor/reviewer information.

view details

push time in 4 days

issue commentapollographql/apollo-client

[v3] cache.modify with optimistic result does not broadcast change

@martaver Ok, thanks very much for sharing (the beginnings of) a reproduction! We'll take a look, and hopefully either identify/fix the problem or clarify how things are supposed to work.

martaver

comment created time in 4 days

push eventdminkovsky/apollo-client

Ben Newman

commit sha 40e5a13dfc5cd6d43c1b61df7686531ddee3071a

Add back author/review information.

view details

push time in 4 days

push eventdminkovsky/apollo-client

Ben Newman

commit sha ec67ca93ab6e1947318b6c51a19b178c17156354

Update README.md with new apollo-client/codemods/imports.js path.

view details

push time in 4 days

push eventdminkovsky/apollo-client

Renovate Bot

commit sha 3e2a41fe0710744b100cf8be0d9b1352cbdbcf95

chore(deps): update dependency gatsby-theme-apollo-docs to v4.3.6

view details

Dmitry Minkovsky

commit sha 6707111b4807d7276b99bf23ef0096796c3a181b

Add jscodeshift transform for v2->v3 migration

view details

Dmitry Minkovsky

commit sha 915c37867242302101a0fb7d07e5fb642c130335

Extracted common code and added remove `apollo-link` imports

view details

Jenn Creighton

commit sha a1844777a76014a40cd3e0620f4c4dc39c43ee9b

renameImport

view details

Jenn Creighton

commit sha 80a9b436cd713ae8d80e05f0c3726d42ee49d6da

move all specifiers unless explicitly noted

view details

Jenn Creighton

commit sha de8c074f77b1f0926841d3b8b9679d6eec56ffad

modify jscodeshift to migrate 2 to 3

view details

Jenn Creighton

commit sha 6a6af8981b069d3aa7deb19e9bc53cd60c95055f

move to src/utilities/codemods

view details

Jenn Creighton

commit sha e0f6599926e750e893af41917b2b74226703cd56

create apollo client import if there is none

view details

Jenn Creighton

commit sha 1b16a69fce2ce9f0bb35b91c00515497b45aa9e8

Update src/utilities/codemods/jscodeshift-migrate-2-to-3.js Co-authored-by: Ben Newman <ben@benjamn.com>

view details

Jenn Creighton

commit sha f8b7ccee172aaecd1bafc5ec72a396024fb7d846

move all specifiers to new import; check for v3 import of apollo client first

view details

Jenn Creighton

commit sha d49b91a468b4fe1b1b5cd8f108fcff13e0c7c493

rename apollo-link-* imports

view details

Jenn Creighton

commit sha a6dbdf50b1ffa1c5cde6f52c49648ae75a478668

handle default imports

view details

Ben Newman

commit sha 7d815824ccaf8e6ea12e4ed2c41bfc0881672aa1

Rename default specifier for apollo-link-schema, too.

view details

Ben Newman

commit sha cc08166e30cdd6f13d96d53ee33daee1bd2c17d5

Use renameDefaultSpecifier to rename { default as Foo } imports. Default exports can be imported by name: import { default as Client } from "apollo-client" which is equivalent to import Client from "apollo-client" With this commit, both of these styles to get transformed to import { ApolloClient as Client } from "@apollo/client"

view details

Ben Newman

commit sha 69068d300a2451f8be321d7218b1cba3d2c2de26

Add some example files to demonstrate the transform. Ideally we would have actual input/output tests, but for these examples seem like a good start.

view details

Ben Newman

commit sha b54f84bb21a4956ee951a504ffc9168430487d62

Fix old link package naming convention.

view details

Ben Newman

commit sha b4979d82084b1898694583bda64904177ccc91b5

Add basic package.json and README.md in codemods/ac2-to-ac3.

view details

Ben Newman

commit sha 7b7d9ab39a7bbd532c76230062408cbdc4ae3cad

Move codemods out of src/utilities. This makes sense because codemods are not really part of the Apollo Client library, and should fix TypeScript errors caused by the example files.

view details

Ben Newman

commit sha c743673daa81bd0d2741f2cedd58c353e8234938

Update README.md with new apollo-client/codemods/imports.js path.

view details

push time in 4 days

push eventdminkovsky/apollo-client

Ben Newman

commit sha 974a9556941cfff3ae0b05cf162897c34cb31776

Use renameDefaultSpecifier to rename { default as Foo } imports. Default exports can be imported by name: import { default as Client } from "apollo-client" which is equivalent to import Client from "apollo-client" With this commit, both of these styles to get transformed to import { ApolloClient as Client } from "@apollo/client"

view details

Ben Newman

commit sha c3c12dcdd854445a4776737e7192d0430bf7c01c

Add some example files to demonstrate the transform. Ideally we would have actual input/output tests, but for these examples seem like a good start.

view details

Ben Newman

commit sha ffdcc11433a722a7ceb817aaea5320fc176c9bda

Fix old link package naming convention.

view details

Ben Newman

commit sha 6abea9b337dc6fe1a16aad91cc2b078807d8a557

Add basic package.json and README.md in codemods/ac2-to-ac3.

view details

push time in 4 days

push eventdminkovsky/apollo-client

Ben Newman

commit sha 38355ca663a5bb65883e2bfe50d1463e0eab3c07

Rename default specifier for apollo-link-schema, too.

view details

push time in 4 days

Pull request review commentapollographql/apollo-client

Avoid making network requests when skip is true

 describe('useQuery Hook', () => {             break;           case 3:             expect(loading).toBeFalsy();-            expect(data).toBeUndefined();+            expect(data).toEqual(CAR_RESULT_DATA);

@sirugh Yes, that's what this PR currently does. While we think providing the previous data should be safe (because nothing is changing about the query/variables when you skip), we're somewhat worried that it will be a breaking change to start providing data instead of undefined. If you have any intuitions about that, please let us know!

hwillson

comment created time in 4 days

Pull request review commentapollographql/apollo-client

Add jscodeshift transform for v2->v3 migration

+/**+ * This jscodeshift transform takes care of some of the rote+ * things you'll need to do while migrating from v2 to v3.+ */++export default function transformer(file, api) {+  const j = api.jscodeshift;++  const source = j(file.source);++  renameOrCreateApolloClientImport();++  moveSpecifiersToApolloClient('@apollo/react-hooks');+  moveSpecifiersToApolloClient('apollo-cache-inmemory', ['InMemoryCache']);+  moveSpecifiersToApolloClient('graphql-tag');+  moveSpecifiersToApolloClient('apollo-link');+  moveSpecifiersToApolloClient('apollo-link-http');+  moveSpecifiersToApolloClient('apollo-link-http-common');++  renameImport('@apollo/react-components', '@apollo/client/react/components');+  renameImport('@apollo/react-hoc', '@apollo/client/react/hoc');+  renameImport('@apollo/react-ssr', '@apollo/client/react/ssr');+  renameImport('@apollo/react-testing', '@apollo/client/testing');

Let's use renameImport for the other @apollo/link-* packages here (see entryPoints.js for a complete list).

I was also going to suggest apollo-utilities => @apollo/client/utilities, but I suspect those imports have changed quite a bit, and the apollo-utilities package is still usable, so maybe we just leave it alone for now.

dminkovsky

comment created time in 6 days

Pull request review commentapollographql/apollo-client

Add jscodeshift transform for v2->v3 migration

+/**+ * This jscodeshift transform takes care of some of the rote+ * things you'll need to do while migrating from v2 to v3.+ */++export default function transformer(file, api) {+  const j = api.jscodeshift;++  const source = j(file.source);++  renameOrCreateApolloClientImport();++  moveSpecifiersToApolloClient('@apollo/react-hooks');+  moveSpecifiersToApolloClient('apollo-cache-inmemory', ['InMemoryCache']);+  moveSpecifiersToApolloClient('graphql-tag');+  moveSpecifiersToApolloClient('apollo-link');+  moveSpecifiersToApolloClient('apollo-link-http');+  moveSpecifiersToApolloClient('apollo-link-http-common');++  renameImport('@apollo/react-components', '@apollo/client/react/components');+  renameImport('@apollo/react-hoc', '@apollo/client/react/hoc');+  renameImport('@apollo/react-ssr', '@apollo/client/react/ssr');+  renameImport('@apollo/react-testing', '@apollo/client/testing');++  return source.toSource();++  function renameOrCreateApolloClientImport() {+    const apolloClientImport = getImport('apollo-client');+    if (apolloClientImport.size()) {+      renameImport('apollo-client', '@apollo/client');+    } else {+      source.find(j.ImportDeclaration).at(0).insertBefore(() => j.importDeclaration([], j.literal('@apollo/client')));+    }+  }++  function moveSpecifiersToApolloClient(+    moduleName,+    specifiers = [],+  ) {+    const moduleImport = getImport(moduleName);++    if (moduleImport.size()) {+      const clientImports = getImport('@apollo/client');+      const specifiersToAdd = (specifiers.length ? specifiers.map(importSpecifier) : moduleImport.get().value.specifiers);+      clientImports.replaceWith(p => ({+        ...p.value,+        specifiers: [+            ...p.value.specifiers,+            ...specifiersToAdd.map(path => importSpecifier((path.imported || path.local).name)),
            ...specifiersToAdd,

If we want to handle things like import { InMemoryCache as Cache } from "apollo-cache-inmemory", I think we should move the whole specifier (InMemoryCache as Cache), rather than ending up moving only Cache. Fortunately, I think this simplifies the code, since we don't need to recreate the specifier with importSpecifier.

dminkovsky

comment created time in 6 days

Pull request review commentapollographql/apollo-client

Add jscodeshift transform for v2->v3 migration

+/**+ * This jscodeshift transform takes care of some of the rote+ * things you'll need to do while migrating from v2 to v3.+ */++export default function transformer(file, api) {+  const j = api.jscodeshift;++  const source = j(file.source);++  renameOrCreateApolloClientImport();++  moveSpecifiersToApolloClient('@apollo/react-hooks');+  moveSpecifiersToApolloClient('apollo-cache-inmemory', ['InMemoryCache']);+  moveSpecifiersToApolloClient('graphql-tag');+  moveSpecifiersToApolloClient('apollo-link');+  moveSpecifiersToApolloClient('apollo-link-http');+  moveSpecifiersToApolloClient('apollo-link-http-common');++  renameImport('@apollo/react-components', '@apollo/client/react/components');+  renameImport('@apollo/react-hoc', '@apollo/client/react/hoc');+  renameImport('@apollo/react-ssr', '@apollo/client/react/ssr');+  renameImport('@apollo/react-testing', '@apollo/client/testing');++  return source.toSource();++  function renameOrCreateApolloClientImport() {+    const apolloClientImport = getImport('apollo-client');+    if (apolloClientImport.size()) {+      renameImport('apollo-client', '@apollo/client');+    } else {+      source.find(j.ImportDeclaration).at(0).insertBefore(() => j.importDeclaration([], j.literal('@apollo/client')));+    }+  }++  function moveSpecifiersToApolloClient(+    moduleName,+    specifiers = [],+  ) {+    const moduleImport = getImport(moduleName);++    if (moduleImport.size()) {+      const clientImports = getImport('@apollo/client');+      const specifiersToAdd = (specifiers.length ? specifiers.map(importSpecifier) : moduleImport.get().value.specifiers);+      clientImports.replaceWith(p => ({+        ...p.value,+        specifiers: [+            ...p.value.specifiers,+            ...specifiersToAdd.map(path => importSpecifier((path.imported || path.local).name)),

On second thought, the whole clientImports.replaceWith(...) expression can be replaced with

clientImports.get("specifiers").push(...specifiersToAdd);

since there's a NodePath#push method that works when the underlying value is an array.

dminkovsky

comment created time in 6 days

Pull request review commentapollographql/apollo-client

Add jscodeshift transform for v2->v3 migration

+/**+ * This jscodeshift transform takes care of some of the rote+ * things you'll need to do while migrating from v2 to v3.+ */++export default function transformer(file, api) {+  const j = api.jscodeshift;++  const source = j(file.source);++  renameOrCreateApolloClientImport();++  moveSpecifiersToApolloClient('@apollo/react-hooks');+  moveSpecifiersToApolloClient('apollo-cache-inmemory', ['InMemoryCache']);

After discussing this yesterday, I'm now leaning towards just moving everything from apollo-cache-inmemory to @apollo/client, so that we can safely remove the old import. The risk is that some of the moved specifiers may no longer exist in AC3, but I think that's better than accidentally dropping some unmoved imports.

dminkovsky

comment created time in 6 days

Pull request review commentapollographql/apollo-client

Add jscodeshift transform for v2->v3 migration

+/**+ * This jscodeshift transform takes care of some of the rote+ * things you'll need to do while migrating from v2 to v3.+ */++export default function transformer(file, api) {+  const j = api.jscodeshift;++  const source = j(file.source);++  renameOrCreateApolloClientImport();++  moveSpecifiersToApolloClient('@apollo/react-hooks');+  moveSpecifiersToApolloClient('apollo-cache-inmemory', ['InMemoryCache']);+  moveSpecifiersToApolloClient('graphql-tag');+  moveSpecifiersToApolloClient('apollo-link');+  moveSpecifiersToApolloClient('apollo-link-http');+  moveSpecifiersToApolloClient('apollo-link-http-common');++  renameImport('@apollo/react-components', '@apollo/client/react/components');+  renameImport('@apollo/react-hoc', '@apollo/client/react/hoc');+  renameImport('@apollo/react-ssr', '@apollo/client/react/ssr');+  renameImport('@apollo/react-testing', '@apollo/client/testing');++  return source.toSource();++  function renameOrCreateApolloClientImport() {+    const apolloClientImport = getImport('apollo-client');+    if (apolloClientImport.size()) {+      renameImport('apollo-client', '@apollo/client');+    } else {+      source.find(j.ImportDeclaration).at(0).insertBefore(() => j.importDeclaration([], j.literal('@apollo/client')));+    }

One of the things that changed from AC2 to AC3 is that there's no longer a default export for @apollo/client, which is something we can handle here. In other words, code like this:

import Client from "apollo-client"

should become

import { ApolloClient as Client } from "@apollo/client"

Here's one way I found to handle that case:

    apolloClientImport
      .find(j.ImportDefaultSpecifier)
      .replaceWith(path => {
        return path.value.local.name === "ApolloClient"
          ? importSpecifier("ApolloClient") // typical case
          : j.importSpecifier(j.identifier("ApolloClient"), path.value.local);
      });
dminkovsky

comment created time in 6 days

Pull request review commentapollographql/apollo-client

Add jscodeshift transform for v2->v3 migration

+/**+ * This jscodeshift transform takes care of some of the rote+ * things you'll need to do while migrating from v2 to v3.+ */++export default function transformer(file, api) {+  const j = api.jscodeshift;++  const source = j(file.source);++  renameOrCreateApolloClientImport();++  moveSpecifiersToApolloClient('@apollo/react-hooks');+  moveSpecifiersToApolloClient('apollo-cache-inmemory', ['InMemoryCache']);+  moveSpecifiersToApolloClient('graphql-tag');+  moveSpecifiersToApolloClient('apollo-link');+  moveSpecifiersToApolloClient('apollo-link-http');+  moveSpecifiersToApolloClient('apollo-link-http-common');++  renameImport('@apollo/react-components', '@apollo/client/react/components');+  renameImport('@apollo/react-hoc', '@apollo/client/react/hoc');+  renameImport('@apollo/react-ssr', '@apollo/client/react/ssr');+  renameImport('@apollo/react-testing', '@apollo/client/testing');++  return source.toSource();++  function renameOrCreateApolloClientImport() {

What happens if there's already an @apollo/client import in the file? It would be good if this function can find it and reuse it, since folks might have started migrating manually already, or they might try running this codemod more than once on the same file.

dminkovsky

comment created time in 6 days

Pull request review commentapollographql/apollo-client

Add jscodeshift transform for v2->v3 migration

+/**+ * This jscodeshift transform takes care of some of the rote+ * things you'll need to do while migrating from v2 to v3.+ */++export default function transformer(file, api) {+  const j = api.jscodeshift;++  const source = j(file.source);++  renameOrCreateApolloClientImport();++  moveSpecifiersToApolloClient('@apollo/react-hooks');+  moveSpecifiersToApolloClient('apollo-cache-inmemory', ['InMemoryCache']);+  moveSpecifiersToApolloClient('graphql-tag');+  moveSpecifiersToApolloClient('apollo-link');+  moveSpecifiersToApolloClient('apollo-link-http');+  moveSpecifiersToApolloClient('apollo-link-http-common');++  renameImport('@apollo/react-components', '@apollo/client/react/components');+  renameImport('@apollo/react-hoc', '@apollo/client/react/hoc');+  renameImport('@apollo/react-ssr', '@apollo/client/react/ssr');+  renameImport('@apollo/react-testing', '@apollo/client/testing');++  return source.toSource();++  function renameOrCreateApolloClientImport() {+    const apolloClientImport = getImport('apollo-client');+    if (apolloClientImport.size()) {+      renameImport('apollo-client', '@apollo/client');+    } else {+      source.find(j.ImportDeclaration).at(0).insertBefore(() => j.importDeclaration([], j.literal('@apollo/client')));+    }+  }++  function moveSpecifiersToApolloClient(+    moduleName,+    specifiers = [],+  ) {+    const moduleImport = getImport(moduleName);++    if (moduleImport.size()) {+      const clientImports = getImport('@apollo/client');+      const specifiersToAdd = (specifiers.length ? specifiers.map(importSpecifier) : moduleImport.get().value.specifiers);
      const specifiersToAdd = (specifiers.length ? specifiers.map(importSpecifier) : moduleImport.get("specifiers").value);

If I recall correctly (and it has been a while), calling .get() on a NodePath just gives you back the same path object, so we can either drop the .get() or use it to get a NodePath for the specifiers property, and then get that path's value (like I'm doing here).

dminkovsky

comment created time in 6 days

issue commentapollographql/apollo-client

writeFragment doesn't update objects with extended types

I think you'll have to share a reproduction if you want concrete guidance here (and also please include the versions of @apollo/client and any other relevant npm packages you're using!).

Cache IDs are expected to be uniquely identifying (for a particular type, since the __typename is usually included in the ID), so the idea that you would have two logically different objects with the same ID suggests that you're not meeting this expectation? Generally speaking, whenever the client receives different result objects with the same ID, the objects' fields will be merged together in the cache, because those result objects are considered to be different views of the same logical entity. If that's not the case here, then you need to find a way to keep the IDs of these objects distinct.

geiszla

comment created time in 6 days

issue commentapollographql/apollo-client

How should I import WebSocketLink ?

It's also to avoid cluttering the available top-level imports, and to avoid importing the entire library when using CommonJS (which Node.js still does in most cases). Any use of @apollo/client without a bundler benefits from having narrowly-scoped entry points for optional parts of the library, because there's no opportunity for tree-shaking without a bundler like Rollup or Webpack.

ArnaudBarre

comment created time in 6 days

issue commentapollographql/apollo-client

useQuery with changed variable on Apollo Cache doesn't work

Ok so, the readField helper takes a field name (string) as the first argument, and a Reference (the things that look like { __ref: <ID string> }) as the second argument, so maybe try readField("id", a) to get the id field from the a object?

By the way, the readField function will also work if the second argument is a normal object (not a Reference), so you should be able to use it regardless of whether you have references or regular objects.

hatchli

comment created time in 6 days

issue commentapollographql/apollo-client

Resolve missing fields in queries when optional ?

By the way, if this becomes repetitive, you can shorten the code with a helper function:

function nullable() {
  // Create a generic field policy that allows any field to be null by default:
  return {
    read(existing = null) {
      return existing;
    },
  };
}

new InMemoryCache({
  typePolicies: {
    Person: {
      fields: {
        address: nullable(),
        middleName: nullable(),
        // and so on...
      },
    },
  },
})
lampropoi

comment created time in 6 days

issue commentapollographql/apollo-client

Resolve missing fields in queries when optional ?

This is something you can do with the InMemoryCache API in AC3!

new InMemoryCache({
  typePolicies: {
    // Assuming the __typename of the Dog.owner field is "Person":
    Person: {
      fields: {
        address(existing = null) {
          return existing;
        },
      },
    },
  },
})

If any data from the server has been written for this field (within this Person object), you'll get that data in the existing parameter. The = null part is a default expression that will be used if existing is undefined. The key here is that returning undefined indicates the field is missing, whereas returning null will suppress the missing field warning. So this field policy ensures you always get at least null for Person.address, which should prevent the warnings.

lampropoi

comment created time in 6 days

issue closedapollographql/apollo-client

Loading state on Server Side Rendering

<!-- Thanks for filing an issue on Apollo Client!

Please make sure that you include the following information to ensure that your issue is actionable.

If you don't follow the template, your issue may end up being closed without anyone looking at it carefully, because it is not actionable for us without the information in this template.

PLEASE NOTE: Feature requests and non-bug related discussions are no longer managed in this repo. Feature requests should be opened in https://github.com/apollographql/apollo-feature-requests. -->

Intended outcome: Server side rendering with extracted cache

Actual outcome: The useQuery hook returns loading:true state

How to reproduce the issue:

  • create an apollo-client instance
  • execute a query using apollo.query
  • extract the cache
  • create an apollo-client instance passing the extracted state
  • run the same query with useQuery

Expected: loading property is false Actual: loading property is true, data is populated

Versions @apollo/client 3.0.2

closed time in 6 days

correttojs

issue closedapollographql/apollo-client

setContext not being called for query

Intended outcome: setContext's setter should be called on every request allowing me to dynamically set headers after an SPA login.

Actual outcome: Console logs that describe what events are occurring.

Notice that setContext is called twice during the signin mutation. Note that is happens whether or not the second query is run.

Second to last log SHOULD be running setContext image

How to reproduce the issue:

import { ApolloClient, ApolloLink, HttpLink } from "@apollo/client";
import { setContext } from "@apollo/client/link/context";
import { loader } from "graphql.macro";
import { cache } from "./cache";

const httpLink = new HttpLink({
  uri: "http://localhost:3001/graphql",
});

const authLink = setContext((_, { headers, ...context }) => {
  console.log("running setContext");
  return {
    headers: {
      ...headers,
      authorization: localStorage.getItem("token")
        ? `Bearer ${localStorage.getItem("token")}`
        : "nothing here", // set to verify it was setting in headers
    },
    ...context,
  };
});

export const apolloClient = new ApolloClient({
  link: ApolloLink.from([authLink, httpLink]),
  cache,
  typeDefs: loader("./schema.graphql"),
});

Code that is being called:

export const getMe = async () => {
  console.log("before running new query after token set");
  const meResult = await apolloClient.query<MeQuery>({
    query: MeDocument,
  });
  const me = meResult.data?.me;

  appState({ ...appState(), me });
};

export const signIn = async (input: { email: string; password: string }) => {
  try {
    console.log("before signin mutation");
    const result = await apolloClient.mutate<SignInMutation>({
      mutation: SignInDocument,
      variables: {
        input,
      },
    });
    console.log("succesfully passed signin mutation");

    const token = result.data?.signIn.access_token!;
    localStorage.setItem("token", token);

  // settings token in state, but not using it in the setContext.
    appState({ ...appState(), token });
    console.log("Token has been set and verified to exist");
    await getMe();
  } catch (e) {
    console.log("new query has thrown. authorization was not set in header.");
    // console.log("caught signin error", e);
    throw e;
  }

  return true;
};

headers for the Me query image

Versions

 System:
    OS: macOS 10.15.5
  Binaries:
    Node: 12.16.3 - ~/.nvm/versions/node/v12.16.3/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.4 - ~/.nvm/versions/node/v12.16.3/bin/npm
  Browsers:
    Chrome: 83.0.4103.116
    Edge: 83.0.478.64
    Firefox: 77.0.1
    Safari: 13.1.1
  npmPackages:
    @apollo/client: ^3.0.1 => 3.0.1 

closed time in 6 days

Johnhhorton

delete branch apollographql/apollo-client

delete branch : async-schema-link-context-function

delete time in 6 days

push eventapollographql/apollo-client

Ben Newman

commit sha d7664b5a075c9f45305e6983b79f254dbca63073

Allow SchemaLink.Options.context function to be async. (#6735) Closes #6730.

view details

push time in 6 days

PR merged apollographql/apollo-client

Reviewers
Allow SchemaLink.Options.context function to be async. 🔗 apollo-link 🔠 quick-and-easy 🧞‍♂️ enhancement

Closes #6730.

I chose to use the Promise API instead of async/await because async functions tend to grow large when compiled by TypeScript.

+32 -32

0 comment

1 changed file

benjamn

pr closed time in 6 days

issue closedapollographql/apollo-client

context in SchemaLink is not async

Intended outcome: I'm trying to have an async context for SchemaLink. But in "src/link/schema/index.ts" at line 51 there is this.context(operation)instead of await this.context(operation). This is a different behavior for ApolloClient than for ApolloServer, which breaks the app in my case.

Actual outcome: context does not wait until promise is resolved, and therefore the injected context in resolvers is wrong.

How to reproduce the issue: Make the context return a promise instead of a sync function

Versions Latest version

closed time in 6 days

djflex68

issue commentapollographql/apollo-client

context in SchemaLink is not async

@djflex68 Seems like a good idea! Have a look at #6735?

djflex68

comment created time in 6 days

PR opened apollographql/apollo-client

Reviewers
Allow SchemaLink.Options.context function to be async. 🔗 apollo-link 🔠 quick-and-easy 🧞‍♂️ enhancement

Closes #6277

I chose to use the Promise API instead of async/await because async functions tend to grow large when compiled by TypeScript.

+32 -32

0 comment

1 changed file

pr created time in 6 days

issue commentapollographql/apollo-client

Loading state on Server Side Rendering

You may want to update to @apollo/client@3.1.1, which includes #6710.

correttojs

comment created time in 6 days

issue commentapollographql/apollo-client

useQuery with changed variable on Apollo Cache doesn't work

You may be right that all the data is in the cache already, but the cache can't guess which variables are relevant for reading this particular query, so it would be inappropriate to return data that may not match the given variables.

Fortunately, in AC3, you can define a custom read and merge functions for the Query.products field, which can process/examine the existing cache data and the arguments received by the field, to support flexible ways of querying the field:

const cache = new InMemoryCache({
  typePolicies: {
    Query: {
      fields: {
        products: {
          // Prevent the cache from using the arguments to store separate values for this field:
          keyArgs: false,
          // Define how to use args.{where,take,...} to return flexible views of the existing data:
          read(existing, { args }) {
            // Note: existing is whatever merge returns, and may be undefined if no data has been written yet.
            return readWithArgs(existing, args);
          },
          // Define how new data is combined with existing data to support reading:
          merge(existing = emptyData(), incoming, { args }) {
            return mergeWithArgs(existing, incoming, args);
          },
        },
      },
    },
  },      
});

See the documentation for further explanation, this recent comment for a related discussion of keyArgs, and these helper functions for some examples of generating reusable field policies. We don't have any helpers that exactly match your use case, but offsetLimitPagination is probably the closest starting point.

I know that's a lot to digest, but we're happy to answer any questions you have!

hatchli

comment created time in 6 days

issue commentapollographql/apollo-client

How should I import of WebSocketLink ?

This should work (although it was improved in v3.1.0 by #6656):

import { WebSocketLink } from "@apollo/client/link/ws"

However, you will probably want to avoid using @apollo/link-ws or apollo-link-ws at the same time.

Happy to answer follow-up questions, of course.

ArnaudBarre

comment created time in 6 days

issue commentapollographql/apollo-client

Fetch more with merge policy existing data comes undefined or previous incoming data with duplicates.

You're very close to the solution, but there's one more piece that's worth understanding.

The cache can't make any assumptions about the meaning of your field arguments (filterType and pageNumber), so by default it stores data received for the people field separately whenever the arguments are different. Since your fetchMore query has different argument values than the original query, those two people results get stored separately, which is why existing is undefined in the merge function—no data exists for those new arguments.

While this is reasonable default strategy (in the absence of better information), it's often not a very good strategy, especially since fetchMore is intended to grow the original array, rather than storing its result separately. For cases like this, you can control which arguments the cache considers relevant for storage using the keyArgs configuration. Options include keyArgs: ["filterType"], keyArgs: ["pageNumber"], keyArgs: ["filterType", "pageNumber"] (this is the default behavior), and keyArgs: false.

Since you probably want there to be only one array, regardless of the arguments, the most appropriate setting is keyFields: false, which tells the cache to store the people data using a property like people: [...], rather than something like 'people:({"filterType":...,"pageNumber":...})': [...]. This ensures there's only ever one array, and it works because your merge (and read) functions have a chance to examine options.args to interpret the arguments however you like. If you wanted to keep separate lists according to filterType, you could use keyArgs: ["filterType"] instead.

One additional subtlety: when you define both a merge function and read function for a field, the cache assumes those functions will take responsibility for interpreting the arguments, so keyArgs: false is assumed by default (though you can override it explicitly). For more background on this behavior, see #5680 and #5862. That's why you noticed (correctly) that adding a simple read function fixed the problem. However, if you want to have only a merge function, you need to specify keyArgs: false yourself. Sorry this policy wasn't better documented!

For comparison, our concatPagination helper exported by @apollo/client/utilities uses a keyArgs configuration that defaults to false:

export function concatPagination<T = Reference>(
  keyArgs: KeyArgs = false,
): FieldPolicy<T[]> {
  return {
    keyArgs,
    merge(existing, incoming) {
      return existing ? [
        ...existing,
        ...incoming,
      ] : incoming;
    },
  };
}

If you wanted to use this helper, your code could look like this:

import { concatPagination } from "@apollo/client/utilities"

const cache = new InMemoryCache({
  typePolicies: {
    Query: {
      fields: {
        filterId: {
          read() {
            return filterIdVar();
          }
        },
        people: concatPagination(),
      }
    }
  }
})

However, even with a helper function available, I think it's useful to understand what's going on behind the scenes.

As one final note, it may be tempting to define a read function to go along with your merge function, but we've found that read functions are often unnecessary when using fetchMore, and can complicate things because you have to update the variables for the original query to match the new longer list. With no read function and keyArgs: false, the list just keeps growing, and you don't have to worry about updating the original query.

I know that's a whole lot of information, but thanks for reading, and thanks for providing a reproduction that made it easy to see exactly what was going on!

ErkinKurt

comment created time in 7 days

issue commentapollographql/apollo-client

DataProxy and NormalizedCacheObject types not available from @apollo/client in 3.1 without deep import

This should now be fixed in @apollo/client@3.1.1 (just published). Thanks for reporting this @JoshRobertson!

JoshRobertson

comment created time in 7 days

created tagapollographql/apollo-client

tagv3.1.1

:rocket: A fully-featured, production ready caching GraphQL client for every UI framework and GraphQL server

created time in 7 days

push eventapollographql/apollo-client

Ben Newman

commit sha edb3954070ffd551c506e74600b7a5093c8ff349

Mention PR #6725 in CHANGELOG.md section for v3.1.1.

view details

Ben Newman

commit sha c3f65bfb07584e46ac184ee4b9c7b9f7352b1496

Bump @apollo/client npm version to 3.1.1.

view details

push time in 7 days

issue closedapollographql/apollo-client

DataProxy and NormalizedCacheObject types not available from @apollo/client in 3.1 without deep import

When upgrading from 3.02 to 3.1, our type imports for DataProxy and NormalizedCacheObject no longer work unless we deep import from @apollo/client/cache.

I suspect it might be a result of https://github.com/apollographql/apollo-client/pull/6656

I just can't tell if it's intended and undocumented, or unintended.

closed time in 7 days

JoshRobertson

delete branch apollographql/apollo-client

delete branch : reinstate-cache-type-exports

delete time in 7 days

push eventapollographql/apollo-client

Ben Newman

commit sha 0cf607f48e7a0204837448cc781db9498d31ba6d

Re-export cache types from @apollo/client/core, again. (#6725) These types were lost in #6656 when I switched from export * from '../cache' to using named exports. There are some @apollo/client/cache exports that I wanted to omit from @apollo/client/core (like cacheSlot), but I definitely did not intend to omit these types. Fixes #6723.

view details

push time in 7 days

PR merged apollographql/apollo-client

Re-export cache types from @apollo/client/core, again. ⛑ TypeScript 📟 regression

These types were lost in #6656 when I switched from

export * from '../cache'

to using named exports. There are some @apollo/client/cache exports that I wanted to omit from @apollo/client/core (like cacheSlot), but I definitely did not intend to omit these types!

Fixes #6723.

+15 -0

0 comment

1 changed file

benjamn

pr closed time in 7 days

issue commentapollographql/apollo-client

DataProxy and NormalizedCacheObject types not available from @apollo/client in 3.1 without deep import

Ack, sorry, this was unintentional. Fix incoming: #6725

JoshRobertson

comment created time in 7 days

PR opened apollographql/apollo-client

Re-export cache types from @apollo/client/core, again.

These types were lost in #6656 when I switched from

export * from '../cache'

to using named exports. There are some @apollo/client/cache exports that I wanted to omit from @apollo/client/core (like cacheSlot), but I definitely did not intend to omit these types!

Fixes #6723.

+15 -0

0 comment

1 changed file

pr created time in 7 days

create barnchapollographql/apollo-client

branch : reinstate-cache-type-exports

created branch time in 7 days

issue commentapollographql/apollo-client

Reactive variables: Updating nested properties doesn't trigger a re-render

That code still seems to be modifying properties of the task objects in-place. Hence my suggestion about doing task = { ...task, completed: !task.completed } instead. You shouldn't need a library to do simple immutable/non-destructive updates to JS objects.

ryands17

comment created time in 7 days

issue commentapollographql/apollo-client

setContext not being called for query

@Johnhhorton This should now be fixed in @apollo/client@3.1.0, assuming #6656 was the solution to your problem. I'll leave this issue open so you can confirm. Thanks!

Johnhhorton

comment created time in 8 days

pull request commentapollographql/apollo-client

Add codemod for migrating imports to `@apollo/client`.

@bnjmnt4n Feel up for reviewing #6486, given your deep/recent experience with this? 🙏 🔬

bnjmnt4n

comment created time in 8 days

pull request commentapollographql/apollo-client

Ergonomic improvements for field policy merge and keyArgs functions.

These improvements are available now in @apollo/client@3.1.0 (just published to npm).

benjamn

comment created time in 8 days

pull request commentapollographql/apollo-client

Support async render function in getDataFromTree / getMarkupFromTree

Following up: we just published @apollo/client@3.1.0 to npm!

richardscarrott

comment created time in 8 days

pull request commentapollographql/apollo-client

react: MutationResult.client is always set

This is officially available now in @apollo/client@3.1.0 (just published to npm).

glasser

comment created time in 8 days

issue commentapollographql/apollo-client

defaultOptions.mutate.fetchPolicy is ignored by useMutation

Following up: we just published @apollo/client@3.1.0 to npm!

awinograd

comment created time in 8 days

more