🎉 End-of-year Sale! Save 25% when you subscribe today.

Modern SwiftUI: Effects, Part 1

Episode #217 • Dec 19, 2022 • Subscriber-Only

After a brief digression to explore the performance and ergonomics of identified collections, we dive into the messy world of side effects by implementing the “record meeting” screen. We’ll start with the timer, which has surprisingly nuanced logic.

Previous episode
Modern SwiftUI: Effects, Part 1
Next episode
Locked

Unlock This Episode

Our Free plan includes 1 subscriber-only episode of your choice, plus weekly updates from our newsletter.

Sign in with GitHub

Introduction

And this model binding logic is getting a little complex, but the amazing thing is that because it’s all integrated together at the model level, it’s all 100% testable. We can write tests that go through an entire user flow and prove that the features interacted with each other in the correct way. And then if we ever accidentally break the binding logic we will get instant visibility into it.

That will all come later, so let’s keep moving forward. We are down to the very last piece of functionality in the detail screen, and that’s drilling down to start a new meeting, and that feature is by far the most complex of the entire application because it involves effects.

It manages a timer for counting down the meeting time, and it manages a speech recognizer for transcribing live audio while the meeting is taking place. There’s also another effect in the app. Way back at the root we need to handle persistence of the data for saving and loading to disk.

That will be the focus of this episode, but before doing any of that, let’s have a little fun by making our domain modeling even more concise than it is now. A moment ago we came across two thorny situations that made it clear that our simple array of standups is not pulling its weight. There are many times we need to deal standup values by their ids, and forces us to scan the entire array to find a particular standup.

SwiftUI has already learned this lesson because many of its APIs require you provide Identifiable data, and in fact many of our core domain data types already conform to that protocol. So, wouldn’t it be nice if you could look up a value by its id, or remove a value by its id instead of linearly scanning the entire collection?

Well, it is possible, and it is all thanks to another library that we open sourced a year and a half ago. It’s called IdentifiedArray, and it’s a collection type that is specifically tuned for dealing with Identifiable elements. It has all of the standard collection APIs, but also comes with some enhanced APIs that allow for performant, safe and ergonomic access to elements via their id.

So, let’s bring in that library and see how things improve.

Identified arrays


References

Downloads

Get started with our free plan

Our free plan includes 1 subscriber-only episode of your choice, access to 64 free episodes with transcripts and code samples, and weekly updates from our newsletter.

View plans and pricing