React - how to render adjacent JSX elements

If you've been using React you must know already that we are only allowed to render one JSX (that code you find in the return statement and looks like HTML but it's not) element at a time. Trying to break this rule will result into an error like the one we can see bellow:

SyntaxError: Adjacent JSX elements must be wrapped in an enclosing tag. Did you want a JSX fragment <>...</>?

This can be easily fixed by wrapping our two elements into a div, which would be treated by React as the single element it needs to behave correctly..

Another way to avoid this problem is by transforming the code in the return block into an array of elements. It looks weird and I never use this approach but it's good to know it's out there (note that you still need to provide a unique key for each element so you don't get an error):

We could also wrap all our elements into a React.Fragment. It lets us group as many components as we want, without adding an extra node to the DOM. It behaves similar to a div and I don't think it has any real advantages over divs, unless we use it in really large applications where not creating extra nodes would help performance. You can write a React.Fragment in two ways: <React.Fragment></React.Fragment> or <></>.

Another solution to our problem would be a HOC (higher order component). We can create one with the single purpose of wrapping our JSX elements every time we need to (since it's a component as any other, it's reusable and we can include it in our code as many times as we want).

We create a HOC which does nothing than rendering its children (which in our case are all the JSX elements we need to display).

Every React component has a special (default) prop called children and the children represent everything we want to put in between the opening and the closing tags of a component.

Image source: Goran Ivos/ @goran_ivos on Unsplash

Comments

[Joseph Mawa]

Thanks for the article.

Another way to avoid this problem is by transforming the code in the return block into an array of elements.

I have never thought about this. Don't you need a unique key for elements in the array?
According to the React docs.

Keys help React identify which items have changed, are added, or are removed. Keys should be given to the elements inside the array to give the elements a stable identity.

Or perhaps keys are for dynamic element lists?

[Arika O]

Actually you do, I totally forgot about that. This is the reason I find it very inconvenient to use, because of the key. Thank you for the observation, I'll edit in a bit.

[Joseph Mawa]

A quick question here. I know about HOC but i am struggling to make sense of the parameter. What is { children: React.ReactNode } part of the parameter?

[Arika O]

That's actually Typescript code. For some reason, the online editor I am using to test my code was throwing an error because I didn't specify the children type, so I had to add it (probably Typescript was included in the dependencies). That code translates to: the children of this HOC should be of type React.ReactNode. If you don't work with TS, you can skip that code all together.

[Joseph Mawa]

Thanks. I am already overwhelmed by the amount of material i have to learn. I don't want to add TS to the list.

[Arika O]

If you will ever want to learn TS, I would advise you to learn it separately from React, otherwise it will be very overwhelming, as you said. I had to learn them at the same time for work and sometimes I couldn't tell which one is a React feature and which one is TS. Good luck!

[Leiv Fredrik Berge]

The performance difference is probably negligible, but the semantics is not. As I see it, it's the main differential between div and fragment. Often the parent component is semantically related to the children.

<ul>
  <div>
    <li>a child</li>
    <li>another child</li>
  </div>
</ul>

That's no good, and fragment solves this.

[Will G]

Thanks for the post. I'm going to try and use Fragments more in my code!

[Arika O]

Hope it helped :).