Make makeVar a global function instead of a method of InMemoryCache. #6512
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The makeVar method was originally attached to InMemoryCache so that we could call cache.broadcastWatches() whenever the variable was updated. See #5799 and #5976 for background. However, as a number of developers have reported, requiring access to an InMemoryCache to create a ReactiveVar can be awkward, since the code that calls makeVar may not be colocated with the code that creates the cache, and it is often desirable to create and initialize reactive variables before the cache has been created. As this commit shows, the ReactiveVar function can infer the current InMemoryCache from a contextual Slot, when called without arguments (that is, when reading the variable). When the variable is updated (by passing a new value to the ReactiveVar function), any caches that previously read the variable will be notified of the update. Since this logic happens at variable access time rather than variable creation time, makeVar can be a free-floating global function, importable directly from @apollo/client. This new system allows the variable to become associated with any number of InMemoryCache instances, whereas previously a given variable was only ever associated with one InMemoryCache. Note: when I say "any number" I very much mean to include zero, since a ReactiveVar that has not been associated with any caches yet can still be used as a container, and will not trigger any broadcasts when updated. The Slot class that makes this all work may seem like magic, but we have been using it ever since Apollo Client 2.5 (#3394, via the optimism library), so it has been amply battle-tested. This magic works.
benjamn
commented
Jun 30, 2020
benjamn
commented
Jun 30, 2020
benjamn
commented
Jun 30, 2020
| @@ -16,6 +16,7 @@ const external = [ | |||
| 'graphql/language/visitor', | |||
| 'graphql-tag', | |||
| 'fast-json-stable-stringify', | |||
| '@wry/context', | |||
There was a problem hiding this comment.
Super important to include any new direct dependencies in this list; otherwise the whole dependency gets pulled into the Apollo Client bundle!
benjamn
commented
Jun 30, 2020
benjamn
commented
Jun 30, 2020
hwillson
approved these changes
Jun 30, 2020
47 tasks
This was referenced Jun 30, 2020
benjamn
added a commit
that referenced
this pull request
Jun 30, 2020
Follow-up to #6512. Also, set cacheSlot when calling local state resolver functions, since they are analogous to field read functions.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
makeVarmethod was originally attached toInMemoryCacheso that we could callcache.broadcastWatches()whenever the variable was updated. See #5799 and #5976 for background.However, as a number of developers have reported, requiring access to an
InMemoryCacheto create aReactiveVarcan be awkward, since the code that callsmakeVarmay not be colocated with the code that creates the cache, and it is often desirable to create and initialize reactive variables before the cache has even been created.As this commit shows, the
ReactiveVarfunction can infer the currentInMemoryCachefrom a contextualSlot<InMemoryCache>, when called without arguments (that is, when reading the variable). When the variable is updated (by passing a new value to theReactiveVarfunction), any caches that previously read the variable will be notified of the update. Since this logic happens at variable access time rather than variable creation time,makeVarcan be a free-floating global function, importable directly from@apollo/client.This new system allows the variable to become associated with any number of
InMemoryCacheinstances, whereas previously a given variable was only ever associated with oneInMemoryCache. Note: when I say "any number" I very much mean to include zero, since aReactiveVarthat has not been associated with any caches yet can still be used as a container, and will not trigger any broadcasts when updated.The
Slotclass that makes this all work may seem like magic, but we have been using it ever since Apollo Client 2.5 (#3394, via theoptimismlibrary), so it has been amply battle-tested. This magic works.