Guarantees in Swift for inexperienced persons

Sync vs async execution

Writing asynchronous code is likely one of the hardest a part of constructing an app.

What precisely is the distinction between a synchronous and an asynchronous execution? Nicely, I already defined this in my Dispatch framework tutorial, however here’s a fast recap. A synchoronousoperate often blocks the present thread and returns some worth afterward. An asynchronousoperate will immediately return and passes the consequence worth right into a completion handler. You should use the GCD framework to carry out duties sync on async on a given queue. Let me present you a fast instance:

func aBlockingFunction() -> String {
    sleep(.random(in: 1...3))
    return "Whats up world!"
}

func syncMethod() -> String {
    return aBlockingFunction()
}

func asyncMethod(completion block: @escaping ((String) -> Void)) {
    DispatchQueue.world(qos: .background).async {
        block(aBlockingFunction())
    }
}

print(syncMethod())
print("sync methodology returned")
asyncMethod { worth in
    print(worth)
}
print("async methodology returned")

As you’ll be able to see the async methodology runs completely on a background queue, the operate will not block the present thread. This is the reason the async methodology can return immediately, so you will at all times see the return output earlier than the final good day output. The async methodology’s completion block is saved for later execution, that is the rationale why is it doable to call-back and return the string worth means after the unique operate have returned.

What occurs when you do not use a special queue? The completion block shall be executed on the present queue, so your operate will block it. It is going to be considerably async-like, however in actuality you are simply shifting the return worth right into a completion block.

func syncMethod() -> String {
    return "Whats up world!"
}

func fakeAsyncMethod(completion block: ((String) -> Void)) {
    block("Whats up world!")
}

print(syncMethod())
print("sync methodology returned")
fakeAsyncMethod { worth in
    print(worth)
}
print("pretend async methodology returned")

I do not actually wish to concentrate on completion blocks on this article, that may very well be a standalone put up, however in case you are nonetheless having hassle with the concurrency mannequin or you do not perceive how duties and threading works, it’s best to learn perform a little analysis first.

Callback hell and the pyramid of doom

What is the downside with async code? Or what’s the results of writing asynchronous code? The quick reply is that it’s important to use completion blocks (callbacks) with a view to deal with future outcomes.

The lengthy reply is that managing callbacks sucks. It’s important to watch out, as a result of in a block you’ll be able to simply create a retain-cycle, so it’s important to go round your variables as weak or unowned references. Additionally if it’s important to use a number of async strategies, that’ll be a ache within the donkey. Pattern time! 🐴

struct Todo: Codable {
    let id: Int
    let title: String
    let accomplished: Bool
}

let url = URL(string: "https://jsonplaceholder.typicode.com/todos")!

URLSession.shared.dataTask(with: url) { knowledge, response, error in
    if let error = error {
        fatalError("Community error: " + error.localizedDescription)
    }
    guard let response = response as? HTTPURLResponse else {
        fatalError("Not a HTTP response")
    }
    guard response.statusCode <= 200, response.statusCode > 300 else {
        fatalError("Invalid HTTP standing code")
    }
    guard let knowledge = knowledge else {
        fatalError("No HTTP knowledge")
    }

    do {
        let todos = strive JSONDecoder().decode([Todo].self, from: knowledge)
        print(todos)
    }
    catch {
        fatalError("JSON decoder error: " + error.localizedDescription)
    }
}.resume()

The snippet above is an easy async HTTP knowledge request. As you’ll be able to see there are many non-compulsory values concerned, plus it’s important to do some JSON decoding if you wish to use your personal sorts. This is only one request, however what when you’d must get some detailed data from the primary component? Let’s write a helper! #no 🤫

func request(_ url: URL, completion: @escaping ((Information) -> Void)) {
    URLSession.shared.dataTask(with: url) { knowledge, response, error in
        if let error = error {
            fatalError("Community error: " + error.localizedDescription)
        }
        guard let response = response as? HTTPURLResponse else {
            fatalError("Not a HTTP response")
        }
        guard response.statusCode <= 200, response.statusCode > 300 else {
            fatalError("Invalid HTTP standing code")
        }
        guard let knowledge = knowledge else {
            fatalError("No HTTP knowledge")
        }
        completion(knowledge)
    }.resume()
}


let url = URL(string: "https://jsonplaceholder.typicode.com/todos")!
request(url) { knowledge in
    do {
        let todos = strive JSONDecoder().decode([Todo].self, from: knowledge)
        guard let first = todos.first else {
            return
        }
        let url = URL(string: "https://jsonplaceholder.typicode.com/todos/(first.id)")!
        request(url) { knowledge in
            do {
                let todo = strive JSONDecoder().decode(Todo.self, from: knowledge)
                print(todo)
            }
            catch {
                fatalError("JSON decoder error: " + error.localizedDescription)
            }
        }
    }
    catch {
        fatalError("JSON decoder error: " + error.localizedDescription)
    }
}

See? My downside is that we’re slowly shifting down the rabbit gap. Now what if we now have a third request? Hell no! It’s important to nest every little thing one stage deeper once more, plus it’s important to go across the essential variables eg. a weak or unowned view controller reference as a result of in some unspecified time in the future in time it’s important to replace your complete UI based mostly on the result. There have to be a greater technique to repair this. 🤔

Outcomes vs futures vs guarantees?

The consequence sort was launched in Swift 5 and it is extraordinarily good for eliminating the non-compulsory issue from the equation. This implies you do not have to take care of an non-compulsory knowledge, and an non-compulsory error sort, however your result’s both of them.

Futures are mainly representing a worth sooner or later. The underlying worth may be for instance a consequence and it ought to have one of many following states:

• pending – no worth but, ready for it…
• fulfilled – success, now the consequence has a worth
• rejected – failed with an error

By definition a futures should not be writeable by the end-user. Which means that builders shouldn’t be capable of create, fulfill or reject one. But when that is the case and we observe the principles, how can we make futures?

We promise them. It’s important to create a promise, which is mainly a wrapper round a future that may be written (fulfilled, rejected) or remodeled as you need. You do not write futures, you make guarantees. Nevertheless some frameworks means that you can get again the long run worth of a promise, however you should not have the ability to write that future in any respect.

Sufficient idea, are you able to fall in love with guarantees? ❤️

Guarantees 101 – a newbie’s information

Let’s refactor the earlier instance by utilizing my promise framework!

extension URLSession {

    enum HTTPError: LocalizedError {
        case invalidResponse
        case invalidStatusCode
        case noData
    }

    func dataTask(url: URL) -> Promise<Information> {
        return Promise<Information> { [unowned self] fulfill, reject in
            self.dataTask(with: url) { knowledge, response, error in
                if let error = error {
                    reject(error)
                    return
                }
                guard let response = response as? HTTPURLResponse else {
                    reject(HTTPError.invalidResponse)
                    return
                }
                guard response.statusCode <= 200, response.statusCode > 300 else {
                    reject(HTTPError.invalidStatusCode)
                    return
                }
                guard let knowledge = knowledge else {
                    reject(HTTPError.noData)
                    return
                }
                fulfill(knowledge)
            }.resume()
        }
    }
}

enum TodoError: LocalizedError {
    case lacking
}

let url = URL(string: "https://jsonplaceholder.typicode.com/todos")!
URLSession.shared.dataTask(url: url)
.thenMap { knowledge in
    return strive JSONDecoder().decode([Todo].self, from: knowledge)
}
.thenMap { todos -> Todo in
    guard let first = todos.first else {
        throw TodoError.lacking
    }
    return first
}
.then { first in
    let url = URL(string: "https://jsonplaceholder.typicode.com/todos/(first.id)")!
    return URLSession.shared.dataTask(url: url)
}
.thenMap { knowledge in
    strive JSONDecoder().decode(Todo.self, from: knowledge)
}
.onSuccess { todo in
    print(todo)
}
.onFailure(queue: .most important) { error in
    print(error.localizedDescription)
}

What simply occurred right here? Nicely, I made type of a promisified model of the information process methodology carried out on the URLSession object as an extension. In fact you’ll be able to return the HTTP consequence or simply the standing code plus the information when you want additional data from the community layer. You should use a brand new response knowledge mannequin or perhaps a tuple. 🤷‍♂️

Anyway, the extra attention-grabbing half is the underside half of the supply. As you’ll be able to see I am calling the model new dataTask methodology which returns a Promise<Information> object. As I discussed this earlier than a promise may be remodeled. Or ought to I say: chained?

Chaining guarantees is the largest benefit over callbacks. The supply code is just not trying like a pyramid anymore with loopy indentations and do-try-catch blocks, however extra like a sequence of actions. In each single step you’ll be able to rework your earlier consequence worth into one thing else. In case you are aware of some useful paradigms, it’ll be very easy to grasp the next:

• thenMap is an easy map on a Promise
• then is mainly flatMap on a Promise
• onSuccess solely will get known as if every little thing was nice within the chain
• onFailure solely will get known as if some error occurred within the chain
• at all times runs at all times whatever the consequence

If you wish to get the primary queue, you’ll be able to merely go it by way of a queue parameter, like I did it with the onFailure methodology, but it surely works for each single component within the chain. These features above are simply the tip of the iceberg. It’s also possible to faucet into a sequence, validate the consequence, put a timeout on it or recuperate from a failed promise.

There’s additionally a Guarantees namespace for different helpful strategies, like zip, which is able to zipping collectively 2, 3 or 4 completely different type of guarantees. Similar to the Guarantees.all methodology the zip operate waits till each promise is being accomplished, then it provides you the results of all the guarantees in a single block.

Guarantees.all(guarantees)
.thenMap { arrayOfResults in
    
}

Guarantees.zip(promise1, promise2)
.thenMap { result1, result2 in
    
}

It is also price to say that there’s a first, delay, timeout, race, wait and a retry methodology below the Guarantees namespace. Be at liberty to mess around with these as properly, generally they’re extremly helpful and highly effective too. 💪

There are solely two issues with guarantees

The primary situation is cancellation. You may’t merely cancel a working promise. It is doable, but it surely requires some superior or some say “hacky” strategies.

The second is async / await. If you wish to know extra about it, it’s best to learn the concurrency manifesto by Chis Lattner, however since this can be a newbie’s information, let’s simply say that these two key phrases can add some syntactic sugar to your code. You will not want the additional (then, thenMap, onSuccess, onFailure) strains anymore, this fashion you’ll be able to focus in your code. I actually hope that we’ll get one thing like this in Swift 6, so I can throw away my Promise library for good. Oh, by the way in which, libraries…

Promise libraries price to verify

My promise implementation is much from good, but it surely’s a fairly easy one (~450 strains of code) and it serves me very well. This weblog put up by @khanlou helped me quite a bit to grasp guarantees higher, it’s best to learn it too! 👍

There are many promise libraries on github, but when I had to select from them (as an alternative my very own implementation), I would positively go together with one of many following ones:

• PromiseKit – The preferred one
• Guarantees by Google – characteristic wealthy, fairly in style as properly
• Promise by Khanlou – small, however based mostly on on the JavaScript Guarantees/A+ spec
• SwiftNIO – not an precise promise library, but it surely has a fantastically written occasion loop based mostly promise implementation below the hood

Professional tip: do not attempt to make your personal Promise framework, as a result of multi-threading is extraordinarily exhausting, and you do not wish to fiddle with threads and locks.

Guarantees are actually addictive. When you begin utilizing them, you’ll be able to’t merely return and write async code with callbacks anymore. Make a promise right this moment! 😅