Are reducers split too specific?

wyattGTL — Tue, 10 Mar 2020 19:08:52 +0000

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.

Best way to allow other components to change table's focused row?

wyattGTL — Thu, 05 Mar 2020 16:02:51 +0000

I have displayProjectTable that gets state from reducer projectData and populates itself.

Currently displayProjectTable has a local state that stores focusedRowID. My problem is that I want other components to have the ability to modify the focusedRowID and it's content.

Some examples:
-A component tells displayProjectTable to add 1 to focusedRowID (ie. focus on the next row)
-A component tells displayProjectTable to set value of row at focusedRowID to "test". Because displayProjectTable gets its state from projectData, that reducer's state will have to be changed at the focusedRowID index.

A possible solution is to store focusedRowID inside of the projectData.js reducer. However, this seems like a bad solution to me. The projectData reducer is responsible for fetching, storing, and saving projectData. Would it really make sense to store a focusedRowID when projectData shouldn't even know what a row is?

DEV Community: wyattGTL

Are reducers split too specific?

Best way to allow other components to change table's focused row?