Delete unused imports and declarations

[Iron-Ham]

Closes #3099

[netlify]

👷 Deploy request for apollo-ios-docs pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	eee71b7

[AnthonyMDev]

@calvincestari have you ever seen this Circle CI error before?

[calvincestari]

The OAuth error? I've only seen that one when Apollo changed security config and we had to remove/add our auths. Should have been resolved a while ago. Try running it again.

[Iron-Ham]

Don't think that's something I can do on my end

[calvincestari]

I'm limited to mobile till the weekend but I don't think this is anything wrong in your PR.

[calvincestari]

I've followed up with our security team to see if we can figure out what is going on, it appears limited to forked repo contributions so let's see what they come back with. I'll update you once I learn more.

[calvincestari]

OK @Iron-Ham, it looks like it got a bit further with that empty commit I pushed. I've been told that you should try fully logging out of GitHub to see if that helps? In the past I followed these steps for CircleCI but you wouldn't have those credentials so I'm hoping the GH logout/login will resolve it for you.

[Iron-Ham]

@calvincestari hopefully that does it? Double-checked if I had some old CircleCI tokens on my account from previous jobs but no dice.

[calvincestari]

It looks like your fork might be quite far behind the upstream. I'm guessing that's the reason for the failed tests?

This branch is 4 commits ahead of, 45 commits behind apollographql/apollo-ios:main.

[Iron-Ham]

@calvincestari merged with main -- could you try an empty commit again?

[calvincestari]

Thanks for the cleanup PR @Iron-Ham. The import removal looks good, I'm less certain about the RawData type changes though.

@AnthonyMDev it looks like the opaqueObjectDataWrapper should have been using the RawData type alias to create the consistency we were looking for - can you confirm that please. I can't find any other reference to them so we either use that type in the function declaration or remove the type alias.

[Iron-Ham]

@calvincestari the RawData aliases were fully unused outside of their declaration – and I was torn between either removing them fully, or inferring that it should have been used in the files that they were declared in.

[calvincestari]

or inferring that it should have been used in the files that they were declared in.

I think this is the right choice. My opinion is to use them because it creates the consistency when reading the code that we wanted to achieve with that change, even if they have different types under the hood.

[AnthonyMDev]

I've been hesitant to remove Foundation imports because I've had situations in the past where code compiled in Xcode for our project after removing them, but then when actually included in someone else's project as a package (I think w/CocoaPods?) they would fail to compile.

I think this has to do with umbrella headers or something where Foundation was always being linked against targets due to our project configuration, but that wasn't the case when consumed as a package.

If the files really don't use Foundation then this is fine, which I'm assuming is the case because the static analyzer only identified some specific import statements to be removed. So I'm okay with this change.

---

The RawData was supposed to be a typealias that explictly declares the type for the GraphQLExecutionSource protocol's associated type. At some point, I changed the associated type name from RawData to RawObjectData. Now the compiler is having to infer the associated type from the function signatures.

I think the proper fix would be to change the typealiases to RawObjectData, but I think it's still easier to read and reason about the code by leaving the references in the actual function signatures and implementations as the direct type. The point of the typealiases in the first place was just to give the compiler the explicit information it needed to shave nanoseconds off of compilation time. 😅

[calvincestari]

I think the proper fix would be to change the typealiases to RawObjectData, but I think it's still easier to read and reason about the code by leaving the references in the actual function signatures and implementations as the direct type. The point of the typealiases in the first place was just to give the compiler the explicit information it needed to shave nanoseconds off of compilation time. 😅

Good to know, thanks for that context. It appears that RawObjectData is correctly used in CacheDataExecutionSource already so I'm going to update the two other sources and then I think we can get this merged.