feat: introduce forbidUnknowProps

[HendrikThePendric]

I introduced this component because propTypes.exact does something slightly different than we needed....

For example this is how propTypes.exact is used:

MyComponent.propTypes = {
    house: PropTypes.exact({
        streetName: PropTypes.string,
        houseNumber: PropTypes.number,
    }),
    otherProp: propTypes.bool,
}

And this would be a similar example of how this new function forbidUnknowProps can be used:

MyComponent.propTypes = forbidUnknowProps({
    houseNumber: propTypes.number,
    streetName: propTypes.string,
    otherProps: propTypes.bool,
})

So with forbidUnknowProps we can wrap an entire prop-type definition and with exact we operate at property level.

As another note, normally we would export two "flavours": 1) the normal function and 2) the isRequired function. In this case that didn't make much sense....

[varl]

There's a typo "forbidUnknowProps" (should be "forbidUnknownProps") in the documentation and code. Mind cleaning that up?

[varl]

I think that whitelistProps (or secondarily allowedProps) is a more succinct name than forbidUnknownProps.

I don't like having a negative in the function name as it raises some questions about the parameters passed in.

[varl]

Spelling errors and a comment about the chosen name of the function.

[ismay]

Maybe we should wait for this issue to be resolved (or help out): facebook/prop-types#263. It seems our use-case should be supported by exact from the prop-types package.

I would prefer that over this solution. It's more standard, and others will understand easier what's going on.

[HendrikThePendric]

@ismay that issue has been open since March, you think it would be worth the wait?

[HendrikThePendric]

@varl function name has been corrected to whitelistProps as per your suggestion

[ismay]

that issue has been open since March, you think it would be worth the wait?

I don't know what the holdup is. Depends if it'll need a ton more work or if it's nearly there. If it's close I'd prefer using the prop-types package over building and maintaining it ourself. That'll be easier for us and more clear for outside/new devs.

[varl]

The hold-up seems to be that propTypes.exact is not meant to work like that according to the docs. Some consider it a bug. Others do not. One of the maintainers has implemented this in a separate library: https://github.com/airbnb/prop-types-exact so seems to me like this is by design?

[ismay]

One of the maintainers has implemented this in a separate library: https://github.com/airbnb/prop-types-exact so seems to me like this is by design?

That dude is fairly direct with closing PRs that are wontfix or out of scope somehow though. I'd expect him to have closed it if it wouldn't fit. But I don't know. We can ask, see what the hold up is, and why he created a separate lib implementing exactly that.

[HendrikThePendric]

Closing this PR for the following reasons:

• We no longer have a valid use-case for this (see fix(css-variables): improve robustness and developer warnings ui-core#449 (comment))
• Potentially, when a use-case does arise, we will find that we can use propTypes.exact for it.