[React 19] prop-types removal alternative / console component trace

[oliviertassinari]

Summary

The state of .propTypes is a bit unclear. I see:

1. https://react.dev/blog/2024/04/25/react-19 doesn't mention their deprecation but https://react.dev/blog/2024/04/25/react-19-upgrade-guide#removed-proptypes-and-defaultprops does. Should the two pages by synced?
2. https://react.dev/blog/2024/04/25/react-19-upgrade-guide#removed-proptypes-and-defaultprops says:

But it looks inaccurate, I would expect it says that React.PropTypes were deprecated from the source linked.

Source

3. The migration guides encourage to migrate to "TypeScript or another type-checking solution", but TypeScript has a limited type coverage. For instance, it doesn't support integers. We rely on this e.g. (not the most convincing example, though, you can check Material UI codebase to see other examples, like deprecated props, incompatible props combinations)

Autocomplete.propTypes = {
  /**
   * The maximum number of tags that will be visible when not focused.
   * Set `-1` to disable the limit.
   * @default -1
   */
  limitTags: integerPropType,

https://github.com/mui/material-ui/blob/2827bacf567fc95ef147d543316ffe688896db90/packages/mui-material/src/Autocomplete/Autocomplete.js#L985-L990

So to replace this, it seems that the closest alternative is to do something like this:

function DemoComponent(props) {
  if (process.env.NODE_ENV !== "production") {
    if (typeof props.bar !== "string") {
      console.error(
        `Warning: Failed prop type: Invalid prop \`bar\` of type \`number\` supplied to \`DemoComponent\`, expected \`string\`.`
      );
    }
  }

  return null;
}

Unfortunately, it's missing the component trace.

Before: https://codesandbox.io/p/sandbox/mystifying-mcclintock-mf7r5m?file=%2Fsrc%2FDemo.js%3A16%2C1

After: https://codesandbox.io/p/sandbox/agitated-orla-8kj8rh?file=%2Fsrc%2Findex.js

It seems much harder to figure out where console logs come from. So while https://react.dev/blog/2024/04/25/react-19#diffs-for-hydration-errors is a great step forward, this one feels like a step backward. Is there an alternative to it?

There is a function in https://github.com/facebook/prop-types/blob/1c9c6311c1fb8778bffc7a1ca70c273ee8a8654d/checkPropTypes.js#L20 but it doesn't log the component trace either. This function was recommended in #28328.

[cherniavskii]

Unfortunately, it's missing the component trace.

React is missing a public API for logging component stack trace.
The only way I managed to get the stack trace is this:

const getStackTrace = () => {
  let stack = '';
  const ReactSharedInternals = React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED;
  if (ReactSharedInternals != null) {
    const ReactDebugCurrentFrame = ReactSharedInternals.ReactDebugCurrentFrame;
    const stackAddendum = ReactDebugCurrentFrame.getStackAddendum();
    if (stackAddendum !== '') {
      stack = stackAddendum;
    }
  }
  return stack;
}

The problems with this solution:

• It uses internal API that differs across the major React versions
• I would rather keep my current job 😅

Does the React team consider adding public API for this?

Alternatively, we can create a community package that would encapsulate the internal API access and provide a cross-version method for getting the stack trace.

[rickhanlonii]

There are two separate issues here: PropTypes deprecation, and component stacks for console.error. The PropTypes concerns are understandable, but we're not adding support back to them. The blog posts are separate because one announces the features in 19, and the other the breaking/notable changes:

In our React 19 Beta Upgrade Guide, we shared step-by-step instructions for upgrading your app to React 19 Beta. In this post, we’ll give an overview of the new features in React 19, and how you can adopt them.

The component stack changes seem concerning, they seem to work for me in the CodeSandbox you linked:

[oliviertassinari]

they seem to work for me in the CodeSandbox you linked

@rickhanlonii the console component trace doesn't work when opening the codesandbox link standalone. It doesn't work on Vite either. I haven't tested Next.js but I don't recall seeing it work their either.

[Janpot]

Doesn't work in Next.js neither for me. I suppose normally the react devtools extension should kick in?

[cherniavskii]

There are two separate issues here: PropTypes deprecation, and component stacks for console.error.

Correct! I mentioned the component stacks in this issue because we need them for props validation errors that would replace propTypes for us.

[jbt]

I just stumbled on this issue while catching up on React 19 changes - specifically around the removal of propTypes checking, I'm concerned the documentation could have been clearer.

What's caught me off guard is that "Importing prop type checkers with React.PropTypes" and "actual checking of types defined with .propTypes" are two completely separate things, and only the former was ever actually documented & deprecated in 15.5.0, so it's a bit revisionist to say that proptypes themselves have been deprecated for that long.

As far as I can see there was no public discussion or proposal for the removal of actual prop type checking - and while I guess technically it's not a breaking change so it's not strictly necessary to put in deprecation warnings as with e.g. defaultProps, it's nonetheless caught me by surprise. I guess the ship has sailed now but I certainly would have welcomed the opportunity to contribute to any discussion when it was being considered.

[oliviertassinari]

Data from https://2023.stateofjs.com/en-US/usage/

You can conclude that:

• 70% of the code written is in TypeScript (9.33 * 0+5.6 * 0.13+4.22 * 0.25+2.26 * 0.38+5.99 * 0.5+3.16 * 0.63+10.76 * 0.75+26.47 * 0.88+32.22 * 1) (up from 50% in 2022 https://2022.stateofjs.com/en-US/usage/#js_ts_balance)
• 30% of the code written is in JavaScript (9.33 * 1+5.6 * 0.88+4.22 * 0.75+2.26 * 0.63+5.99 * 0.5+3.16 * 0.38+10.76 * 0.25+26.47 * 0.13+32.22 * 0)

We might be looking at 30% of the user base with no more types. It will be interesting to see what 2024 looks like. If this grows from 70% to 90%, it should be all fine.

Then, it's really only about the problems listed above with not having propTypes when writing TypeScript:

• no React component trace with console.error()/console.warn()
• no coverage for more specific types
• no primitives for warning deduplication in render components

[ericfortis]

Could anyone help me understand how to override class components for adding the type-value checks. That is, there is no React.Component.prototype.render.

So we can't simply:

import checkPropTypes from 'prop-types/checkPropTypes'

const oldRender = React.Component.prototype.render
React.Component.prototype.render = function () {
  checkPropTypes(this.propTypes, props, 'prop', this.name)
  oldRender()
}

Or any other approach. Thanks

---

As @oliviertassinari mentioned, I also check the values (not only the data type).
Also, as @jbt said, this deprecation caught me by surprised as well.

[github-actions]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[oliviertassinari]

Bump