So we finally got the app building and all tests passing…

But now that we’ve done yet another big refactor of the Composable Architecture, maybe we should slow down and ask “what’s the point?”. Because although we have weened ourselves off of the global environment, it doesn’t seem like it has materially changed our application much. We are still mostly constructing effects in the same way and writing tests in the same way.

So have we actually solved the problems that we said the environment technique has, and will this really help out our applications at the end of the day?

And the answer is definitely yes! This adaption of the environment technique has solved all of the problems we described at the beginning of this series of episodes:

• We had the problem of multiple environments: if each of your feature modules has its own environment, it can be difficult to know how to control all of them simultaneously, and you lose some static guarantees around that.

• There’s also the idea of local dependencies. With each module having only one environment, it’s impossible to reuse a screen with different environments.

• And then there’s the problem of sharing dependencies. Each of our features may have environments with common dependencies, and the “global” environment of a module made it difficult to share these common dependencies.

And it’s important to note that our tweak of the environment technique was only possible due to us adopting the Composable Architecture, which gave us a single, consistent way of building our features and solving these problems.

And to prove this, let’s go through each problem and demonstrate exactly how it was solved.