What about a mapContextToProps?

[gfpacheco]

My root component have a property and I want to pass it down to any descendants that care about it. From what I've seen, please tell me if I'm wrong, the right way of doing it is through context. This way no intermediate component should know about it and keep passing it down.

The problem is my container (smart component, or whatever) doesn't have access to context to send that property to my presentational component as a prop (or does it?).

If I'm right again, is there any reason to not exist such map?

[timjacobi]

context is to be used carefully as it is effectively a global variable. The philosophy of redux is that all your application state lives in the store. Using redux with React the store is actually made available to all components through context by using the <Provider /> component which is part of react-redux.
You could incorporate the property you are referring to into the store and then use mapStateToProps to make the property available to your components.

[xorcus]

Why at all you need to separate mapStateToProps, mapDispatchToProps, etc. ?
Why not just have a single connect() argument mapToProps( { state, dispatch, context, ... }) ?
The background of this question is that one may want to access the state in mapDispatchToProps for some reason... e.g. decide which action to dispatch based on the current state, etc.

[gaearon]

I don't think we want to rely on context in our public API. It's still subject to change. You should create an intermediate component that takes care of reading from context and rendering the child component.

We don't suggest you to use context for changing data because React doesn't support this scenario well at the time (facebook/react#2517).

Why at all you need to separate mapStateToProps, mapDispatchToProps, etc. ?
Why not just have a single connect() argument mapToProps( { state, dispatch, context, ... }) ?

Check out #1 for a big discussion on this. ;-)
Basically it's a perf nightmare because you'd have to rebind action creators every time the state changes.

This means a ton of unnecessary and expensive allocations, and changing function identities that kill shouldComponentUpdate() optimizations down the tree.

The background of this question is that one may want to access the state in mapDispatchToProps for some reason... e.g. decide which action to dispatch based on the current state, etc.

You can already use mergeProps() (third argument to connect()) to do something with the results of mapStateToProps() and mapDispatchToProps(). If you really want to, you can put that logic there. See also #237.