docs/assets/partial-results.png
docs/assets/partial-results.png
This is a binary file and will not be displayed.
+76
-34
docs/graphcache/schema-awareness.md
+76
-34
docs/graphcache/schema-awareness.md
···-fragment matching. This schema argument is of type `IntrospectionQuery`, as JSON structure that-With deterministic fragment matching if we use an interface or a union _Graphcache_ can be 100% sure-what the expected types and shape of the data must be and whether the match is permitted. It also-But how do you get this introspected schema? The process of introspecting a schema is running anintrospection query on the GraphQL API, which will give us our `IntrospectionQuery` result. So an-As long as `introspection` as turned on and permitted, we can download an introspection schema by···It may be worth checking what your bundler or framework does when you import a JSON file. Typically-Once _Schema Awareness_ is activated in _Graphcache_, it can use the schema to check which fields-possible, which means that different queries may give you partial data where some uncached fields-have been replaced with `null`, while loading more data in the background, instead of our apps-Let's approach this with the example from ["Computed Queries"](./local-resolvers.md#resolve): We-have our `TodosQuery` result which loads a list, and our app may want to get a specific `Todo` when-_Graphcache_ what `Query.todo` does, but it may be missing some optional field to actuall give us-Without a schema _Graphcache_ would assume that because some fields are uncached and missing, it-can't serve this query's data. But if it has a schema, it may see that the uncached fields are-optional anyway and it can return a partial result for the `Todo` while it's fetching the full query-This means that _Schema Awareness_ can enable us to create apps that can display already cached data-on page transitions, while the page's full data loads in the background, which can often feel much
···+Previously, [on the "Normalized Caching" page](./normalized-caching.md) we've seen how Graphcache+stores normalized data in its store and how it traverses GraphQL documents to do so. What we've seen+Graphcache is able to build a normalized caching structure that keeps our application up-to-date+across API results, allows it to store data by entities and keys, and provides us configuration+While this is all possible without any information about a GraphQL API's schema, the `schema` option+"introspected"](https://graphql.org/learn/introspection/), which are special GraphQL queries that+GraphQL API directly or from the GraphQL.js Schema and contains a list of all types, the types'+In Graphcache we can pass this schema information to enable several features that aren't enabled if+- Fragments will be matched deterministically: A fragment can be written to be on an interface type+or multiple fragments can be spread for separate union'ed types in a selection set. In many cases,+if Graphcache doesn't have any schema information then it won't know what possible types a field+warning](./errors.md#16-heuristic-fragment-matching). If we pass Graphcache a `schema` then it'll+- A schema may have non-default names for its root types; `Query`, `Mutation`, and `Subscription`.+- We may write a lot of configuration for our `cacheExchange` but if we pass a `schema` then it'll+start checking whether any of the configuration options actually don't exist, maybe because we've+Graphcache has a schema it knows which fields can be made optional and it'll be able to generate+As we navigate an app that uses Graphcache we may be in states where some of our data is already+cached and some isn't. Graphcache normalizes data and stores it in tables for links and records for+each entity, which means that sometimes it can maybe even execute a query against its cache that it+[On the "Local Resolvers" page](./local-resolvers.md#resolving-entities) we've seen how to write+resolvers that resolver entities without having to have seen a link from an API result before. If+Graphcache uses these resolvers and previously cached data we often run into situations where a+"partial result" could already be generated, which is what Graphcache does when it has `schema`+Without a `schema` and information on which fields are optional, Graphcache will consider a "partial+result" as a cache miss. If we don't have all of the information for a query then we can't execute+it against the locally cached data after all. However, an API's schema contains information on which+fields are required and which fields are optional, and if our apps are typed with this schema and+TypeScript, can't we then use and handle these partial results before a request is sent to the API?+But how do you get an introspected `schema`? The process of introspecting a schema is running anintrospection query on the GraphQL API, which will give us our `IntrospectionQuery` result. So an+As long as `introspection` is turned on and permitted, we can download an introspection schema by···It may be worth checking what your bundler or framework does when you import a JSON file. Typically