Logic-less JSX

Approach 1: Variables

An intuitive approach to move some logic out of our JSX can be to create some intermediate variables in the body of the function of the component:

const Animal = ({ id, name, legCount, isFriendly }) => {
  const url = `url/animal/${id}`
  const legCountStr = String(legCount ?? '?')
  const friendliness = isFriendly ? 'Friendly' : 'Unfriendly'
  const hasNotEnoughData = legCount === undefined && isFriendly === undefined

  return (
    <li>
      <a href={url}>{name}</a> - {legCountStr} legs
      {friendliness && ` - ${friendliness}`}
      {hasNotEnoughData && ' - Not enough data!'}
    </li>
  )
}

The strength of this approach is that it is pretty simple to understand, and doesn't introduce any new concept. The body of the function can get pretty big if there is a lot of logic, but at least that logic is right there, accessible and clear.

Approach 2: Second component

We can move that logic into a second component that will transform the props, and possibly do other smart things such as handling a state. I chose to add a Cmp suffix to the markup component. It looks like this:

const AnimalCmp = ({ name, url, legCount, friendliness }) => (
  <li>
    <a href={url}>{name}</a> - {legCount} legs
    {friendliness && ` - ${friendliness}`}
    {hasNotEnoughData && ' - Not enough data!'}
  </li>
)

const Animal = ({ id, name, legCount, isFriendly }) => (
  <AnimalCmp
    name={name}
    url={`url/animal/${id}`}
    legCount={String(legCount ?? '?')}
    friendliness={isFriendly ? 'Friendly' : 'Unfriendly'}
    hasNotEnoughData={legCount === undefined && isFriendly === undefined}
  />
)

The strength of this approach is the isolation of the Cmp component, which can be used for pure logic-less rendering in a Storybook. It also has a clean separation of concerns, and you can put those components in 2 different files if that's what you want. The downside of the intermediate component is that it can be confusing at first. It also adds one extra depth level per component which is a bit annoying when using React Devtools, and might have some performance impact that I haven't tested.

If the components have a state, I'd favor putting that state in the "transforming" component rather than the Cmp one, to keep the latter free from any logic.

Approach 3: Function

If you extract the transforming logic into a function, you get this:

const getAnimalRenderData = ({ id, name, legCount, isFriendly }) => ({
  name,
  url: `url/animal/${id}`,
  legCountStr: String(legCount ?? '?'),
  friendliness: isFriendly ? 'Friendly' : 'Unfriendly',
  hasNotEnoughData: legCount === undefined && isFriendly === undefined,
})

const Animal = props => {
  const {
    name,
    url,
    legCountStr,
    friendliness,
    hasNotEnoughData,
  } = getAnimalRenderData(props)

  return (
    <li>
      <a href={url}>{name}</a> - {legCountStr} legs
      {friendliness && ` - ${friendliness}`}
      {hasNotEnoughData && ' - Not enough data!'}
    </li>
  )
}

This version is a bit of a mix of the last two. It is simpler than introducing a new component, but doesn't give you the option to isolate the logic-less JSX code, and the function cannot hold a state. Its special feature however is that unlike the previous approaches, this function can be used outside of the context of React, by your server for instance, or if you switch to a different UI library than React one day.

As you can see, if we deconstruct our render data, and if our line is too long, we might have to place each property on a single line, which takes a lot of space (at least that's how Prettier would format it). The first 2 approaches don't have this problem.

Approach 4: Class

This is very similar to the function approach, except that it is using a class:

class AnimalRenderData {
  constructor(data) {
    this.data = data
  }
  get name() {
    return this.data.name
  }
  get url() {
    return `url/animal/${this.data.id}`
  }
  get legCountStr() {
    return String(this.data.legCount ?? '?')
  }
  get friendliness() {
    return this.data.isFriendly ? 'Friendly' : 'Unfriendly'
  }
  get hasNotEnoughData() {
    return this.data.legCount === undefined && this.data.isFriendly === undefined,
  }
}

const Animal = props => {
  const {
    name,
    url,
    legCountStr,
    friendliness,
    hasNotEnoughData,
  } = new AnimalRenderData(props)

  return (
    <li>
      <a href={url}>{name}</a> - {legCountStr} legs
      {friendliness && ` - ${friendliness}`}
      {hasNotEnoughData && ' - Not enough data!'}
    </li>
  )
}

The main difference with the function implementation is that with a class, the transforming functions are only executed when those properties are accessed, which makes it more performant, at the cost of being more verbose. But if you intend to use this render data outside of React, to get the url of an animal on the server for instance, this is a more optimized choice than the function.

What goes in my JSX

Code is clearer than words so there you go:

{str} // strings
<Cmp /> // components

foo && <Cmp /> // shows if truthy
foo === somevalue && <Cmp /> // shows if foo is somevalue

!foo && <Cmp /> // shows if falsy
foo !== somevalue && <Cmp /> // shows if foo is not somevalue

isNil(foo) && <Cmp /> // shows if null or undefined (Lodash)
exists(foo) && <Cmp /> // shows if not null or undefined (custom !isNil function)

arr.length > 0 && <Cmp /> // shows if array has at least 1 item
arr.length === 0 && <Cmp /> // shows if array is empty

!isEmpty(obj) && <Cmp /> // shows if object has properties (Lodash)
isEmpty(obj) && <Cmp /> // shows if object is empty (Lodash)

arr.map(({ id }) => <Cmp key={id} />) // renders array

foo ? <CmpA /> : <CmpB /> // show CmpA if foo is truthy, CmpB if not

{
  caseA: () => <CmpA />,
  caseB: () => <CmpB />,
  undefined: () => <CmpC />
}[switchValue]() // an inline switch of components based on switchValue

condA ? (
  <CmpA />
) : condB ? (
  <CmpB />
) : condC ? (
  <CmpC />
) : (
  <CmpD />
) // chained ternaries - just think of them as else-ifs

If conditions are more complex than this, then I would probably put them in the render data. This list is very likely to change.

What goes in the render data

I guess most logic that derives the props and ends up going into the JSX could be "render data". It's pretty much just helpers to keep your JSX as lean as possible. It's difficult to make an exhaustive list of that one.

However I think it is a good idea to not put any JSX code in the render data. It can be tempting to do something like:

const foo = isFoo ? <Cmp1 /> : <Cmp2/>

and inject {foo} in the JSX, but if we do this, we break the separation of concerns and the features that come with it. Instead, create a new component:

const Foo = () => isFoo ? <Cmp1 /> : <Cmp2 />

and use <Foo />.

Another thing that should probably not go in the render data is styles. Even if they are based on props.

Styles

I try to have as little styles in the JSX as possible, because just like logic, they can make a big mess in our JSX. And the whole point of logic-less JSX is to keep the JSX lean. Note that I am not only referring to inline styles, but also CSS-in-JS libraries that support writing styles in the JSX. Instead, I prefer using CSS-in-JS classes.

In my opinion, an essential feature for a CSS-in-JS library is to apply styles based on props. Styled Components, Emotion (with Styled Components), JSS, or Material UI support it for instance. With that feature, no need to put styles in the render data.

CSS-in-JS brings encapsulation and styles inheritance to CSS. So I think now is a good time to switch back to the old way of writing styles, with "semantic" classnames such as <div className={css.post} /> instead of things like:

<div class="block-list media-container media-container--dark" />

This helps keeping our JSX light too. But that's a very big debate for an other day.