Required by default?

[jamierumbelow]

Thanks prop-types team for all your work so far.

Question: when's the next major prop-types release scheduled for, and has there been a discussion about enabling isRequired by default?

My basic assumption is that the majority of components require the majority of their props implicitly, even if developers don't label them as such.

I try to mark props as required by default:

Profile.propTypes = {
  id: PropTypes.number.isRequired,
  email: PropTypes.string.isRequired,
  openModal: PropTypes.func.isRequired,
  renderAdminActions: PropTypes.func
}

It's safer to be stricter rather than let avoidable failures happen further down the stack, or further away from their source – which is the basic rational for adding .isRequired, and for using prop types more generally, for that matter.

Repeating .isRequired, like above, is cumbersome and causes visual clutter. Instead, we could expose an .optional modifier to disable it:

Profile.propTypes = {
  id: PropTypes.number,
  email: PropTypes.string,
  openModal: PropTypes.func,
  renderAdminActions: PropTypes.func.optional
}

'Required by default' is a common pattern in software: many languages such as TypeScript and Swift require declared function parameters by default; NOT NULL must be set explicitly in most relational DB schemas; . Such conventions shape developer expectations (particularly amongst developers who are newer to the React ecosystem).

It may also have positive knock-on effects:

• It could encourage developers to be more thoughtful about making the default values of optional props explicit. If a prop is required by default, but marked optional, then it should have a default value. If a prop is optional by default, then it either could be required or not, could have a default value or not, and we have to look inside the component and parse the logic in our head to decide whether that's the case.

• Relatedly, it would render more potent the require-default-props recommended eslint rule.

• In cases where components are reused several times across an application, it could encourage developers to be more thoughtful when adding single-use props to component interfaces. In particular, it could encourage developers to not clutter component type definitions with a sort-of implicit rendering logic:

  const Profile = (props) => { if (props.adminBaseUrl) { return doAdminStuff(props) } }

  Profile.propTypes = { id: PropTypes.number, email: PropTypes.string, openModal: PropTypes.func, adminBaseUrl: PropTypes.string, accessLevel: PropTypes.string }

• It could facilitate easier compile/transpile-time checking, simplifying tooling.

• Depending on how it's implemented, it could clear up a semantic ambiguity between not being given a value and having a null/undefined value.

[ljharb]

Although I think that would have been a better initial default, I don't think the value in that breaking change is high enough to warrant the developer churn it would cause.