It’s time to start catching up with Combine!

If you’ve been with me and remember the initial breakdown using SwiftUI, here’s what I wanted to do:

We still haven’t decided on what’s the best approach to SwiftUI’s declarative way of building UI architecture-wise, but it seems to be leaning heavily towards MVVM, or at least some variant of it.

Since it seems pretty natural to use, we’re going with that.

We need to start off with several things in mind:

First things first, the view needs to read values from the state of the view model. The model will be updating its state when it receives events from the URLSession.DataTaskPublisher.

If you’re familiar with RxSwift, you’ll know that you can achieve that by binding streams of data to UI elements.

In the case of SwiftUI, it’ll actually re-render the component that needs to be updated. So, when building a list of rows and that list updates, the UI will end up adjusting itself to accommodate for the changes.

With all that in mind, let’s make a model which represents a single GitHub repository.

A simple struct with some attributes that conforms to Decodable. Those of you with a keen eye might’ve noticed something new—and that’s a protocol called Identifiable.

The only requirement of the protocol is that the object has an id, which is then used by Equatable under the hood. That’s great! But… where is it identified? SwiftUI uses it for its List element which does diffing, insertion and deletion for us.

How cool is that?! No more headaches with index paths. ?

The single most important thing to do is to conform to the BindableObject protocol. The object uses that to notify the framework when it receives changes. Changes are then sent to the view, which then updates the layout.

To satisfy the protocol, we need the didChange property, which is typed as AnyPublisher<Void, Never>. It’s pretty cool that we don’t need a concrete type, the framework only expects us to signal when there are updates in the pipeline!

Since we’re also binding to the UI, errors need to be handled before passing values to the publisher. Hence the second type, which is represented as Never.

I’ll concentrate only on the ListView and the RepositoryRowView, since the implementation is exactly the same across all of them.

ListView requires a few simple changes. Instead of a fixed range that we passed to the List initially, we’re now passing the repositories property of the model.
If Repository is not conforming to the Identifiable protocol, a convoluted error might pop up in this moment, so double check that in case of any weirdness.

All that’s left to do now is to add the Repository to the rest of the subviews.

Pretty simple, right?

The exact same thing needs to be done for both the DetailsContainerView and the StarsContainerView, so I won’t dive into that.

We’ve already started by adding a publisher that’s responsible of notifying the view about updates.

What about the changes of the actual data source, that is, the repositories array inside of the view model?
Thankfully, URLSession provides a publisher just for that!

We also need to pass any text changes from the view to the view model. It then needs to initiate an API call and provide information about the update.

Taking a look at the ListView again, we can see the @State property wrapper that’s used to track text changes.

Since we have no use of that property in the view anymore, we can move it into the model! We can use it to track changes internally and simply notify the view when we’re done.

Let’s tweak both the model and the list. We’ll start with the list since it’s simpler:

The @State var text was replaced by binding the text field to a keypath which points to the text property of the view model. Going further, let’s adjust the model now:

This concludes all the properties necessary to make the view model work! Not so bad, right?
Concentrating on said properties, we can see the following:

To elaborate, for each character input in the textfield, our internal subject will get notified through the setter of the text variable. This then initiates an API call.

That API call is going to return a cancellable which we store and call on deinit to clean up the resources when needed.

Woah, wait, what’s a subject now? Well, since I talked about publishers already—I can paraphrase that a Subject in its most simplest term is a publisher into which you’re able to write values.

Remember, publishers are read-only and are strictly used to pass data.

On the other hand, a subject can be used as a bridge between reactive and non-reactive code, since it’s able to receive data in its stream.
We’ll use that to publish text changes through the stream which will result in an API call returning the Repositories.

That’s a lot to chew through, but bear with me and let’s just pour those words into code:

If this is a bit intimidating, fret not—I’ll go over the operators to make it a bit easier to grasp.

I’ve already mentioned how we’re pushing all text changes into the _textDidChange subject.
These get sent into the flatMapLatest operator.
If you’re using the first beta of Combine, you won’t be able to find it—you need to make it.

Essentially, flatMapLatest can be derived into map and switchToLatest operators. But why do we need it?

Well, map is the same old map provided in Swift, it maps an input to a desired output. We need that to map the search String into an API call returning Repositories.
Okay… but what about the switchToLatest operator?

Imagine that you’re typing in a textfield—typing is quite fast.
For each character you type, an API call will be made. If we did that we’d absolutely trash the server with all that traffic.

This is where switchToLatest operator comes in handy. It automatically cancels any previously sent events and continues on with the latest one! That way, we only take whatever text we have for the last character coming into the stream.

Making the operator is pretty straightforward:

You might’ve also noticed the debounce operator.

Along with debounce, throttle is also one of the operators that saves lives when using RxSwift, so it’s only natural that it found its place in Combine.

So what’s so magical about it? Putting it simply, it does not let any events in the stream pass the point where debounce is placed, as long as the time between each of those events is shorter than the provided time interval.

Huh… it doesn’t sound that simple?
Think of it as a valve that is automatically shut if a stream of liquid is bigger than what the pipe can support.

So in the case where a user types fast, any character that comes before the period of 0.3 seconds has elapsed, will end up being dropped.
Once the user stops typing or slows down, events will pass freely for further processing.

This makes it perfect for text inputs because it guards against unintentional DDOS attacks and potential wrath of your sysadmins.

Last, but definitely not the least important operator used is share.

If share wasn’t used then each subscription would re-trigger an API call, or putting it simply, resources wouldn’t be shared.

Using it means that the part of the stream before the operator will get reused across all of its subscriptions, instead of getting invoked again. This avoids triggering further API calls on any of our maps, flatMaps, sinks, etc.

Remember when I mentioned that we need to notify the view on view model value changes? We’re doing it here.

Once the search event arrives (i.e. the API call finished and the data has been decoded), we’ll notify the view.
Since we also don’t care about the type here, the event is mapped into Void.

It is extremely important that any events sent towards the UI are on the Main thread. Failing to do so will result in undefined behaviour, glitches or a crash. Since we’re doing that using the didChange property, we need to move that stream to the main thread.

Thankfully, Apple provided a method to do that with Combine in beta 2. It’s done by simply calling the receive(on:) operator in the exact moment when you want to switch.

Do note that any code that executes below that will run on the thread you’ve assigned it on.

Why yes, it is! And we can do that by using the assign operator.
If you’ve used RxSwift you already guessed that this is basically its bind counterpart.

I’ll also make use of Swift 5’s new Result type and its .get() convenience method. This enables unwrapping an enum’s associated value if it exists, without requiring any conditional checks or switch statements.

However, there’s caveat that it throws if there’s no value. Thankfully, Combine has our backs—we can simply use tryMap.

Swift will raise a red light though, since all errors need to be handled before using assign.

To remedy that, we’ll need a catch operator.

It’s important to use catch when passing data to the UI or when you want to keep your stream alive and well. Unhandled errors will terminate the stream – remember, we can only get one subscription and one error event per stream.

The closure returns an error and expects a publisher back. That gives us the choice either to handle the error and return a new publisher that’ll keep the stream alive, or simply let the error through.

Since we don’t care about the error in case, returning existing repositories is fine.

Main difference compared to RxSwift is that the returned value from assign needs to be stored into _cancellable instead of being stored into a DisposeBag.

Overall usage is exactly the same, the only caveat being that we need to think about it ourselves during deinit and call cancel.

On the other hand, the default behaviour of DisposeBag can also be achieved.

If you want to do that, the returned stream needs to be wrapped into AnyCancellable, which requires a closure upon init. That closure is called upon deinit of the class that’s holding the AnyCancellable object.

In any case, depending on the approach, just be wary to call cancel if needed.

And another thing—if you’re wondering, you can do this by using an approach similar to the .subscribe(onNext:) available in RxSwift. Talking Combine though, you’ll want to use the sink operator:

And that’s it! Take a deep, relaxing breath if you’ve made it this far, we’re on the home stretch now.

What’s left to do is to cover the _getRepositories(using:existingRepositories:) method that you might have noticed all the way up there. That’s the method that’s making the API call and getting the data.

Simple networking stuff.
Creating an URLRequest and an appropriate JSONDecoder, which is then used after the dataTaskPublisher retrieves the data needed for decoding.

Speaking of decoding, a really great addition is the decode operator. It enables decoding on the fly, directly on the stream by simply passing in the decoder. This avoids us having to write all of the boilerplate decoding logic, which is always nice.

Be mindful though, since decoding can also throw.

Lastly, the publisher is type erased so that we lose all those wrapping publisher types (the same thing already seen with SwiftUI) and simply return an AnyPublisher<Result>.

In case that it’s needed, I’m also attaching the URLRequest creation part:

With this in place, we’re done! Searching now works and repositories are listed and sorted depending on their stargazers count.

I’m excited to see how we’ll be able to improve the code with further updates. Beta 2 has already provided some Foundation awesomeness which made things quite a bit easier.

Compared to the initial beta, we’ve gotten the dataTaskPublisher on the URLSession which we’d otherwise have to implement ourselves.

Most importantly, we’ve gotten other schedulers outside of the initially supplied ImmediateScheduler which wasn’t something we could use. That opened up the possibility to use debounce to throttle the events!

Next time, we’ll be making a details view that’ll show us some basic information about the repository and its author.

Stay tuned!

Another WWDC is behind us and oh boy, did they leave us with some cool new kids in town. We were kind of expecting a new UI framework that’s packing Swift’s power under the hood, but the extent of it caught us by surprise.

As a team, we’ve generally moved in the direction of writing reactive code (mostly using RxSwift), so when we saw that Apple has decided to move in the same direction with Combine, we were thrilled. To add more fuel, they’ve shown SwiftUI and all of its glory. It looked fun and snappy so we decided to give it a test ride.

So, today we’ll be making a GitHub search app that uses SwiftUI and Combine under the hood.

Apple released beta 2 versions of both frameworks a few weeks ago, so we’ll be going with that, as it makes developers’ lives a bit easier.

We’ll use GitHub search as an example. It’s very straightforward, and given its features supplied with the current SDK, SwiftUI really shines.

So, what do we want to make? Something like this:

Here’s the list of components we need to make in order to get this up and running:

Along with a couple of smaller tweaks and tricks (I’ll get into them shortly), that’s pretty much all we have to do.. That said – let’s dive in!

If you watched most of the SwiftUI related talks, you’ve probably seen this gem. Up until this point, creating a simple list required many steps like adding a UITableView on a screen, implementing the UITableViewDataSource and the UITableViewDelegate to handle cell selection… and that’s just the UI.

Additionally, developers had to provide the data source on the presentation layer as well as to make sure the indexes are correct if any changes were made to the data source, etc.

Well, not anymore!

SwiftUI leverages all of that boilerplate that we needed to write before it came with its declarative handywork. It gives us an object (guess the name of that object) that simply takes a list as a data source and turns that into cells.

That object is called List and it does all the “heavy lifting” under the hood!

Making a cell is also as simple as making a simple Text(_ stringLiteral:) view inside the list.

In the most basic of examples, this is our list.

However, we’re making a search-enabled app, meaning we’re still missing a TextField. While we’re at it, let’s customize our row in the list as well.

Modifying views in SwiftUI is as simple as calling methods on existing views in our body property. Those methods are known as modifiers.

An important note though – each time you end up calling a modifier, a wrapper view will be created. That wrapper ends up wrapping the view you’re modifying and it’s represented as _ModifiedContent, which itself conforms to the View protocol.

Essentially, with SwiftUI, we’re building wrappers around our views which in the end represent a single view that was built around aforementioned wrappers.

At this point, we’re almost done with the desired layout.

Adding all that vertically-written layouting code creates a lot of noise. On the plus side, a great feature in SwiftUI is that no one is really stopping you from creating another custom view and then simply constructing that inside of a list.

This way, code can be divided into smaller components that only handle a piece of the data. Let’s see this in action.

We will first move all the code we had into a separate RepositoryRowView. Since there’s already a lot of code even for that single view, we’ll break that down into smaller chunks.

This is the result we’re aiming for:

Design-wise, the screen is almost done!

You might notice that, compared to the initial image, a navigation bar is missing, as well as the fact that the design incorporates that new, flashy dark mode. Thankfully, both of these changes are extremely simple to make.

SwiftUI doesn’t use conventional navigation. Instead, it has an appropriate view that handles navigation. The name of the view is NavigationView, shockingly so.
This view will serve as a root and it’ll also be used as a means of setting the colorScheme of the entire view hierarchy to .dark.

Since we’re using system colors, iOS will do the heavy lifting, changing the colors of all the views accordingly.

That being said, let’s replace our root VStack with a NavigationView.
We’ll also adjust the listStyle, which is the last change we need to make to match the initial design.

This wraps up the SwiftUI part for now.

We’ve covered a lot. Don’t miss out on the documentation Apple provided, after all, that’s the ultimate guide for everything SwiftUI-related.

The SDK is not yet complete, but if you get up to speed now, you’ll have less catching up later.

In our next post, we’ll Combine (get it?) SwiftUI with the logic required to run the app.

See you swiftly!