Use Closures Not Delegates | Swift 5, Xcode 10

Today we cover why I think you should consider using closures instead of delegates. We will go over a common example of where delegates are used and I will explain how to convert that example to a closure/callback style.

By the end of this video, you will know how to use and create your own closures, replace delegates with those closures, and know when to use closures over delegates.

*** Show Notes and Links ***

Need Help?

Project Files:

Kyle Lee on Social Media:



---------GEAR -------

Code Passionately T-Shirt

Laptop - 2017 MacBook Pro

Microphone - PowerDeWise Lavalier Microphone

DISCLAIMER: This video and description contains affiliate links, which means that if you click on one of the product links, we’ll receive a small commission. This helps support the channel and allows us to continue to make videos like this. Thank you for the support!

[easyabe]

Omg I finally understand closures now! This was exactly the thing I needed. Gonna replace all my single function protocols with this

[Nightsd]

Completely disagree. Protocols are a lot more powerful and flexible than just passing closures all over the place. And the memory management model for you typical delegate pattern is a lot simpler.

For simple things like network requests a closure is fine. But for everything else a delegate greatly improves separation of concerns and you don’t have to worry as much about how a closure will implicitly capture references and possibly cause memory leaks.

It gets even worse if you start using closures all over the place and start nesting them, makes your code much harder to read.

[jhogue]

OMG thank you for this example, I've been struggling to change from the delegate method to this!!

[gwapster]

Neat solution. This is pretty much how it works on web/javascript and I’ve always found it much simpler than Swift delegates.

[jasonkendall]

Been following you for a few years now man, always great content!

[Fullstackdesign]

I guess it also depends on the context of when you should and shouldn't use the delegator pattern. Using delegates creates a "tether" that helps abstract the details of the class you want to communicate to. Whereas in a closure you need a concrete representation of the class to access the information passed to the closure thus exposing all of the inner workings of said class.


In summary, a delegate is great for abstracting the communication between two objects.
I.E. object A should not know or care about object B. The communication is implicit/decoupled:
A- - - - Delegate- - - -B


In a closure, object A needs a concrete representation of object B.

[fernandomontes]

I knew there was a easier way of handling these situations than using delegates, but I didn't know how. Thank you for making this video, I will be implementing this in my projects!

[markuspfeifer]

Exact same opinion here. I use closures even for forms: a form declares the data that can be passed in, and then you have a submit button. What I do there is to pass the current values in the form as arguments to a closure provided by whichever class created the form. Very handy pattern for UIKit where you don’t have bindings, still useful in SwiftUI where you can keep your stored data elsewhere but still need to know if the closure was called. I wonder if the planned multiple trailing closures help mitigate the need for delegates in more complex scenarios.

[CASMANWHAT]

Thx Kilo! U da I come from a JS background so i love this closure talk.

[milolajzelichowski]

thx for good knowladge ! 2 days i spent for looking for about good way with use closure !:)

[karimahmed]

What if ---- var didTapNoise:((Animal) -> Bool)? How could we send them in the button action ?

[Eugene.Berezin]

Very nice!
I agree code is more DRY and clean with closures.

[joet]

Came to see if this had anything to do with protocols containing a single function (I too wondered how I could get around having to create a delegate just to utilize a single function).... BUT I stayed because of "poop". True Story. Subscribed.

[iosmayank]

I also prefer using closures over delegates majority of times :)

[ravikirangajula]

great video, great explanation
but left with one question
animalCell?.didTapNoise = { [weak self] animal in
//some code
}
we are using weak reference here to avoid retain cycles
but what will happen in below case
animalCell?.didTapNoise = didTapNoise

[domainxh]

Excellent video, I think you made a great point about delegate vs closure. For simple projects like this, I would definitely be leaning more towards closure. Though I think for both cases, you have to watch out for retain cycles, as that is the reason why you put down [weak self] inside of the closure, and likewise weak var for the delegate.
Subscribed :)

[donathmm]

that's so awesome!!! So much better and less code!! How did you made the errors so pretty on 6:58 that looks different

[subinkk]

Great one . Need to change my old codes 😀👍

[TheFloydPinkus]

Another great video. I really enjoy watching your videos and I sure do learn a lot.

[VeryBlueBot]

Interesting. Im new to Swift and thought that delegate is the "Swift" way.. Using closures is basically
callbacks like in any other language (with some synthetic sugar)
Also, in React and React native (also in Angular in way) you can pass functions as properties to
child nodes and then only trigger them from the child node (class)
using only this patter things can get really ugly when there are a deep drill down you trying to pass
My question is - how do you prevent "callback hell" with more complex code?
Love your vids - very helpful and clear :) thanks