I was wondering why Scope the reducer is done the way it is as a top level reducer and not as a function on Reducer.
Other reducers are done as a function. .ifLet.ifCaseLet etc...
I know that in those cases the order matters. So there is a case for forcing that constraint. But for instance with BindingReducer() the order also matters as it needs to run first. So wouldn't it make sense for this to be a .binding like it was before the ReducerProtocol update?
And then, if we're doing that could we not also do .scope(...). I feel like this would match a lot more with how the store on the view side of things is scoped.
Hi @Fogmeister, as you noted, the main reason is that there is no order to preserve. Also, BindingReducer does not have an order requirement. There can be times you may want the value before the binding is applied, and so we have that flexibility with a top-level reducer.
Further, we found that type inference and autocomplete worked better with the Scope style. Typically you can do Scope(state: \. and autocomplete figures out what key paths are available based on the surrounding builder context. Whereas .pullback(state: \. has no such context.
And finally, there's a chance we may even move store.scope in the direction of Scope rather than the other way around. This discussion shows why we might want that, and we've started experimenting with baking it deep into the library.