DEV Community

Discussion on: Clean Coding React - Props

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?