You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am not 100% sure whether or not this is an anti-pattern, but three of those actions are basically doing the exact same thing: applying the payload to the state. Imagining for a second that this is not an antipattern, I ended up abstracting these kinds of "standard" operation out into their own utility method called "applyPayloadToState" - all it is was the following;
Are you guys open to incorporating this function directly into your utility methods or is this an abstraction too far? I am happy to do the PR if you are up for it.
The text was updated successfully, but these errors were encountered:
Thanks @mjetek (and sorry for this extremely delayed response - been mega busy!). I have been using combineActions - all across my codebase (and sometimes multiple times in the same duck if I want to split out my reducers in there) so I still see a need for the extra convinience function.
Totally fine if you don't want it in the codebase here though, I can just continue using it separately.
I have found that in using this library I've ended up with quite a lot of reducer code that look like this;
I am not 100% sure whether or not this is an anti-pattern, but three of those actions are basically doing the exact same thing: applying the payload to the state. Imagining for a second that this is not an antipattern, I ended up abstracting these kinds of "standard" operation out into their own utility method called "applyPayloadToState" - all it is was the following;
and then in the duck (or reducer or wherever);
Are you guys open to incorporating this function directly into your utility methods or is this an abstraction too far? I am happy to do the PR if you are up for it.
The text was updated successfully, but these errors were encountered: