Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: new utility function "applyPayloadToState" #320

Open
mikeyhogarth opened this issue Aug 18, 2018 · 2 comments
Open

Proposal: new utility function "applyPayloadToState" #320

mikeyhogarth opened this issue Aug 18, 2018 · 2 comments

Comments

@mikeyhogarth
Copy link

mikeyhogarth commented Aug 18, 2018

I have found that in using this library I've ended up with quite a lot of reducer code that look like this;

const reducer = handleActions(
  {

    [myAction](state, { payload: { amount } }) {
      return { ...state, ...payload };
    },

    [myOtherAction](state, { payload: { amount } }) {
      return { ...state, ...payload };
    },

    [myWeirdActionThatIsDifficultToSeeAmongstTheNoise]: (state, { payload }) => {
      return { ... state, foobar: !payload.flobalob }
    },

    [myLastAction](state, { payload: { amount } }) {
      return { ...state, ...payload };
    }

  }, defaultState);

// possibly more reducers using the same (...state, ...payload) pattern above

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;

export function applyPayloadToState(state, { payload }) {
  return { ...state, ...payload }
}

and then in the duck (or reducer or wherever);

import { applyPayloadToState } from 'wherever';

const reducer = handleActions(
  {

    [myAction]: applyPayloadToState,

    [myOtherAction]: applyPayloadToState,

    [myWeirdActionThatIsNowEasyToSee]: (state, { payload }) => {
      return { ... state, foobar: !payload.flobalob }
    },

    [myLastAction]: applyPayloadToState

  }, defaultState);

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.

@mjetek
Copy link

mjetek commented Sep 2, 2018

Hey @mikeyhogarth ,
In cases like these, when you are handling multiple actions with the same reducer logic, use combineActions.

const reducer = handleActions(
  {
    [combineActions(myAction, myOtherAction, myLastAction)](state, { payload }) {
      return { ...state, ...payload };
    },
    [myWeirdActionThatIsDifficultToSeeAmongstTheNoise]: (state, { payload }) => {
      return { ... state, foobar: !payload.flobalob }
    }
  }, defaultState);

@mikeyhogarth
Copy link
Author

mikeyhogarth commented Oct 6, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants