Reducer Protocol: The Solution

So, we have now seen there is still a ton of room for improvement in the library:

• We can do a better job of providing a more natural space for housing the state, actions and logic of your features built in the Composable Architecture.

• We can help out the compiler a bit so that it is not so strained, leading us to lose type inference, autocomplete and warnings.

• There’s improvements we can make to readability of highly composed reducers, as well as the correctness of some of the more powerful operators in the library.

• We definitely have to do something about the ergonomics of the environment, because right now it’s quite a pain to add new dependencies to a leaf node of an application and update every layer through to the root of the application.

• And finally, there’s performance improvements we can make because highly modularized applications will lead to very deep call stacks.

Well, luckily for us it’s possible to solve all of these problems, and more. By putting a protocol in front of reducers, and by constructing reducers as concrete types that conform to the protocol rather than deeply nested escaping closures, we will greatly improve the experience of developing large, complex features in the library.