Sort-comp rule doesn't enforce getDerivedStateFromProps placement
See original GitHub issueWith “react/sort-comp”: “warn” provided code shouldn’t be considered valid:
static getDerivedStateFromProps(nextProps, prevState) {}
state = {}
Tested on version 7.8.2
Issue Analytics
- State:
- Created 5 years ago
- Reactions:2
- Comments:9 (9 by maintainers)
Top Results From Across the Web
Why getDerivedStateFromProps does not allow to re-render ...
When a make an update to the component's state, the state changes (and the component did after updated) but still renders the previous...
Read more >eslint-plugin-react | Yarn - Package Manager
List of supported rules ; state-in-constructor, Enforce class component state initialization style ; static-property-placement, Enforces where React component ...
Read more >You Probably Don't Need Derived State – React Blog
Anti-pattern: Unconditionally copying props to state A common misconception is that getDerivedStateFromProps and componentWillReceiveProps are ...
Read more >eslint-plugin-react @ 7.10.0 .. 7.12.4 - Package Diff
+* add [`jsx-fragments`][] rule to enforce fragment syntax ([#1994][], ... +* [`sort-comp`][]: Fix fixer in case of more than 10 props ([#2012][], ...
Read more >React specific linting rules for ESLint - BestofReactjs
react/sort-comp, Enforce component methods order ... Rule `require-default-props` does not support default parameters in stateless function.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
aha, this seems to be a bug in the sort-comp implementation then - since the lifecycle methods are typically instance methods, but
getDerivedStateFromProps
is a static method.cc @joe-denea / #1771 which has tests for the “valid” case for this method, but not for the “invalid” case.
Fixed in #1795.