-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Adjusted no-deprecated rule for React 16.3.0 #1750
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
Merged
Merged
Changes from 1 commit
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not suggest getDerivedStateFromProps? And why not lint against UNSAFE_ lifecycle methods?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because that's only one of the use cases for
componentWillReceiveProps
, so it's not always the right recommendation.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the point of linting against
componentWillReceiveProps
if we're just going to recommendUNSAFE_componentWillReceiveProps
anyway? Both are equally bad, no? They do the exact same thing, just one has a scary name.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So that a human can look at it and make a human judgement about which to use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sahrens, legacy lifecycles (including
componentWillReceiveProps
) will continue to work until version 17, however you will see deprecation warnings for them. In version 17, it will still be possible to use them, but they will be aliased with an “UNSAFE_”, see details.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that
no-deprecated
can and will warn against them, but not until every use case of them has a replacement (this is not currently the case).Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There're no deprecation warnings regarding using

UNSAFE_
methods in strict mode, there is unsafe lifecycle methods warning:So I'm not sure that
no-deprecated
is appropriate place for that (at least for now).I'm also not sure regarding
strict-mode
rule, I vote for addingno-unsafe
rule that will be more specific. In the same way that it was done forno-string-refs
rule -- using string ref API also cause warnings in strict mode. @ljharb, I could take a look at it if you find it reasonable.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Modes are not a conceptual pattern I'd want to encourage, "strict" or otherwise.
I don't think a "no-unsafe" rule makes sense when for users of React < 16, it is perfectly safe, and for users of React >= 17, the methods won't work at all.
The purpose of these deprecations from React is to encourage people to migrate to replacements as early as possible, so the breaking change in v17 that removes the old ones will be as painless as possible. When React 17 comes out, we'll certainly lint against invalid lifecycle methods, including newly-invalid ones - but I'm not sure how much value we'd get out of warnings in React 16 outside of
no-deprecated
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not true, even in version 17, it will still be possible to use UNSAFE_ methods, see Component Lifecycle Changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that case, a separate "no-unsafe" rule, that only focuses on UNSAFE_ methods, seems reasonable.