[just ideas] - Option for dealing with deep component prop passing within Connected components
See original GitHub issueApologies for polluting the issue list since it’s not really an issue but I believe there is some interest in coming up with a workable solution that
a) Keeps the Smart/Dumb component divide clean & generally near the top of the component tree for a given part of the app domain AND b) Avoid the hassle of passing @connect results down deep chains of children
I liked the Provide/connect pattern a lot so I generalized it in react-tunnel and starting playing with a patter like so
// in some Top level Component
<Provider store={mystore} /> //react-redux Provider
{() => <App />}
</Provider>
// in a route handler
@connect(
myStateMapper,
(dispatch) => ({
someActions: bindActionCreators(subsetOfMyActions, dispatch)
})
)
export class ConnectedComponent...
// within ConnectedComponent's render()
<Provider someActions={this.props.someActions}> //react-tunnel Provider
{() => <PageController />}
</Provider>
// deep within PageController's render tree
@inject(
(provided) => ({
specificActionIwant: someActions.specificActionIwant
})
)
export class DeepComponent...
//within DeepComponent's lifecycle methods
...
this.props.specificActionIWant();
...
The Provider in react-tunnel puts props into context under the provided namespace and inject pulls them off with the mapProvidedToProps function.
It’s not react-redux specific nor really related to redux in any way (and there are probably plenty of other DI type libraries that will get the same job done) but i thought it fit nicely with the react-redux paradigm but would give you the option to use similar semantics deeper in the component tree without bringing along anything specific to redux.
As a final note, you could actually do away wiht the react-redux Provider and just use the react-tunnel provider and inject by doing
// near top of app
<Provider store={mystore}> //react-tunnel Provider
{() => <App />}
</Provider>
//when you are going to connect...
@connect(
stateFn,
actionFn
)
@inject( provided => ({store: provided.store}) )
export class InjectedThenConnectedComponent...
//the above would have store made available to connect via props and not context but that is now supported in react-redux
anyhow, just some food for thought… would love feedback even if it’s why this is a horrible idea.
Thanks, Josh
Issue Analytics
- State:
- Created 8 years ago
- Comments:5 (5 by maintainers)
Top GitHub Comments
I try to
connect()
route handlers and use props all the way down unless some component gets too complicated and then it gets its ownconnect()
, but also gets a “dumb” props-only version in case I want to reuse it later.Makes sense, I guess i would just replace the deep
connect()
withinject()
since it isn’t strictly bound to the semantics of redux. The thing about either option is that they map what is contextual information into props so that you the ‘dumb’ version doesn’t care how it get’s its props and this means you can easily partially or fully unwind this style of props providing without having to refactor said component.