Adaptive State Management: State

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.