-
-
Save mbrochh/188e9b14713d4100fc7e90d455ff7b85 to your computer and use it in GitHub Desktop.
class Component1 extends React.Component { | |
static propTypes = { | |
some: React.PropTypes.bool, | |
prop: React.PropTypes.string, | |
types: React.PropTypes.object, | |
} | |
} | |
class Component2 extends React.Component { | |
static propTypes = { | |
additional: React.PropTypes.object.isRequired, | |
some: React.PropTypes.bool, | |
prop: React.PropTypes.string, | |
types: React.PropTypes.object, | |
} | |
render() { | |
let { additional, ...other } = this.props | |
return ( | |
<Component1 {...other} /> | |
) | |
} | |
} |
Since I didn't find a good solution for that, I'm (very sparsely) using contexts as a workaround for now.
@Schneck how would context help? Got a code snippet?
I've got a 3-level hierarchy: Project => EntryDetail => InlineEdit
.
InlineEdit
needs information from Project
, and using props, EntryDetail
would have to passthrough that information, which is inconvenient.
Example:
Project component
class Project extends React.Component {
getChildContext() {
return {
some_information: this.props.some_information
};
}
}
Project.childContextTypes = {
some_information: React.PropTypes.bool
}
InlineEdit component
class InlineEdit extends React.Component {
static contextTypes = {
some_information: React.PropTypes.bool
};
}
some_information
can then be used as this.context.some_information
Note
For me, this seems like less redundant when passing through data to subcomponents, but essentially, it's a backdoor breaking the redux data flow rules. So I think it depends on preference, and amount of redundancy whether to use this method or not.
It looks like this saves you one hop when passing props into deeper children but you still need to define all props on both components, so when you add something_else
to InlineEdit you also need to change code in Project? That's exactly what I want to avoid.
Prop distribution hell is one of the things that Redux addresses. Pre-Redux, your root component needed all the data, and then each subsequent component level needed some subset of the data. With leaf nodes (or nodes closer to the leaves) being able to connect()
to the data using Redux, a lot of that complexity is reduced.
However, you have Component1
's propTypes
statically available to you, so why not something like this?
class Component2 extends React.Component {
static propTypes = {
...Component1.propTypes, // <------------------ :-)
additional: React.PropTypes.object.isRequired
}
render() {
let { additional, ...other } = this.props
return (
<Component1 {...other} />
)
}
}
@erikras see, I'm still a JS syntax noob! That thing with the ...Component1.propTypes
is EXACTLY what I was hoping for! This is perfect, thank you so much!
And I agree that Redux helps with propTypes-hell, just in my special usecase, I'm dealing with props that don't make sense to be stored in a reducer, so that's why I was asking.
I would like to know how to properly compose propTypes for nested components. In this example we have a
Component1
that has certain propTypes and aComponent2
which is supposed to be a wrapper aroundComponent1
. Therefore, the usage ofComponent2
should be almost the same as forComponent1
, just that it can do some additional stuff (i.e. accepts additional propTypes).My example has to be an antipattern, because when I ever update the propTypes of
Component1
I must remember to also update the propTypes ofComponent2
, which sucks.Is there some way to define the propTypes of
Component2
in some more dynamic way so that it somehow takes the propTypes ofComponent1
and adds it's own ones to those?