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

Networking Beta #1386

Merged
merged 153 commits into from
Sep 29, 2020
Merged

Networking Beta #1386

merged 153 commits into from
Sep 29, 2020

Conversation

designatednerd
Copy link
Contributor

@designatednerd designatednerd commented Sep 11, 2020

Future changes to the networking stack will get merged into this until it comes out of beta (hopefully soon). Opening a PR to get Netlify to auto-generate updated docs that can be referenced here.

Please note:

  • If you're opening a bug about the networking beta, please prefix the bug title with Networking Beta: - this will help me narrow down where things are going wrong more quickly.
  • If you're using the beta, please check the CHANGELOG from this branch for updates.
  • Updated documentation and code are available here: https://deploy-preview-1386--apollo-ios-docs.netlify.app/docs/ios/
  • The code changes to the tutorial are available in the Tutorial Repo on the new-network-beta branch.

The problem is: the `additionalErrorInterceptor(for:)` function is never called, if the `InterceptorProvider` class in use is a subclass of any `InterceptorProvider` that *does not* declare the `additionalErrorInterceptor` function.

For example, consider this `CustomInterceptor` type:
```swift
class CustomInterceptor: LegacyInterceptorProvider {
  // Note that we don't use `override` here.
  func additionalErrorInterceptor<Operation>(for operation: Operation) -> ApolloErrorInterceptor? where Operation : GraphQLOperation {
    ErrorInterceptor()
  }
}
```

Its superclass, `LegacyInterceptorProvider`, does not provide an implementation of `additionalErrorInterceptor(for:)`, relying instead on the default implementation that returns `nil`.
Since its superclass does not implement this function, the implementation in `CustomInterceptor` is not overriding it, but declaring it anew. For some 🤯 reason, this means that the implementation that provides the `additionalErrorInterceptor` is never called. The default implementation in the extension of the `InterceptorProvider` protocol is called instead, returning `nil`.

I suggest 2 small changes to solve this issue, and remove this trap.
- Remove the default implementation of `additionalErrorInterceptor(for:)` from `extension InterceptorProvider`. This will force base classes to implement it; the library expects the user to subclass one of the provided InterceptorProviders anyway, so I think it's acceptable.
- Implement `additionalErrorInterceptor(for:)` in both `LegacyInterceptorProvider` and `CodableInterceptorProvider`, so that subclasses will have something to override, but keeping the nice `nil` default.

These changes make for a pretty smooth solution, with only one small breaking change: `InterceptorProvider`s that did implement `additionalErrorInterceptor(for:)` before this change will have to add the `override` keyword, if they inherited from one of the provided `InterceptorProvider`s.
@heyzooi
Copy link
Contributor

heyzooi commented Sep 25, 2020

hi @designatednerd, I'm wondering if you have an estimate release date for a new version including this PR?

Tiziano Coroneo added 2 commits September 26, 2020 14:46
@designatednerd
Copy link
Contributor Author

@heyzool - Hoping for monday evening if nobody finds any showstoppers

…-additional-error-handler-bug

[Networking Stack] `additionalErrorInterceptor(for:)` doesn't work when subclassing `LegacyInterceptorProvider`
Adding the operation type to the request headers
@designatednerd designatednerd merged commit cbb9a36 into main Sep 29, 2020
@designatednerd designatednerd deleted the betas/networking-stack branch September 30, 2020 00:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants