From 42f0dd82b03182f5d1686ac572ab23c8482c115e Mon Sep 17 00:00:00 2001 From: Calvin Cestari Date: Mon, 23 Sep 2024 17:00:34 -0700 Subject: [PATCH 1/4] Fix page title links --- docs/source/project-configuration/modularization.mdx | 2 +- docs/source/project-configuration/schema-types.mdx | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/source/project-configuration/modularization.mdx b/docs/source/project-configuration/modularization.mdx index 96b7358b8..acc8b0409 100644 --- a/docs/source/project-configuration/modularization.mdx +++ b/docs/source/project-configuration/modularization.mdx @@ -19,7 +19,7 @@ Alternatively you may use a single target configuration with a multi-module proj --- -For a single target project configuration, you can link your target to the `Apollo` library. You can also optionally link to [`ApolloSQLite`](#apollosqlite) and/or [`ApolloWebSocket`](#apollowebsocket) to enable their functionality. +For a single target project configuration, you can link your target to the `Apollo` library. You can also optionally link to [`ApolloSQLite`](./sdk-components#apollosqlite) and/or [`ApolloWebSocket`](./sdk-components#apollowebsocket) to enable their functionality. > For more information about the libraries that make up the Apollo iOS SDK, see the [Apollo iOS SDK](./sdk-components). diff --git a/docs/source/project-configuration/schema-types.mdx b/docs/source/project-configuration/schema-types.mdx index 1a80c3880..e14dfd2b1 100644 --- a/docs/source/project-configuration/schema-types.mdx +++ b/docs/source/project-configuration/schema-types.mdx @@ -25,7 +25,7 @@ Wherever you place your schema types, they will need to be linked to by any modu ## Schema module -For most projects, we recommend creating a "schema module" to contain your schema types. This enables you to share your generated models across modules as your project grows. You can use either the [`.swiftPackageManager`](#swiftpackagemanager) or [`.other`](#other-module) options to create a schema module. +For most projects, we recommend creating a "schema module" to contain your schema types. This enables you to share your generated models across modules as your project grows. You can use either the [`.swiftPackageManager`](#swiftpackagemanager) or [`.other`](#other) options to create a schema module. With this approach your schema types will be `public` top-level symbols in a module using the provided `schemaNamespace` as the module name. From c0c491b0e70e5a5901c2f7f2ae676648cb2b0878 Mon Sep 17 00:00:00 2001 From: Calvin Cestari Date: Mon, 23 Sep 2024 17:01:04 -0700 Subject: [PATCH 2/4] Fix repo test link --- docs/source/fetching/fetching-data.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/source/fetching/fetching-data.mdx b/docs/source/fetching/fetching-data.mdx index 74364a4ed..6f8586cc0 100644 --- a/docs/source/fetching/fetching-data.mdx +++ b/docs/source/fetching/fetching-data.mdx @@ -191,7 +191,7 @@ The cache polices which you can specify are: - This is the most common use case, and is the most performant method if your data is not expected to change. - If you do not need to check for updates to data once it's been fetched, you should usually use this cache policy. -> If you're interested in returning cached data after a failed fetch, the current recommended approach is to use an `additionalErrorInterceptor` on your interceptor chain to examine if the error is one it makes sense to show old data for rather than something that needs to be passed on to the user, and then retrying with a `.returnCacheDataDontFetch` retry policy. An example of this setup can be found in the [Cache-dependent interceptor tests](https://github.com/apollographql/apollo-ios/blob/main/Tests/ApolloTests/Cache/CacheDependentInterceptorTests.swift). +> If you're interested in returning cached data after a failed fetch, the current recommended approach is to use an `additionalErrorInterceptor` on your interceptor chain to examine if the error is one it makes sense to show old data for rather than something that needs to be passed on to the user, and then retrying with a `.returnCacheDataDontFetch` retry policy. An example of this setup can be found in the [Cache-dependent interceptor tests](https://github.com/apollographql/apollo-ios-dev/blob/main/Tests/ApolloTests/Cache/CacheDependentInterceptorTests.swift). For more information on how result data is stored in the cache data or how to configure the normalized cache, see the [Caching documentation](./../caching/introduction). From 7130b412b2d3d83522982ab8fd53acebfaf2c1de Mon Sep 17 00:00:00 2001 From: Calvin Cestari Date: Mon, 23 Sep 2024 17:01:12 -0700 Subject: [PATCH 3/4] Fix API reference link --- docs/source/caching/cache-key-resolution.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/source/caching/cache-key-resolution.mdx b/docs/source/caching/cache-key-resolution.mdx index cd06c073e..da6294ceb 100644 --- a/docs/source/caching/cache-key-resolution.mdx +++ b/docs/source/caching/cache-key-resolution.mdx @@ -88,7 +88,7 @@ If the JSON response `object` has no `id` field, the function returns `nil` and #### JSON value convenience initializer -Alternatively, you can use the [`init(jsonValue:uniqueKeyGroup:)`](https://www.apollographql.com/docs/ios/docc/documentation/apolloapi/cachekeyinfo/init(jsonvalue:uniquekeygroupid:)) convenience initializer. This initializer attempts to use the value of a key in the JSON response, throwing an error if the key does not exist. +Alternatively, you can use the [`init(jsonValue:uniqueKeyGroup:)`](https://www.apollographql.com/docs/ios/docc/documentation/apolloapi/cachekeyinfo/init(jsonvalue:uniquekeygroup:)) convenience initializer. This initializer attempts to use the value of a key in the JSON response, throwing an error if the key does not exist. If you want to return `nil` when the value does not exist, you can use `try?`. From c9236a6f385a1529a96d3ecc70d4d9703ed99c09 Mon Sep 17 00:00:00 2001 From: Calvin Cestari Date: Wed, 25 Sep 2024 10:47:20 -0700 Subject: [PATCH 4/4] Update dead links --- docs/source/fetching/operation-arguments.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/source/fetching/operation-arguments.mdx b/docs/source/fetching/operation-arguments.mdx index 254c1eefc..1e1c9a5e0 100644 --- a/docs/source/fetching/operation-arguments.mdx +++ b/docs/source/fetching/operation-arguments.mdx @@ -4,7 +4,7 @@ title: Operation Arguments GraphQL operations can define arguments as part of their definitions, the values of these arguments can be passed to field arguments or directive arguments (eg. `@skip` and `@include`). -Apollo iOS generates type-safe initializers for your operation that accept your operation's arguments. These arguments can be [built-in scalar types](https://graphql.org/learn/schema/#scalar-types), [custom scalars](./../custom-scalars), [enums](./../enums), or [input objects](./../input-objects) defined in your schema. +Apollo iOS generates type-safe initializers for your operation that accept your operation's arguments. These arguments can be [built-in scalar types](https://graphql.org/learn/schema/#scalar-types), [custom scalars](./../custom-scalars), [enums](https://graphql.org/learn/schema/#enumeration-types), or [input objects](https://graphql.org/learn/schema/#input-types) defined in your schema. Let's say we define a GraphQL query named `HeroName` with an `episode` argument which is a custom `Episode` enum defined in our schema: