(855)-537-2266 sales@kerbco.com

React Children And Iteration Methods

About The Author

Arihant Verma is a Software Engineer based in India. He likes to read open source code and help others understand it. He’s a rich text editors fanatic. His …

More about
Arihant ↬

Quick summary ↬

In this article, we’ll discuss and learn about the use case of iterating over React children and the ways to do it. In particular, we will deep dive into one of the utility methods, React.Children.toArray, that React gives us, which helps to iterate over the children in a way which ensures performance and determinism.

The most obvious and common prop that developers work with within React is the children prop. In the majority of cases, there is no need to understand how the children prop looks like. But in some cases, we want to inspect the children prop to maybe wrap each child in another element/component or to reorder or slice them. In those cases inspecting how the children prop looks like becomes essential.

In this article, we’ll look at a React utility React.Children.toArray which lets us prepare the children prop for inspection and iteration, some of its shortcomings and how to overcome them — through a small open-source package, to keep our React code function the way it is deterministically supposed to behave, keeping performance intact. If you know the basics of React and have at least an idea about what the children prop in React is, this article is for you.

While working with React, most of the time we do not touch the children prop any more than using it in React components directly.

But sometimes we have to iterate over the children prop so that we can enhance or change the children without having the user of the components explicitly do it themselves. One common use case is to pass the iteration index-related information to child components of a parent like so:

Here we’re doing the following:

The user of Breadcrumbs and BreadcrumbItem doesn’t have to worry about which children should have links and how they should be styled. Inside the Breadcrumbs component, it automatically gets handled.

This pattern of implicitly passing in props and/or having state in the parent and passing the state and state changers down to the children as props is called the compound component pattern. You might be familiar with this pattern from React Router’s Switch component, which takes Route components as its children:

Now that we have established that there are needs where we have to iterate over children prop sometimes, and having used two of the children utility methods React.Children.map and React.Children.toArray, let’s refresh our memory about one of them: React.Children.toArray.

More after jump! Continue reading below ↓

Deep-dive into front-end accessibility with Carie Fisher in her upcoming Smashing workshop on . With best practices and guidelines on accessibility, assistive technology and inclusive design patterns. Online, and live.

React.Children.toArray

Let’s start by seeing with an example what this method does and where it might be useful.

We have a Debugger component, which does nothing much in terms of rendering — it just returns children as is. But it does log two values: children and React.Children.toArray(children).

If you open up the console, you’d be able to see the difference.

Let’s read the method’s documentation in React docs to make sense of what is happening.

React.Children.toArray returns the children opaque data structure as a flat array with keys assigned to each child. Useful if you want to manipulate collections of children in your render methods, especially if you want to reorder or slice children before passing it down.

Let’s break that down:

The first point says that that children (which is an opaque data structure, meaning it can be an object, array, or a function, as described earlier) is converted to a flat array. Just like we saw in the example above. Additionally, this GitHub issue comment also explains its behavior:

It (React.Children.toArray) does not pull children out of elements and flatten them, that wouldn’t really make any sense. It flattens nested arrays and objects, i.e. so that [['a', 'b'],['c', ['d']]] becomes something similar to ['a', 'b', 'c', 'd'].

Let’s see what the second point (‘With keys assigned to each child.’) says, by expanding one child each from the previous logs of the example.

Expanded Child From console.log(children)

Expanded Child From console.log(React.Children.toArray(children))

As you can see, besides flattening the children prop into a flat array, it also adds unique keys to each of its children. From the React docs:

Because the .toArray method might change the order and place of children, it has to make sure that it maintains unique keys for each of them for reconciliation and rendering optimization.

Let’s give a little bit more attention to so that each element’s key is scoped to the input array containing it., by looking at the keys of each element of the second array (corresponding to console.log(React.Children.toArray(children))).

As you can see that the fruits, which were originally a nested array inside the original children array, have keys that are prefixed with .2. The .2 corresponds to the fact that they were a part of an array. The suffix, namely :0 ,:1, :2 are corresponding to the React elements’ (fruits) default keys. By default, React uses the index as the key, if no key is specified for the elements of a list.

So suppose you had three level of nesting inside children array, like so:

The keys will look like

The $1, $2, $3 suffixes are because of the original keys put on the React elements in an array, otherwise React complains of lack of keys ? .

From whatever we’ve read so far we can come to two use cases for React.Children.toArray.

If there’s an absolute need that children should always be an array, you can use React.Children.toArray(children) instead. It’ll work perfectly even when children is an object or a function too.

If you have to sort, filter, or slice children prop you can rely on React.Children.toArray to always preserve unique keys of all the children.

There’s a problem with React.Children.toArray ?. Let’s look at this piece of code to understand what the problem is:

If you see what gets rendered for the children of the fragment, you’ll see that both of the links get rendered inside one li tag! ?

This is because doesn’t traverse into fragments. So what can we do about it? Fortunately, nothing ? . We already have an open-sourced package called . It’s a small function that does its magic.

Let’s see what it does. In pseudo-code (these points are linked in the actual code below), it does this:

Let’s retry our previous example to use this function and see for ourselves that it fixes our problem.

Woooheeee! It works.

As an add-on, if you are new to testing — like I am at the point of this writing — you might be interested in 7 tests written for this utility function. It’ll be fun to read the tests to deduce the functionality of the function.

The Long Term Problem With Children Utilities

The problem with using Children methods to change children behavior is that they only work for one level of nesting of components. If we wrap one of our children in another component, we lose composability. Let’s see what I mean by that, by picking up the first example that we saw — the breadcrumbs.

Although our new component <BreadcrumbItemCreator /> rendered, our Breadcrumb component doesn’t have any way to extract out the link prop from it, because of which, it doesn’t render as link.

To fix this problem React team had come with — now defunct — experimental API called react-call-return.

Ryan Florence’s Video explains this problem in detail, and how react-call-return fixed it. Since the package was never published in any version of React, there are plans to take inspiration from it and make something production-ready.

To conclude, we learned about:

You might also be interested in reading how to use other Children methods to do everything you can do with children in Max Stoiber’s blog post React Children Deep Dive.

This content was originally published here.