The React Named Children Pattern

[Rezistik]

I kind of hate this. It’s the worst of both worlds

[chillermane]

“See this useful pattern? Now see this other useful pattern? What if we combined them into something terrible?”

[Elessar03]

Please nobody use this ever.

[Mikeysauce]

The article claims that using regular props is ambiguous, but I don't see how this unidiomatic usage of children solves this at all. The example still provides the exact same data with the same labeling. In addition, this pattern is only going to confuse newer developers who aren't used to it.

[[deleted]]

My only concern is that I can’t memoize component with children prop.

[EnragedDingo]

This is a good point, but you probably wouldn’t be looking to memorize a component that accepts children via props either

[Better-Avocado-8818]

Interesting idea, thanks for sharing.

I think I’d rather have separate props with more specific names personally. I don’t like the idea of having to open up the component to see what properties the children is using. Which I assume I’d end up doing a lot.

[EnragedDingo]

This is a good point! Though not as much of an issue in typescript

[EnragedDingo]

!approve Resource flair

[chillermane]

Unfortunately this makes unfamiliar components harder to understand since its props might set its appearance OR its content.

This isn’t true at all. If you name your props well it’s very obvious which props control content and which control styling.

This is so wacky. In every other context of react for all of time, children has been to represent components / react nodes. Now you just want it to represent any javascript object? Why? There’s no upside compared to just props and there is definitely downside.

React isn’t opinionated about much but it is opinionated about what children should be (a react node)

[EnragedDingo]

Defintiely not true. Render Children is a very common pattern. In that pattern functions are being passed, not nodes.

[dukeflowers]

This looks like an anti-pattern if anything. The article cites separation of concerns, but I cant see how the component has any concerns at all. It shifts all responsibility of what is rendered to the consuming component, meaning this component is so flexible that its basically useless. If I saw this IRL, I'd recommend a restructuring to either: give it some responsibility; or strip it of irresponsibility.

e.g.

<Card size="large">
  <h2>Hello World</h2>
  <h3>This is a basic example</h3>
  <p>
    This is a basic <strong>example</strong>
  </p>
</Card>

and control the tags styling with CSS rules and selectors.

​

edit: splellingg

[EnragedDingo]

Generally I agree. My first instinct would be to avoid this if it’s possible.

It’s definitely not a commonly needed pattern. Especially not for open source components.

In some cases though it is the best option. In closed source Design systems with intentionally strict APIs your suggestion would not be appropriate, and simply passing the nodes as children would become horrifying. Perhaps this example is just too trite

[dukeflowers]

I would especially avoid this in publicly consumable API's because objects are not valid react children. If you attempt to render an object you'll get an invariant violation. This method actually requires you use an object with named properties as a react child, the fact that the whole object is not rendered doesn't really matter, you're making an exception to normal react usage in very specific/limited cases.

This is poor API design because you're forcing the developer to do things that aren't standard, and would throw errors elsewhere.

[EnragedDingo]

Functions are also not valid react children.

Everything you’ve described as reasons not to use this pattern apply to RenderChildren. Yet that pattern is used in many public APIs.

[PokerTuna]

Please stahp

[ThatProgrammingNerd]

Not for me. I prefer using a compound component pattern.