React: The Battle of Implicit vs. Explicit Returns. Which side are you on?

#webdev #javascript #discuss #react

I was reviewing PRs this morning and found myself making the same syntax nitpick for the third time this week.

It brought up a constant internal battle I have when writing modern React: **Implicit vs. Explicit returns in arrow functions.**

We all love arrow functions. They transformed clunky class components into sleek functional components. But in the pursuit of "sleekness," are we sometimes sacrificing readability?

I want to hear where the community draws the line.

## The Contenders

Quick refresher on the two styles we're fighting over.

### 1. The Implicit Return (The "Sleek" one)

If your component does nothing but dump props straight into JSX, you can ditch the curly braces `{}` and the `return` keyword entirely. You usually wrap the JSX in parentheses `()`.

It looks neat, tidy, and very "functional."

```

jsx
// Look ma, no curly braces!
// Very clean for simple presentational components.
const UserCard = ({ username, avatarUrl }) => (
  <div className="card">
    <img src={avatarUrl} alt={username} />
    <h3>{username}</h3>
  </div>
);

2. The Explicit Return (The "Safe" one)

This uses the standard block body syntax with curly braces {}. Because you opened the braces, you must type the return keyword to render anything.

You are forced to use this if you have any logic, hooks, or variable declarations before rendering.


jsx
const UserCard = ({ user }) => {
  // We have logic before rendering...
  const displayName = user.name.toUpperCase();
  const isPremium = user.tier === 'gold';

  // ...so we MUST be explicit with the return.
  return (
    <div className={isPremium ? 'gold-card' : 'standard-card'}>
      <h3>{displayName}</h3>
    </div>
  );
};

The Grey Area (Where the debate lies)

Nobody argues about the examples above. The problem is the grey area.

The "Habitual Explicit"

Sometimes I see developers using explicit returns out of sheer habit, even when there is zero logic before the return. It adds three extra lines of boilerplate code (the braces and the return keyword) for no functional reason.

The "Tortured Implicit"

Conversely, I often see developers trying way too hard to keep the "sleek" implicit syntax. They end up nesting ternary operators four levels deep inside the JSX just to avoid opening up curly braces and writing a messy if/else block before the return.

This might look "cooler," but it's a nightmare to read 6 months later.

The "Gotcha" Trap ⚠️

And let's not forget the classic rookie mistake. If you try to implicitly return an object literal (common in utility functions or older Redux mapStateToProps), JavaScript thinks the object braces are function body braces.


javascript
// ❌ WRONG. Returns undefined. JS gets confused.
const getInitialState = () => { id: 1, active: true };

// ✅ CORRECT. You must wrap the object in parentheses.
const getInitialState = () => ({ id: 1, active: true });

The Discussion

My general rule of thumb: Use implicit returns by default for brevity, but switch to explicit the second the JSX becomes hard to scan on a single pass.

Readability > Brevity. Every time.

But I know many teams enforce strict linting rules one way or the other.

What about you?

Are you Team Implicit (keep it short) or Team Explicit (keep it obvious)?
Do you feel that implicit returns make code harder to debug?

Let's debate syntax in the comments! 👇

DEV Community