-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
prop-types Validating external propTypes (eg. decorators) #322
Comments
I am also wondering the same thing, if there's a good way to avoid adding them all manually as exceptions. In my case, I'm using a |
I also run into this issue when I am using acdlite/recompose. It turns out that moving // set propTypes in the component
@pure
class Foo extends Component {
static propTypes = {}
}
expect(Foo.propTypes).to.be.an('undefined');
// set propTypes in the outermost HOC
@setPropTypes({})
@pure
class Bar extends Component {}
expect(Bar.propTypes).to.be.an('object'); |
I'll be happy to fix the rule for this but I've never used Is there any common pattern on which we could rely? |
@yannickcr //bem.js
export function BEM(blockName) {
if (typeof blockName !== 'string') {
throw new Error(ERROR_DECORATOR_BLOCKNAME_VALIDATION);
}
return function(target) {
if (typeof target !== 'function') {
throw new Error(ERROR_DECORATOR_TARGET_VALIDATION);
}
if (target.prototype instanceof React.Component) {
if (!target.propTypes || target.propTypes && !target.propTypes.modifiers) {
target.propTypes = Object.assign({}, target.propTypes, {
modifiers: React.PropTypes.arrayOf(
React.PropTypes.string
)
});
}
if (!target.defaultProps || target.defaultProps && !target.defaultProps.modifiers) {
target.defaultProps = Object.assign({}, target.defaultProps, {
modifiers: []
});
}
}
target.prototype.bem = bem.bind(null, blockName);
return target;
};
} //table.jsx
const CN_TABLE = 'table';
@BEM(CN_TABLE)
export default class Table extends React.Component {
render() {
return (
<table className={this.bem(this.props.modifiers)}>
<TableCol/>
<TableHead/>
</table>
);
}
} |
any progress on this topic? |
@yannickcr and all I added a simple test case that exposes an issue I came across while working with https://github.com/acdlite/recompose Hopefully this can help bring attention to this issue. |
We need this ! |
PS: I'm right now using the |
@yvele I'm trying to do this but struggling to get it working, could you show me what your .eslintrc looks like? |
@giuseppepaul Sure!
|
Just to leave another option, I export the proptypes for a decorator then destructure them into the connected class. Decorator ...
...
export const authPropTypes = {
authorize: PropTypes.func,
isLoggedIn: PropTypes.bool,
login: PropTypes.func,
logout: PropTypes.func,
userProfile: PropTypes.object
};
export default function withAuth(ComposedComponent) {
...
} Decorated: ...
import withAuth, {authPropTypes} from 'decorators/with-auth';
@withAuth
class Header extends Component {
static propTypes = {
checked: PropTypes.bool,
toggleMenu: PropTypes.func,
...authPropTypes
}
...
} |
Any progress on this? It's so annoying to duplicate all the component proptypes around the codebase or importing/spreading them all over. 😔 |
Would be great to have this. |
This is something that comes from loggur/react-redux-provide#1 as propTypes are used to actually define data that will be provided to the component like this:
That doesn't coop well with this rule unfortunately. I am wondering if there is a way how to analyze this and read propTypes from higher-order component / decorator also.
I have noticed some undocumented
customValidators
, but I am not sure how does that works. If I understand correctly it accepts list of props that will be ignored?The text was updated successfully, but these errors were encountered: