Initial Alamofire Combine Support!

Related Projects Alamofire
1

Based on work by an Apple engineer (whose name I can’t remember) in the labs at WWDC, I've pushed a branch containing a few initial bits of support of Combine support for Alamofire. This includes:

  • Request, a Publisher to transform URLRequests into Alamofire DataRequests. This will eventually be enhanced with support for our URLRequestConvertible protocol.
  • Response, a Publisher which adds a responseDecodable handler to a DataRequest and passes along the DataResponse<T>.

This allows for easy creation and response handling using Combine and Alamofire:

// When
let urlRequest = URLRequest.makeHTTPBinRequest()

_ = Publishers.Just(urlRequest)
    .request()
    .response(of: HTTPBinResponse.self)

Combine also makes it trivial to wait for the results of multiple requests, so thanks to @Tony_Parker and the Foundation team for such a commonly requested feature.

Ongoing issues include the lack the cancellation support, and there could be some queue hops internally, as the Alamofire response callback is called on a custom queue.

This can be tried out on the initial-combine-support branch of Alamofire.

4 Likes
2

Hi @Jon_Shier, thanks for sharing!

It looks like the Request and Response publiishers are defined in the Combine.Publishers namespace. What do you think, is it a safe good practice that most Combine-based libraries should follow? What if generic names like Request or Response clash with another library?

3

They’re actually in an AF enum inside Publishers. But the method names themselves may need to go in our namespace, but the type requirements may let the overrides work.

Also, this is largely a prototype and won’t ship as is, as I would like more community and Apple input, as well as refining the actual APIs.

4

You're right, I missed it. AF is quite particular, you may well be safe.

This is exactly why I asked :-)

1 Like