-
Notifications
You must be signed in to change notification settings - Fork 2
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
deprecate message in favour of content #66
Conversation
/** Content shown when the Popover is visible */ | ||
message: PropTypes.node.isRequired, | ||
content: PropTypes.node, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@larsbs not sure if to make this required or not. Technically it should be, but then you get the deprecation warning message and the prop type not matching since you might still be using message
. Thoughts?
@nicmosc what's the motivation behind this change in the first place? |
@larsbs at first it made sense to have But that's not all. After adding the |
@nicmosc Ok, have you investigated about what's the standard procedure to deprecate a prop-type that was required? |
@larsbs For now i've only been able to find things about "why are proptypes deprecated" when referring to the facebook package, which is just 👌😑 At Airbnb they have a This is interesting, though it's not part of the issue: facebook/prop-types#156 (comment) |
@nicmosc then, let's just re-create a mutuallyExclusive type like Airbnb and then, trigger the deprecation error if message is used. |
@nicmosc idea for syntax: message: CustomPropType.mutuallyExclusive('content', { deprecated: true }),
content: CustomPropType.mutuallyExclusive('message'), |
@larsbs good one, then shall we also have a custom prop for deprecated only? deprecatedProp: CustomPropTypes.deprecated(PropTypes.string), |
@nicmosc sure, we're gonna need it eventually. |
No description provided.