Adaptive State Management: State

Episode #95 • Mar 23, 2020 • Subscriber-Only

There’s a potential performance problem lurking in the composable architecture, and it’s time to finally solve it. But, in doing so, we will stumble upon a wonderful way to make the architecture adaptive to many more situations.

Adaptive State Management: State
Introduction
00:05
View models and view stores
01:58
View store performance
10:05
Counter view performance
18:41
View store memory management
23:41
Adapting view stores
27:51
Next time: adaptive actions
39:09

Unlock This Episode

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

Introduction

Any action we take is causing the UI to freeze up, ostensibly because SwiftUI is doing a ton of work to figure out how to render the root ContentView. So, it definitely is possible for our design choices for the store to cause some performance problems in SwiftUI, but it’s not quite clear how big of a problem this is in a real world application.

So we’ve now seen that there is a potential problem with the way we have set up the composable architecture. Again, we say “potential” because it may not actually become a problem until you have a massive application. But, rather than waiting for that day to come, it turns out there is something pretty simple we can do to fix this. Even better, by fixing this problem we will actually stumble upon a wonderful way to make all of our business logic in our reducers more adaptable to platforms and the constraints we face in real world applications.

The crux of the problem is that we have a single store inside our views that holds not only all the state it needs to show its UI, but also all the state of its children, which may not be shown until later, if at all. So it seems like perhaps our views need to hold onto a different object that only has access to the state that the view cares about, and nothing more. And then maybe we have a better chance of getting notified of only the changes to the state that we actually care about. And if we succeed in doing that, then maybe the Store doesn’t need to be an observable object at all, only this secondary thing needs to be observable.

Before figuring out how to do that, let’s do the one thing we know needs to be done.

This episode is for subscribers only.

Subscribe to Point-Free

Access this episode, plus all past and future episodes when you become a subscriber.

See plans and pricing

Already a subscriber? Log in