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

SPM Prep – Move some async perform types at the WordPressComRESTAPIInterface level #788

Open
wants to merge 17 commits into
base: trunk
Choose a base branch
from

Conversation

mokagio
Copy link
Contributor

@mokagio mokagio commented Apr 12, 2024

Description

This was part of #784 but I've been asked to wait on the actual extension removal because of conflicting WIP work.

All these changes should be fine to merge regardless, as are mostly about changing access control, injecting new params, and moving methods at the protocol level.

Testing Details

See CI.


  • Please check here if your pull request includes additional test coverage. — N.A.
  • I have considered if this change warrants release notes and have added them to the appropriate section in the CHANGELOG.md if necessary. — N.A.

@mokagio mokagio changed the title Move some async perform types at the WordPressComRESTAPIInterface level SPM Prep – Move some async perform types at the WordPressComRESTAPIInterface level Apr 12, 2024

@property (strong, nonatomic, readonly) NSURLSession * _Nonnull urlSession;

@property (strong, nonatomic, readonly) void (^ _Nullable invalidTokenHandler)(void);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

All these properties went in the protocol to make the async perform methods work.

The async perform methods, which like in WordPressComRestApi are Swift-only, of course.

I considered using an extension or a different protocol, but it seemed neat to have it all in WordPressComRESTAPIInterfacing, so that Swift code can used an upgraded version of the same interface that the Objective-C code uses. This will actually be useful in the cases where we have an ObjC superclass with the API client conforming to WordPressComRESTAPIInterfacing and a subclass using the API client, too.

self.parameters = parameters
}

public func encode(to encoder: Encoder) throws {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

When the type became public, a public init became necessary because the compiler does not synthesize one outside of the package.

As for encode(to:), it needs to be public because Encodable is declared as part of the public type interface.

🤔 In hindsight, I suppose the Encodable part could be moved into an internal extension, but I think it's okay to leave it as is. Let me know if you can think of a strong reason to hide it.

/// Other error occured.
case unknown(underlyingError: Error)

static func unparsableResponse(response: HTTPURLResponse?, body: Data?) -> Self {
return WordPressAPIError<EndpointError>.unparsableResponse(response: response, body: body, underlyingError: URLError(.cannotParseResponse))
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I didn't look up when, but relatively recently, I think, Swift acquired default values for associated parameters. So we can remove this builder method in favor of defining the underlying error as a default for the case.

@@ -173,9 +177,6 @@ open class WordPressComRestApi: NSObject {
}
}

@objc func setInvalidTokenHandler(_ handler: @escaping () -> Void) {
invalidTokenHandler = handler
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Became redundant once invalidTokenHandler became a property in the protocol.

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.

1 participant