Replies: 1 comment 1 reply
-
@heyltsjay While we originally had this overload available, what we found was you'd probably never compile this step since it's so close to the final answer. For example, if you start here: AnyReducer {
FeatureLeafA.Reducer()
}
.pullback(
state: \.featureLeafA,
action: /Action.featureLeafA,
environment: { _ in }
) And wanted to move the AnyReducer {
FeatureLeafA.Reducer()
.pullback(state: \.featureLeafA, action: /Action.featureLeafA)
) You're basically already at AnyReducer {
Scope(state: \.featureLeafA, action: /Action.featureLeafA) {
FeatureLeafA.Reducer()
}
) And so there's very little reason to use that other Definitely interested to hear if other folks had similar experiences, though! |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I just completed migrating our app to
ReducerProtocol
:@Dependency
I was surprised to see that there wasn't an
AnyReducer.pullback
variant that didn't take an environment, since I never needed to use one. I assumed this would be the typical migration path, but maybe it's expected to leave more non-@Dependency
dependencies behind.This is a very small and short-lived convenience, so not sure it warrants discussion, but was encouraged to post one by @mbrandonw
After migrating leaves, my next-higher reducer looked like this until I migrated up one level.
Beta Was this translation helpful? Give feedback.
All reactions