-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added documentation for @typePolicy #586
Conversation
✅ Docs preview readyThe preview is ready to be viewed. View the preview File Changes 0 new, 2 changed, 1 removed
Build ID: 0b2e31899f329a3565584542 URL: https://www.apollographql.com/docs/deploy-preview/0b2e31899f329a3565584542 |
✅ Deploy Preview for eclectic-pie-88a2ba ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for apollo-ios-docc canceled.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just left some superficial copyedit suggestions. I realize some of the suggesting (like using or ) may make these pages inconsistent with formatting on other pages and so you may want to leave them out for now.
docs/source/config.json
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might want to remove this file as long as it's not being used. Will confirm with @BlenderDude if this is something we can bring back first.
|
||
1. `let uniqueKeyGroup: String?` | ||
Declarative cache keys work by adding directives to your backend schema types to indicate how cache keys should be resolved for those times. To do this, you can extend your backend schema by creating a schema extension file with the file extension `.graphqls`. You can add any number of schema extension files to your project. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found this a little hard to follow, so I tried breaking it up into shorter sentences. Does this still capture things accurately?
Declarative cache keys work by adding directives to your backend schema types to indicate how cache keys should be resolved for those times. To do this, you can extend your backend schema by creating a schema extension file with the file extension `.graphqls`. You can add any number of schema extension files to your project. | |
To use declarative cache keys, you add directives to your backend schema types. The directives indicate how to resolve cache keys. To use these directives, you extend your backend schema by creating a schema extension file with the file extension `.graphqls`. You can add any number of schema extension files to your project. |
|
||
The code generation engine creates this file if it doesn't exist yet, but never overwrites an existing `SchemaConfiguration.swift` file. This means you can edit your schema configuration without those changes being overwritten on subsequent code generation runs. | ||
|
||
> *Tip:* You can configure the location of the generated schema types with the [`output.schemaTypes` option in your code generation configuration](./../code-generation/codegen-configuration). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
> *Tip:* You can configure the location of the generated schema types with the [`output.schemaTypes` option in your code generation configuration](./../code-generation/codegen-configuration). | |
<Tip> | |
You can configure the location of the generated schema types with the [`output.schemaTypes` option in your code generation configuration](./../code-generation/codegen-configuration). | |
</Tip> |
|
||
To configure how cache keys are computed from a response object, you can create and return [`CacheKeyInfo`](#cachekeyinfo) values from your implementation of [`cacheKeyInfo(for:object:)`](https://www.apollographql.com/docs/ios/docc/documentation/apolloapi/schemaconfiguration/cachekeyinfo(for:object:)). | ||
|
||
> **Note:** When specifying **cache IDs**, make sure that you are always fetching the fields used to construct those IDs in your operations. Any response objects that don't contain the **cache ID** fields will not be able to be [merged via cache normalization](./introduction#normalizing-responses). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
> **Note:** When specifying **cache IDs**, make sure that you are always fetching the fields used to construct those IDs in your operations. Any response objects that don't contain the **cache ID** fields will not be able to be [merged via cache normalization](./introduction#normalizing-responses). | |
<Note> | |
When specifying **cache IDs**, make sure that you are always fetching the fields used to construct those IDs in your operations. Any response objects that don't contain the **cache ID** fields will not be able to be [merged via cache normalization](./introduction#normalizing-responses). | |
</Note> |
} | ||
``` | ||
|
||
## Caveats & limitations |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
## Caveats & limitations | |
## Caveats and limitations |
|
||
1. While the cache key for an object can use a field from another nested object, if the fields on the referenced object are changed in another operation, the cache key for the dependent object will not be updated. For nested objects that are not normalized with their own cache key, this will never occur, but if the nested object is an entity with its own cache key, it can be mutated independently. In that case, any other objects whose cache keys are dependent on the mutated entity will not be updated automatically. You must take care to update those entities manually with a cache mutation. | ||
|
||
2. The `object` passed to this function represents data for an object in an specific operation model, not a type in your schema. This means that [aliased fields](https://spec.graphql.org/draft/#sec-Field-Alias) will be keyed on their alias name, not the name of the field on the schema type. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2. The `object` passed to this function represents data for an object in an specific operation model, not a type in your schema. This means that [aliased fields](https://spec.graphql.org/draft/#sec-Field-Alias) will be keyed on their alias name, not the name of the field on the schema type. | |
2. The `object` passed to this function represents data for an object in a specific operation model, not a type in your schema. This means that [aliased fields](https://spec.graphql.org/draft/#sec-Field-Alias) will be keyed on their alias name, not the name of the field on the schema type. |
docs/source/client-directives.mdx
Outdated
`directive @typePolicy(module: String!) repeatable on OBJECT | INTERFACE` | ||
|
||
Adds an type policy to a type that can be used to resolve cache keys for objects of that type. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adds an type policy to a type that can be used to resolve cache keys for objects of that type. | |
Adds a type policy to a type that can be used to resolve cache keys for objects of that type. |
@@ -8,181 +8,66 @@ The normalized cache computes a **cache key** for each object that is stored in | |||
|
|||
> To learn more, read about how the cache [normalizes objects by cache key](./introduction#normalizing-objects-by-cache-key). | |||
|
|||
## `CacheKeyInfo` | |||
For most uses cases, you can configure cache keys declaratively using the methods described here. For advanced use cases not supported by declarative cache keys, you can configure cache keys [programmatically](./programmatic-cache-keys). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might just be me but clicking "programmatic cache keys" in the preview makes a 404 (link is https://www.apollographql.com/docs/deploy-preview/1f96ea7a044024b699863083/ios/caching/programmatic-cache-keys)
``` | ||
|
||
If the JSON response `object` has no `id` field, the function returns `nil` and the cache will normalize the object using the [default response path normalization](./introduction#normalizing-responses). | ||
Apollo iOS will now resolve the cache key for all objects with a `__typename` of `"Book"` by using the value of their `id` field. The concrete type of the object is always prepended to the cache key. This means that a `Book` object with an `id` of `456` will resolve to have a cache key of `Book:456`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be worth adding that either:
- it's the user responsibility to make sure all the key fields are queried
- or that the codegen is doing it automatically
I think it is 1. right now? Either case, it's an important consideration for the system to work.
Co-authored-by: Maria Elisabeth Schreiber <[email protected]> Co-authored-by: Martin Bonnin <[email protected]>
4e7e506
to
d74bceb
Compare
Co-authored-by: Maria Elisabeth Schreiber <[email protected]> Co-authored-by: Martin Bonnin <[email protected]>
### `@typePolicy(keyFields: String!)` | ||
|
||
`directive @typePolicy(module: String!) repeatable on OBJECT | INTERFACE` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
`directive @typePolicy(module: String!) repeatable on OBJECT | INTERFACE` | |
`directive @typePolicy(keyFields: String!) on OBJECT | INTERFACE` |
I don't think the deploy preview is correctly updating. This one has the correct commit hash (d1ba913) but it didn't actually deploy. @Meschreiber - is there a way to force a new docs preview to be built on the last commit in this PR? |
```swift showLineNumbers=false | ||
CacheKeyInfo(id: "123", uniqueKeyGroup: "Animal") | ||
Apollo iOS would construct a cache key of `"Animal:123"`. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the formatting is off here, high probability it was from a previous suggestion of mine 😅.
Edit: looks like you can't leave a suggestion with a closing codeblock correctly, but it should be this:
CacheKeyInfo(id: "123", uniqueKeyGroup: "Animal")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything looks good in the preview, going to merge.
This PR adds documentation for the new
@typePolicy
feature.