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: Use public modifier only when required by module type #2313

Merged
merged 17 commits into from
Jun 14, 2022

Conversation

calvincestari
Copy link
Member

PR 1 of x for #2302 (Test mocks are still broken and require use of the namespace when .embeddedInTarget is used)

This PR now assesses the module type and only adds the public modifier when a module is generated for the schema types. When the schema types are embedded within an existing target and automatically namespaced the public modifier is redundant and generates compiler warnings on build.

@netlify
Copy link

netlify bot commented Jun 13, 2022

Deploy Preview for apollo-ios-docs ready!

Name Link
🔨 Latest commit f71d41d
🔍 Latest deploy log https://app.netlify.com/sites/apollo-ios-docs/deploys/62a8ff7088165000089c075f
😎 Deploy Preview https://deploy-preview-2313--apollo-ios-docs.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site settings.

@@ -111,6 +111,14 @@ extension TemplateRenderer {
"""
).description
}

func embeddedAccessControlModifier(
Copy link
Member Author

Choose a reason for hiding this comment

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

This and the call sites into this function are the only relevant pieces of this change. The rest is passing the shared configuration reference around and formatting.

Copy link
Contributor

Choose a reason for hiding this comment

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

At this point, are there even any TemplateRenderers left that don't need a reference to the config? I think we should just make config a property on the TemplateRenderer protocol. Then we could change this from a function you need to pass config into and just make it a computed property on the protocol.

All the functions above this become a lot cleaner too. This doesn't need to happen today to get this PR in. Since we wanna push the release ASAP. But I think i'm going to make that change sometime this week.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes it would be a good change to get it into TemplateRenderer as you mentioned. It started out that not many templates needed to reference the configuration but it's way more complicated now.

@calvincestari
Copy link
Member Author

Changing this to a draft PR because I need to rebase it on top of #2312 and catch up on the new/updated templates.

@calvincestari calvincestari marked this pull request as draft June 14, 2022 00:15
@calvincestari calvincestari changed the base branch from release/1.0 to 1.0/fragment-conditions June 14, 2022 03:27
@calvincestari calvincestari force-pushed the 1.0/2302-public-modifiers branch from 224daf3 to a7878d4 Compare June 14, 2022 04:41
@@ -111,6 +111,14 @@ extension TemplateRenderer {
"""
).description
}

func embeddedAccessControlModifier(
Copy link
Contributor

Choose a reason for hiding this comment

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

At this point, are there even any TemplateRenderers left that don't need a reference to the config? I think we should just make config a property on the TemplateRenderer protocol. Then we could change this from a function you need to pass config into and just make it a computed property on the protocol.

All the functions above this become a lot cleaner too. This doesn't need to happen today to get this PR in. Since we wanna push the release ASAP. But I think i'm going to make that change sometime this week.

Base automatically changed from 1.0/fragment-conditions to 1.0/generate-local-mutations June 14, 2022 18:23
Base automatically changed from 1.0/generate-local-mutations to release/1.0 June 14, 2022 20:29
@calvincestari calvincestari force-pushed the 1.0/2302-public-modifiers branch from a7878d4 to 58ed1c8 Compare June 14, 2022 21:14
@calvincestari calvincestari force-pushed the 1.0/2302-public-modifiers branch from d048665 to f71d41d Compare June 14, 2022 21:36
@calvincestari calvincestari marked this pull request as ready for review June 14, 2022 21:44
@calvincestari calvincestari merged commit 12f697f into release/1.0 Jun 14, 2022
@calvincestari calvincestari deleted the 1.0/2302-public-modifiers branch June 14, 2022 21:44
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.

2 participants