Clean code is code that is easy to understand and easy to change.
When you are developing a React application in TypeScript, you most likely come across the problem of defining the type of the props
of a component. Now this isn't something that's hard to solve, on the contrary: it can be solved in many ways! The problem comes with "many ways".
In my few months of working with React in TypeScript I came to the conclusion to use the following pattern illustrated by a made-up component:
interface Props {
size: Size
variant: Variant
thirdProperty: ThirdProperty
}
const MadeUpCompo = ({ size, variant, thirdProperty }: Props) => {
/* implementation of component */
}
Why do I use this pattern?
- The declaration of the
Props
interface is always before the component. I find this cleaner than declaring the type of props inline which can become quite cluttered after a few properties. - I always use the name
Props
for the interface so I never have to think for even a second about its name. One other pattern I see would be naming itMadeUpCompoProps
but that's repetitive, longer, and I don't think it enhances clarity any more. - Props are always destructured so you just use the
size
,variant
, etc. identifiers, instead of writing something likeprops.size
,props.variant
, etc. - Props are typed, I catch errors compilation time. I avoid using any for "typing" props
One last thing I thought about is whether the Props should be an interface or type alias. At this point I don't think it matters much, but here is a well-fitting article connected to this: Type aliases vs. interfaces in TypeScript-based React apps
What do you think? Do you find this pattern useful?
Top comments (5)
I follow the same pattern. sometimes I get tempted to name
Props
something else tho hahaStay strong and name it
Props
:DSo you are using interface as well?
The main not answered question here is those "many ways".
Many ways
React.FC
React.FC
Lets check
Ok, no objections, however that's not that important.
What about having more that one component in one file?
No brainer. I didn't get the point why it was even considered as possible
The same, why you could or should or may use any?
In other words
In other words - it was something very bad, and this is how to make it not that bad. However, you lost "the journey". You forgot to share the story itself.
This is not "Clean Coding React - Props" - it's a super tiny part of it, told without context.
One last thing
should not be abouttype
orinterface
. What aboutReact.FC
vstyping function arguments
?I rarely put more components in one file but when I do, I name the props of 'Secondary' Component 'SecondaryProps'.
What's no brainer for you, might not be no brainer for everyone.
I intentionally made this post short, I want to write really short, cut to the chase posts.
Short posts keep more secretes and could leave a reader with even more confusion.
So this is it! This is why you cannot throw fully backed answers, but have to explain why they are correct, and display the incorrect solutions as well, so the reader would be able to "find" themselves in your story - like "I am doing it right", or "I am doing it wrong?"
Sometimes you have to have those proofs just to prove that your solution is correct. Prove to yourself, not only to the reader. Be able to answer Devil's advocate questions.
Here a few:
=>
vsfunction
? There is a choice I could make, and what should I pick? Is there any difference?=>
, but as a result functions are variables, and could be typed as variables.React.FC
or:Props
? Is there any difference?