Skip to content

Type Checking With PropTypes: PropTypes and defaultProps cannot be used in React version 19 and above #29510

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

Open
3 tasks done
Punith1117 opened this issue Mar 12, 2025 · 18 comments · May be fixed by #29714
Open
3 tasks done
Assignees

Comments

@Punith1117
Copy link
Contributor

Punith1117 commented Mar 12, 2025

Checks

Describe your suggestion

Issue details:

  • Both PropTypes and defaultProps does not work in functional component
  • defaultProps works but PropTypes doesn't in class component

Possible ways to fix this:

  • [quickest] Mention this same exact fact in the beginning of the article so that people can be aware of this and most importantly preventing wastage of their time in figuring out why it doesn't work (they neither get an error nor a warning when using it) It could be fixed by installing react versions lesser than 19.
  • Remove the whole propTypes and defaultProps concept (this forces the curriculum to teach typescript in detail)

Path

Node / JS

Lesson Url

https://www.theodinproject.com/lessons/node-path-react-new-type-checking-with-proptypes

(Optional) Discord Name

No response

(Optional) Additional Comments

No response

@GaneshS288
Copy link
Contributor

GaneshS288 commented Mar 12, 2025

Just adding some context here, vite's latest react template now uses react 19. So any project created with npm create vite@latest . -- --template react will not support type checking with proptypes

@MaoShizhong
Copy link
Contributor

MaoShizhong commented Mar 12, 2025

Regarding defaultProps, the Passing Data Between Components lesson was already amended in #28406 to mention defaultProps as an extra with class components and older codebases. Now that it's actually been removed from function components in React 19 (and not just giving a warning in React 18), perhaps the last sentence of that section could be tweaked to:

React now prefers the default parameter approach for function components and as of React 19, defaultProps will no longer work in function components. You may still see them used in class components or older codebases so it's still good to be aware of them.

As for propTypes, that'll definitely be a bigger team decision as to how to proceed, but I don't think any of this suggests that TypeScript is needed as a solution.

@Punith1117
Copy link
Contributor Author

Punith1117 commented Mar 12, 2025

React now prefers the default parameter approach for function components and as of React 19, defaultProps will no longer work in function components. You may still see them used in class components or older codebases so it's still good to be aware of them.

@MaoShizhong Isn't it better to mention what you said in the beginning instead of the end. Or at least somewhere in the middle? This will prevent readers from trying to run the code unnecessarily.

@MaoShizhong
Copy link
Contributor

Depending on what a maint decides, the exact wording and where can of course be up for discussion and review. I wouldn't think much needs to be done regarding defaultProps, just perhaps something that makes it clearer it no longer works in function components in React 19 (because it'll still work in class components in React 19 as well as anywhere in older versions).

@Punith1117
Copy link
Contributor Author

Punith1117 commented Mar 12, 2025

Actually, this would require a lot of refactoring rather than just tweaking a sentence since the article directs the readers to "do things" by mentioning terms like setting up, typing the command to install the packages instead of just giving the information. It's a bigger issue than I imagined it to be.

@MaoShizhong
Copy link
Contributor

I was referring specifically to the defsultProps issue which is a separate and much smaller thing to address.

The propTypes lesson is its own thing and yes, I agree is a much bigger issue with multiple long-term options, mostly rather big options. For the team, I'd suggest considering the purpose of the propTypes lesson within this React course and TOP. Given it physically cannot be used in React 19 anymore (and has been recommended against/deprecated for some time beforehand), is the lesson contents a necessity in this course?

@Punith1117
Copy link
Contributor Author

Even if it's only about defaultProps, the code snippet given there doesn't work since it's a functional component and not a class component.

@MaoShizhong
Copy link
Contributor

Hence only a small tweak is actually necessary ti be more explicit about it not working in function components. That part of the section is already clear it's just showing something you might see elsewhere and will be even clearer it's not meant for the learner to implement themselves when it says it won't work in React 19 (and class components have not been introduced yet, so a class component example doesn't seem sensible).

Though the team may decide differently of course.

@Punith1117
Copy link
Contributor Author

Okay, looking forward to the team's final decision!

@wise-king-sullyman
Copy link
Member

wise-king-sullyman commented Mar 19, 2025

At some point in the future I think we'll want to either remove or at least significantly diminish the content, but at the moment I think just adding a note at the start of the lesson is sufficient since I would wager it will still be relevant knowledge for at least the next couple years.

Thanks for making this issue and volunteering to work on it @Punith1117, and thanks to all involved for the great discussion so far!

@Punith1117
Copy link
Contributor Author

Thanks @wise-king-sullyman for assigning me the task.

Image

I would also like to add that it's been asked to use this type checking in the shopping-cart project.

@Punith1117
Copy link
Contributor Author

Punith1117 commented Mar 22, 2025

"

Note: propTypes and defaultProps are discontinued from React version 19. Please use React versions lesser than 19 to follow this lesson.

This can be done by:

  • Setting up Vite as usual
  • Changing the react version in package.json file before running 'npm install'

Change React version:

  • "dependencies": {
    "react": "^18.0.0", // Changed to React 18
    "react-dom": "^18.0.0" // Changed to ReactDOM 18
    }
  • "devDependencies": {
    "@types/react": "^18.0.10", // Updated to React 18 types
    "@types/react-dom": "^18.0.5", // Updated to ReactDOM 18 types
    }
  • Leave the rest in package.json file untouched

"
@wise-king-sullyman Is this note good enough to add it here

Image

?

@itskokeh
Copy link

itskokeh commented Apr 1, 2025

The link to the PropsTypes documentation resolves to nothing

PropsType Documentation

@typies
Copy link

typies commented Apr 8, 2025

bump.

I ran into this issue working through the "Type Checking With PropTypes" section today. This page should be updated with at least a note asap to stop confusion for readers. I spent a while this morning trying to figure out what I was doing wrong before finding the deprecation.

@Punith1117
Copy link
Contributor Author

Punith1117 commented Apr 10, 2025

@typies I faced the same exact problem. I tried a lot to figure out what was wrong. When I asked the same in discord, @GaneshS288 told me that it was deprecated from React 19. I hope the note I have drafted above gets approved by a maintainer soon.

Copy link

This issue is stale because it has had no activity for the last 30 days.

@github-actions github-actions bot added the Status: Stale This issue/PR has been inactive for over 30 days and will be closed if inactivity continues label May 11, 2025
@wise-king-sullyman
Copy link
Member

@Punith1117 apologies, I missed the discussion here. That looks good to me!

Just a note for the future this kind of back and forth about the specific change that's been proposed is usually done directly in a PR review rather than in an issue, as that makes it a bit easier for us as maintainers to stay on top of things.

@github-actions github-actions bot removed the Status: Stale This issue/PR has been inactive for over 30 days and will be closed if inactivity continues label May 14, 2025
@Punith1117
Copy link
Contributor Author

@wise-king-sullyman Sorry about that. I am still new to contributing. Thanks for pointing it out! I'll create a PR shortly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants