Skip to content
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

Fix unqualified scalar collision #2757

Merged
merged 4 commits into from
Jan 9, 2023
Merged

Conversation

AnthonyMDev
Copy link
Contributor

@AnthonyMDev AnthonyMDev commented Jan 6, 2023

Fixes #2691

Always qualify names of shared schema types referenced as the types of fields in selections sets. This prevents collisions with names of other generated selection sets for entity type fields whose names are the same as a referenced schema type.

This namespaces enums, custom scalars, and input objects.

@netlify
Copy link

netlify bot commented Jan 6, 2023

Deploy Preview for apollo-ios-docs canceled.

Name Link
🔨 Latest commit 931d111
🔍 Latest deploy log https://app.netlify.com/sites/apollo-ios-docs/deploys/63b8a93d4f9fed00091cec79

Copy link
Member

@calvincestari calvincestari left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good - thanks. Just one question about the path for test mock rendering.

replacingNamedTypeWith newTypeName: String? = nil,
config: ApolloCodegenConfiguration
) -> String {
lazy var typeName = { newTypeName ?? self.swiftName.firstUppercased }()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't need to change, my question is more out of curiosity.

Is there a benefit to typeName and schemaModuleName being defined as lazy? The return references both of them; it doesn't look like there is a logic path where they wouldn't be used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, there isn't anymore. In the old implementation, there we're paths that did not call them. So this is just a carryover from that. We can change these to let


default:
switch context {
case .testMockField, .inputValue:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

renderedAsTestMockField doesn't look like it flows through this new logic - should it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test mock one works as intended and I just decided not to mess with it to get this PR out. Next time there is a reason to make changes to that rendering, we may want to consider using this function, but I didn't want to break something else that was working at the moment.

@@ -0,0 +1,11 @@
# Overview
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍🏻 - we'll get the test infrastructure written up to keep us honest on these, glad we've got this context and won't be losing anything. Nice work!

@AnthonyMDev AnthonyMDev merged commit e8f30b7 into main Jan 9, 2023
@AnthonyMDev AnthonyMDev deleted the fix-unqualified-scalar-collision branch January 9, 2023 20:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Naming collision with fragments and scalars.
2 participants