Can we add store to third parameter to reducer

[samuelpaulc]

Discussion:
Can we add store to third parameter to reducer?
While working on our application, we ran into cases where a reducer may need to access some parts of state tree which are not directly related to it
We realize that this is indication that our store structure is not in line with redux philosophies but I feel the ability to design store based on functionality is kind of lost.

If this state was given to the reducer we can design the store based on application functionality.
Right now we are in a situation where we need to make the reducer as a top level reducer even when by functionality it should not, only that it needs to access common global state

Please suggest

I saw a similar question but that was for adding it to the mapStateToProps

[markerikson]

The top-level reducer function that you pass to createStore must have the (state, action) signature. Anything inside of that is entirely up to you - remember that reducer logic is simply functions, and can be split up and customized same as you would any other code in your application. Also note that use of combineReducers is not required - it's simply a useful utility for the most common scenario.

Please read the related FAQ question: http://redux.js.org/docs/FAQ.html#reducers-share-state .

Also, I am currently working on a new section for the Redux docs that describes best practices and approaches for writing reducer logic. The description is over in #1784 , and that issue has a link to my work-in-progress.

[marvinhagemeister]

@samuelpaulc Have a look at reselect which allows cross-cutting reducers: https://github.com/reactjs/reselect

[samuelpaulc]

@marvinhagemeister we do use both combine reducers and reselect. The point is reselect selectors require the state to be passed which maybe levels higher than which is passed to the reducer.
But I agree it s upto us to define the functions in the way we want

[markerikson]

@marvinhagemeister , @samuelpaulc : hmm. selectors aren't usually a normal part of reducer logic - they're usually used on the UI/business-logic side of things, in your mapState functions and thunks and such. I suppose you could use a selector inside of a reducer to extract a piece of data you cared about from some nested state, but that's generally not a major use case.