7 Useful Filtering Operators in RxSwift

After using RxSwift for several months now, I can safely say that filtering is a key feature that has saved me plenty of lines of code. To know which filtering operators to use when, requires a basic overview, so let's look at 7 of my favorite filtering operators this library has to offer.

Written by 

RxSwift is the Swift implementation of the popular ReactiveX library. When it comes to filtering data, you're in good hands with this library. It is packed full of operators that allow you to filter out data in various ways so that you only pass through the data you want your subscribers to receive.

Essentially these operators are conditional constraints to the next-event. This means that all next-event elements emitted by an observable pass through the operators you specify. Each of the elements needs to satisfy the requirements of the operator - if not, they will be dropped.

Most operators operate on observables and will return an observable. This way, we're able to chain these operators as the next operator takes the output of the previous operator as input.

One thing to note is, that you won’t be able to filter out with these operators are stop-events, in other words, completed-events and error-events. The filtering operators only operate on next-events.

1. filter()

The first operator on the list is the filter-operator.

The way the operator works is that the filter-operator takes a predicate as an argument. The predicate is as a conditional constraint that must be satisfied by each of the elements emitted by the observable. This way the predicate is applied to all elements and determines if each of them is allowed through to the subscribers or not.

Take a look at this marble diagram:

In this case, filter() will only let through elements whose values are greater than 10. These will reach the next-operator, while the rest of the elements are dropped.

Now, let's see a code example:

2. skip() & skipWhile()

As the names suggest, these two operators serve the purpose of skipping data at some point or another.

With the skip-operator you pass it a number as a parameter. This number tells us how many elements to ignore. All elements that come after are then allowed through to the subscribers. So, skip(2) will ignore the first two incoming elements and emit all other elements.

With the skipWhile-operator you pass a predicate that, as long as evaluates to true, will ignore the incoming elements. When it evaluates to false, all elements that come after will be allowed through.

Let us take a look at this in code:

3. take() & takeWhile()

Next, we have the various taking operators. These are counter to the skipping operators. The skipping operators will exclude certain data based on a condition, but the taking operators will instead include data in the ways you specify.

The take-operator is opposite to the skip-operator. It works as you would expect. With the take-operator you can specify a certain number of elements to allow through. All elements that come after this number are ignored.

The takeWhile-operator is counter to, you guessed it, skipWhile-operator. With the takeWhile-operator you pass a predicate that, as long as evaluates to true, will allow the incoming elements. When it evaluates to false, all elements that come after are ignored.

4. elementAt()

Now, here's is a nifty little operator you can't overlook. The elementAt-operator will filter out all next events except the element you specify at a certain index.

In code, it will look like the following:

5. ignoreElements()

Last but not least we have the ignoreElements-operator.

As you can see from this marble diagram, ignoreElements() will simply ignore next-event elements. This way, you can ignore next-events, subscribe only to stop events and perform an action accordingly.

Wrapping up

We looked at the most common filtering operators that RxSwift has to offer. You can find the entire list of operators available here.

Thanks for reading. Leave a cover to let me know of other RxSwift related topics you want me to cover.

Share this post


You may also like


Refactoring iOS Apps – A Pragmatic Guide

While your app and development teams grow larger, the codebase is inevitably going to scream for refactoring – that is, improvements in the design of the existing code. There are no silver bullets to refactoring, but iOS apps tend to get into the same pitfalls. Luckily, the common cases of refactoring can be mitigated by being in line with the following set of practices on improving and maintaining code while speeding up development.


Architecting a Logging Service for iOS Apps

Understanding how your apps behave in production is a fundamental part of our jobs as iOS engineers. We need to gather log events in order to investigate and reproduce issues that customers run into. Here’s how you create a log service with a clean architecture that’s modular and easily extensible.