Unlock This Episode
Our Free plan includes 1 subscriber-only episode of your choice, plus weekly updates from our newsletter.
The refactor to use the reducer protocol is complete, but the final code we ended up with is… well, let’s just say not ideal.
We naively converted some reducer operators to the brand new
ReducerProtocol, such as
forEach, but the nice thing about using a protocol is that we obtain a new tool to completely re-imagine reducer composition. And that’s result builders.
Result builders give us the opportunity to reimagine what the library’s core compositional operators look like. We can remove a lot of unnecessary noise when composing lots of reducers together, we can force more correctness guarantees into the API’s usage, and we can even work around some of the compiler limitations we mentioned previously, such as variadic generics.
Let’s revisit that particular limitation in order to find inspiration for why we want result builders and how we should implement them.
The Swift Evolution proposal that introduced
buildPartialBlock to result builders, making it possible to accumulate a result from many components. This works around the common limitation of having to define a number of
buildBlock overloads to support larger builders.