DEV Community

wyattGTL
wyattGTL

Posted on

Are reducers split too specific?

I have glossaryReducer.

This reducer is responsible for fetching the glossary, adding terms to the glossary, and removing terms from the glossary.

It's state consists of {glossaryData:[], isFetching:false, isAddingTerm:false, isRemovingTerm:false}

Basically, glossaryReducer handles functionality having to do with the glossary.

Alternatively, I could have three reducers: fetchGlossaryReducer, addTermReducer, removeTermReducer. Each reducer can have the state {isFetching:false}.

Does splitting up reducers this specific make sense? Imaging I am building a medium to large scale application.

Top comments (2)

Collapse
 
bradtaniguchi profile image
Brad • Edited

Usually you have 1 reducer for your slice of state. In the reducer you update the state according to the action. Based upon the action you can update the state how you want.

You probably just want to define how you update the state in their own function if it gets really complex.

function GlossaryReducer(state, action) {
  switch(action.type) {
    //..
    case 'fetchGlossary':
      return fetchGlossary(state, action); // this returns the updated state
    //..    
  }
}

So you keep your 1 reducer, but split up the logic within that reducer with helper functions. This way your reducer just handles the glossary state, rather then having a reducer for each action as that removes the "middle" abstraction of having a reducer handle multiple actions relevant to the same piece of state.

PS. I use NGRX rather then Redux directly, but afaik the base api is the same. :)

Collapse
 
wyattgtl profile image
wyattGTL

Perhaps another way to put it is: doesn't this convention make my reducers looking more like actions? In terms of their names. For instance, fetchGlossaryReducer seems like it performs and action rather than stores the glossary data.