-
Notifications
You must be signed in to change notification settings - Fork 57
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
feature(defer): Code generation #219
feature(defer): Code generation #219
Conversation
@@ -538,13 +568,22 @@ struct SelectionSetTemplate { | |||
let isOptional = | |||
fragment.inclusionConditions != nil | |||
&& !scope.matches(fragment.inclusionConditions.unsafelyUnwrapped) | |||
let isDeferred = fragment.typeInfo.deferCondition != nil | |||
|
|||
return """ |
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 think we might be at the point where it makes sense to break this function into smaller focused functions.
@@ -18,7 +18,7 @@ public class NamedFragmentSpread: Hashable, CustomDebugStringConvertible { | |||
/// Indicates the location where the fragment has been "spread into" its enclosing | |||
/// operation/fragment. It's `scopePath` and `entity` reference are scoped to the operation it | |||
/// belongs to. | |||
let typeInfo: SelectionSet.TypeInfo | |||
public let typeInfo: SelectionSet.TypeInfo |
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.
Is there any reason this shouldn't be a public constant? Doing so matches what we make available on InlineFragment
and means we don't need to have a public method just to get at deferCondition
. The type info is also used in the deferred fragment metadata template, but that may change.
a5fa3e9
to
58a7894
Compare
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.
Be sure to handle these two items in this PR too: |
…ing-defer-codegen # Conflicts: # Tests/ApolloCodegenTests/CodeGenIR/IRRootFieldBuilderTests.swift # Tests/ApolloTests/GraphQLResultTests.swift # Tests/ApolloTests/Interceptors/IncrementalJSONResponseParsingInterceptorTests.swift # Tests/ApolloTests/Interceptors/MultipartResponseDeferParserTests.swift # apollo-ios-codegen/Sources/ApolloCodegenLib/Templates/SelectionSetTemplate.swift # apollo-ios/Sources/Apollo/AnyGraphQLResponse.swift # apollo-ios/Sources/Apollo/GraphQLResult.swift # apollo-ios/Sources/Apollo/IncrementalGraphQLResponse.swift # apollo-ios/Sources/Apollo/IncrementalJSONResponseParsingInterceptor.swift # apollo-ios/Sources/Apollo/MultipartResponseDeferParser.swift # apollo-ios/Sources/ApolloAPI/GraphQLOperation.swift
Closing this as the work has been split into PRs: |
This PR adds the missing pieces to codegen for the
@defer
implementation:@defer
on a named fragment - the template changes in this draft PR at the moment only solve for simple named fragment use cases in order to ready for a preview release. As I add the test cases I'll resolve for all use cases of deferred named fragments.There are no tests included with this PR yet, they're still coming