In React world, developers thrown around various function styles. For example:

const Text1 = (props) => (

const Text2 = ({ message }) => (

function Text3(props) {
  return <div>{props.message}</div>

function Text4({ message }) {
  return <div>{message}</div>

Took from reddit Which one is better? Which one should you use?

Quick answer: the four are equivalent.

As stated in this discussion on Twitter, at the end of the day it doesn’t matter and it is more of a personal preference.

It so doesn’t matter — Dan Abramov (@dan_abramov) May 16, 2018

What is important is to stick with one when building an application. This way:

  • Your code will be easier to read because it use the same convention everywhere
  • You will focus on building the app instead of thinking about how to write your components.
  • You won’t confuse the person who read the code (could be you!) by writing similar code in different ways.

My personal preference

I use named functions with destructed props to define my components:

function Text4({ message }) {
  return <div>{message}</div>

My personal preference: named function with destructured props

Why this style? Let’s compare with alternatives:

function vs const

When using a const, I read it as “I’m defining an anonymous function and storing it in a variable”. While with a function it’s like “here is a function”.

It is longer to type but it is easier to read.

Destructed props

What I like about destructed props is that I know what are the accepted props as I read the component. I know this is not a strong argument, since there are other ways to do it. But this is the easier 😇

How to be consistent without thinking about it

“I want to write code. Not spend cycles on formatting.”

There are tools that help to maintain the same code convention in our code 🥰

In JavaScript world, the most popular is Prettier which is an opinionated code formatter. It means that when you click “save”, it updates your code to follow certain rules 🧙

Feeling overwhelmed by React?

React gives you a lot of flexibility to build applications. But too many choices lead us to analysis paralysis, making us spend hours on project configuration instead of building our product.

I created a FREE e-book about good practices to avoid overthinking so you can focus more on building.

✨ Chapters ✨

  1. Code styling and quality.
  2. Organizing your project files.
  3. How to manage your state.