After being configured with the NPX ESLint –init directive, ESLint is required to declare return types for components:
// Missing return type on function
export default function Transcript(props: TranscriptProps) {
const {style} = props
return <View style={style}>{... }</View>
}
Copy the code
Add the return type declaration as required:
export default function Transcript(props: TranscriptProps) :React.ReactElement {
const {style} = props
return <View style={style}>{... }</View>
}
Copy the code
However, such a type declaration seems meaningless and too cumbersome. Then I think of ignite, which has the most rigorous and excellent code style in my knowledge. This project chooses to rewrite function components into the form of arrow functions. FunctionElement is used to simplify code and enhance type-hinting functions.FunctionElement is also used to decompose props directly in the parameter.
const Transcript: React.FC<TranscriptProps> = ({style}) = > {
return (
<View style={style}>{... }</View>)}export default Transcript
Copy the code
Everything looks good… But ESLint tends to report errors for such delicate code 😅
'style' is missing in props validation eslint(react/prop-types)
Copy the code
I looked through issues and found a discussion about this issue.
- Eslint-plugin-react requires us to use it
PropTypes
To perform runtime type checking - But it’s actually already used here
TypeScript
Perform static type checking - I configured the parser in ESLint to be
@typescript-eslint/parser
- The parser may have problems resolving the pass type
In the issue, I suggest using the traditional function keyword to declare function components, but if we want to use the convenience of arrow functions, such an approach will not work. There are many debaters who would like to keep the form of the arrow function, and some of them suggest that it can be written this way to avoid errors:
const Transcript: React.FC<TranscriptProps> = ({style}: TranscriptProps) = > {
return (
<View style={style}>{... }</View>)}export default Transcript
Copy the code
Maybe using babel-eslint-parser would solve this problem, but in the end I used the simplest solution provided in the issue to save trouble: