DEV Community

Cover image for Clean Coding React - Props
Bence Szabo
Bence Szabo

Posted on

Clean Coding React - Props

#react #typescript #cleancode #tips

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 */
}
Enter fullscreen mode Exit fullscreen mode

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 it MadeUpCompoProps 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 like props.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)

Collapse
 
k_penguin_sato profile image
K-Sato •

I follow the same pattern. sometimes I get tempted to name Props something else tho haha

Collapse
 
finnhvman profile image
Bence Szabo •

Stay strong and name it Props :D

So you are using interface as well?

Collapse
 
thekashey profile image
Anton Korzunov • • Edited

The main not answered question here is those "many ways".

Many ways

  • probably the initial "not clean" solution 
const MadeUpCompo = (props: {
  size: Size
  variant: Variant
  thirdProperty: ThirdProperty
}) => {
  /* implementation of component */
}
Enter fullscreen mode Exit fullscreen mode
  • however probably it was even worse 
const MadeUpCompo = (props: any) => {
  // good luck mate
}
MadeUpCompo.propTypes = {
  // and we are not using propTypes as well. Why should we?
}
Enter fullscreen mode Exit fullscreen mode
  • using React.FC 
interface Props {
  size: Size
  variant: Variant
  thirdProperty: ThirdProperty
}

const MadeUpCompo: React.FC<Props> = ({ size, variant, thirdProperty }) => {
  /* implementation of component */
}
Enter fullscreen mode Exit fullscreen mode
  • using inline React.FC 
const MadeUpCompo: React.FC<{
  size: Size
  variant: Variant
  thirdProperty: ThirdProperty
}> = ({ size, variant, thirdProperty }) => {
  /* implementation of component */
}
Enter fullscreen mode Exit fullscreen mode

Lets check

  • 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.

Ok, no objections, however that's not that important.

  • 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 it MadeUpCompoProps but that's repetitive, longer, and I don't think it enhances clarity any more.

What about having more that one component in one file?

  • Props are always destructured so you just use the size, variant, etc. identifiers, instead of writing something like props.size, props.variant, etc.

No brainer. I didn't get the point why it was even considered as possible

  • Props are typed, I catch errors compilation time. I avoid using any for "typing" props

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 about type or interface. What about React.FC vs typing function arguments?

Collapse
 
finnhvman profile image
Bence Szabo •

What about having more that one component in one file?

I rarely put more components in one file but when I do, I name the props of 'Secondary' Component 'SecondaryProps'.

No brainer.

What's no brainer for you, might not be no brainer for everyone.

You forgot to share the story itself.

I intentionally made this post short, I want to write really short, cut to the chase posts.

Collapse
 
thekashey profile image
Anton Korzunov •

Short posts keep more secretes and could leave a reader with even more confusion.

What's no brainer for you, might not be no brainer for everyone.

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:

  • => vs function? There is a choice I could make, and what should I pick? Is there any difference?
  • or, in your example you've used =>, but as a result functions are variables, and could be typed as variables. React.FC or :Props? Is there any difference?

Read next

torver213 profile image

Dark mode & light mode in next. Js 14 app router with material-ui without ui flickering

Peter Kelvin Torver -

thinkthroo profile image

Manage your versioning and changelogs using Changesets

thinkThroo -

high5dev profile image

Applying an Image on a 3D Model with React Three Drei’s Decal

Full-stack Software Engineer -

guillaumesere profile image

Créer une Radio en Ligne avec l'API Radio Browser

Guillaume Sere -