New rule: no-invalid-default-props

[ljharb]

I'd like a rule that errors if anything is in defaultProps that is not also in propTypes.

This came up with the following code:

Component.propTypes = {
  fooValue: PropTypes.string,
};
Component.defaultProps = {
  foo: '',
};

In other words, it was a partially completed prop rename.

This rule should also look up a propTypes variable (Component.propTypes = propTypes) defined elsewhere in the file.

[webOS101]

I've taken a stab at this and have a working prototype. Just trying to get all the tests update for this rule. If @ljharb or someone else can clarify: I'm basing off an existing rule but need to write different data into the component list. Do rules share the same component data or do they each get their own copies? I see some rules appear to share the same data properties but not sure if they're somehow avoiding stepping on each others toes or if it's just luck that it doesn't conflict.

[webOS101]

Also, I considered it a violation of the rule if supplying a default for an .isRequired property. Was that your intention or should that be configurable?

[ljharb]

That's a good point.

I think that should be an option, but the checking be enabled by default. Let's call it allowRequiredDefaults, and default it to false.

[webOS101]

Also discovered a bug in require-default-props. Oops.

[sholladay]

I am trying to understand the intention behind the allowRequiredDefaults option and why it defaults to false. Can you provide some insight @webOS101?

Surely this code is okay?

Component.propTypes = {
  name : PropTypes.string.isRequired
};
Component.defaultProps = {
  name : 'John Doe'
};

[ljharb]

@sholladay no, that code is not OK - since name is required, the defaultProp will never trigger, so it's redundant - and redundant code should be removed.

[sholladay]

That is incorrect. Default props are applied before type checking happens.

From Typechecking With PropTypes:

The propTypes typechecking happens after defaultProps are resolved, so typechecking will also apply to the defaultProps.

I also confirmed that this includes isRequired by playing around with my React app. Admittedly, React is still a bit new to me, so I could be missing something. But this is in line with what I would expect.

Outside of the React ecosystem, code like this is pretty normal...

const currentUsername = 'John Doe';  // something dynamic
const getUser = (username = currentUsername) {
    if (!username) {
        throw new Error('Username is required');
    }
    // return { ... }
}

I definitely think it's a good thing to mark something as required, even if it has a default.

[ljharb]

If you pass undefined, defaultProps will be applied, but if you pass null, they will not be.

Conceptually though, if a prop is required, it must be passed - having the defaultProp creates a situation where you could safely omit a required prop, which is a bug. This linting rule helps prevent that bug.

[webOS101]

@ljharb is correct, marking a prop as required but using defaultProps to make it optional does not make sense. Either it is required or it is not.

[sholladay]

To each their own, I guess. Thanks for providing an option. I am using isRequired to say that it must have a value, not that the caller of the component must provide one. I'm happy to have a sane default (and to be able to use it) but maybe tomorrow that won't be the case and it will still need a value, so I'm glad to be able to specify these things separately. At the very least, it will make refactoring easier.

[ljharb]

Adding a defaultProp ensures it has a value; propTypes are solely about what the user provides.