DEV Community

✔5 Best Practices for Writing Cleaner and More Readable React Code

Pratham Srivastava on December 17, 2023

In the world of software development, code readability is paramount. We spend more time reading code than writing it, making it crucial to adopt pr...

Read full post

SunflowerToadTheOrbiter • Dec 18 '23 • Edited

My opinion on #5: while making the code more concise, this approach makes the function signature less recognizable, especially when you start working with TypeScript (additional types for long lines).

Also i find the syntax to then be similar to the one beeing used for states in functional react programing:

function Bongo(props) {
  const { name, image } = props;
  const [isHappy, setIsHappy] = useState(true);
}

Deconstructing in the function params may work ok for Javascript but i see this not beeing a best practice for typescript.

Brendan • Dec 19 '23

Thanks for this article :)

I don't agree with number 4 entirely though (Using && operator in JSX) because it can lead to bugs.

Here is more information:
crocoder.dev/blog/react-conditiona...

Pratham Srivastava • Dec 19 '23

Thanks for the additional info.

<div>{dodos.length && `dodos: ${dodos.map(() => '🦤').join(' ')}`}</div> 

//both will work 
<div>{dodos.length >0 && `dodos: ${dodos.map(() => '🦤').join(' ')}`}</div> 
<div>{!!dodos.length && `dodos: ${dodos.map(() => '🦤').join(' ')}`}</div>

Cupcakes • Dec 17 '23 • Edited

Hello. I have a question about #5. I see this being used in a lot of projects, but I have never used it in practice. My reasoning is that, when props are destructured in the parameters list, I am not able to console.log(props) from within the body of the component. This is something that I end up doing a lot while building projects. I am wondering if there is any benefit to destructuring props in the arguments list other than it's more concise?

Rense Bakker • Dec 18 '23

Destructuring early helps to prevent dependency on irrelevant props for the component's side effects and children. Wanting to log all the props seems strange though? Can you elaborate why you'd want to log the entire props object, instead of the specific props that you're interested in? If you don't trust which props are passed down to your component, something is wrong with the component's contract...

Cupcakes • Dec 19 '23

Hi Rense,
Thank you for your reply. You asked:

Can you elaborate why you'd want to log the entire props object, instead of the specific props that you're interested in?

One of the most convincing and frequent reasons (in my experience) is to detect spelling mistakes. Lets say that a generic <Button> component is used as a leaf node in an app. This component is blue by default, but is may also appear as light grey when the disabled prop is set to true. This prop may also be explicitly set to true or not set at all.

While manually testing this app in a browser, I notice that it does not render as light grey when I expect it to. I'm pretty sure I did everything correctly. To test, I cab console.log(props) to see what was sent to the component. In this imaginary example, perhaps isDisabled was sent by mistake from one it the button's ancestors. I now know what to look for.

I've ran into many scenarios where it has been beneficial to see what data has been passed to a component.

If you don't trust which props are passed down to your component, something is wrong with the component's contract...

Totally. Being able to see what has been passed down helps me to determine what the issue is and points me in the right direction of how it may be fixed.

I'm still a bit confused as to how these two styles are different:

const MyComponent = (props) => {
  const { prop1, prop2 } = props
}

const MyComponent = ({ prop1, prop2 }) => {
}

Are there performance or other benefits to be gained by destructuring in the parameter list rather than on the very first line?

Rense Bakker • Dec 19 '23

Hmm, but wouldnt it be better to use typescript or prop types to enforce your components contract with the outside world so this use case cannot happen at all? npmjs.com/package/prop-types

Performance wise eventually it doesn't matter if you destructure on the next line no, it's more of a code practice that people follow, to help make code easier/faster to read/understand.

oadrian2 • Dec 23 '23

I would imagine using React's dev tools to be a more efficient way to get that prop information. You can then even see the cascade of all of the various prop drilling that led to those values.