Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

311
Vistas
Why are Fragments in React 16 better than container divs?

In React 16.2, improved support for Fragments has been added. More information can be found on React's blog post here.

We are all familiar with the following code:

render() {
  return (
    // Extraneous div element :(
    <div>
      Some text.
      <h2>A heading</h2>
      More text.
      <h2>Another heading</h2>
      Even more text.
    </div>
  );
}

Yes, we need a container div, but it's not that big of a deal.

In React 16.2, we can do this to avoid the surrounding container div:

render() {
  return (
    <Fragment>
      Some text.
      <h2>A heading</h2>
      More text.
      <h2>Another heading</h2>
      Even more text.
    </Fragment>
  );
}

In either case, we still need need a container element surround the inner elements.

My question is, why is using a Fragment preferable? Does it help with performance? If so, why? Would love some insight.

over 4 years ago · Santiago Trujillo
3 Respuestas
Responde la pregunta

0

  1. It’s a tiny bit faster and has less memory usage (no need to create an extra DOM node). This only has a real benefit on very large and/or deep trees, but application performance often suffers from death by a thousand cuts. This is one cut less.
  2. Some CSS mechanisms like Flexbox and CSS Grid have a special parent-child relationship, and adding divs in the middle makes it hard to keep the desired layout while extracting logical components.
  3. The DOM inspector is less cluttered. :-)

You can find the descriptions of some other use cases in this React issue: Add fragment API to allow returning multiple components from render

over 4 years ago · Santiago Trujillo Denunciar

0

Adding to all answers above there is one more advantage: code readability, Fragment component supports a syntactic sugar form, <>. Thus the code in your question can be written more easily as:

render() {
  return (
    <>
      Some text.
      <h2>A heading</h2>
      More text.
      <h2>Another heading</h2>
      Even more text.
    </>
  );
}

According to docs,

In React, this desugars to a <React.Fragment/> element, as in the example from the previous section. (Non-React frameworks that use JSX may compile to something different.)

Clutter-free, right ?

Note that you still need to use <Fragment> syntax if you need to provide key to the fragment.

over 4 years ago · Santiago Trujillo Denunciar

0

  • Added features not possible before with JSX
  • Better semantic jsx markup. Wrapper elements are used when needed not because they are forced to.
  • Less overall dom markup (increased render performance and less memory overhead)

It as simple as when you don't need a wrapper element you aren't forced to use one. Having less elements is great but I think the biggest benefit is being able to render elements in jsx that weren't previously possible and adding better semantic meaning to wrapper elements because they are optional now.

This wasn't possible before:

 <select>
    {this.renderOptions()}
 </select>

Glancing at the following in React 15 you can't tell if the wrapper element is needed or not:

<span>
  <h1>Hello</h1>
  {this.getContent()}
</span>
over 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda