¿Por qué los fragmentos en React 16 son mejores que los divs de contenedores?
FragmentsEn React 16.2, se agregó soporte mejorado . Puede encontrar más información en la publicación del blog de React aquí.
Todos estamos familiarizados con el siguiente código:
render() {
return (
// Extraneous div element :(
<div>
Some text.
<h2>A heading</h2>
More text.
<h2>Another heading</h2>
Even more text.
</div>
);
}
Sí, necesitamos un contenedor div, pero no es gran cosa.
En React 16.2, podemos hacer esto para evitar el div contenedor circundante:
render() {
return (
<Fragment>
Some text.
<h2>A heading</h2>
More text.
<h2>Another heading</h2>
Even more text.
</Fragment>
);
}
En cualquier caso, todavía necesitamos un elemento contenedor que rodee los elementos internos.
FragmentMi pregunta es, ¿por qué es preferible utilizar un ? ¿Ayuda con el rendimiento? Si es así, ¿por qué? Me encantaría tener una idea.
- Es un poquito más rápido y utiliza menos memoria (no es necesario crear un nodo DOM adicional). Esto sólo tiene un beneficio real en árboles muy grandes y/o profundos, pero el rendimiento de la aplicación a menudo se ve afectado por mil cortes. Este es un corte menos.
- Algunos mecanismos CSS como Flexbox y CSS Grid tienen una relación especial entre padres e hijos, y agregar
divmensajes de correo electrónico en el medio dificulta mantener el diseño deseado al extraer componentes lógicos. - El inspector DOM está menos abarrotado. :-)
Puede encontrar descripciones de algunos otros casos de uso en este problema de React: Agregar API de fragmento para permitir devolver múltiples componentes desde el renderizado
Agregar a todas las respuestas anteriores hay una ventaja más: legibilidad del código , Fragmentel componente admite una forma sintáctica de azúcar <>. Por tanto, el código de su pregunta se puede escribir más fácilmente como:
render() {
return (
<>
Some text.
<h2>A heading</h2>
More text.
<h2>Another heading</h2>
Even more text.
</>
);
}
Según los documentos ,
En React, esto se desazucará a un
<React.Fragment/>elemento, como en el ejemplo de la sección anterior. (Los marcos que no son React y que usan JSX pueden compilarse en algo diferente).
Sin desorden, ¿verdad?
Tenga en cuenta que aún necesita usar <Fragment>la sintaxis si necesita proporcionarla keyal fragmento.
- Funciones añadidas que antes no eran posibles con JSX
- Mejor marcado semántico jsx. Los elementos envolventes se utilizan cuando son necesarios, no porque estén obligados a hacerlo.
- Menos marcado dom general (mayor rendimiento de renderizado y menos sobrecarga de memoria)
Es tan simple como cuando no necesitas un elemento contenedor, no estás obligado a usar uno. Tener menos elementos es genial, pero creo que el mayor beneficio es poder representar elementos en jsx que antes no eran posibles y agregar un mejor significado semántico a los elementos envolventes porque ahora son opcionales.
Esto no era posible antes:
<select>
{this.renderOptions()}
</select>
Al mirar lo siguiente en React 15, no se puede saber si el elemento contenedor es necesario o no:
<span>
<h1>Hello</h1>
{this.getContent()}
</span>
Según los documentos de reactjs.org , las necesidades más importantes de <Fragment> </Fragment>en lugar de div son evitar romper la semántica de HTML. Cuando usamos div en lugar de, <Fragment> </Fragment>rompemos la semántica HTML.
Para saber más sobre la semántica HTML. haga clic y también hay casos en los que si usa div en lugar de Fragmentos, será html no válido, por ejemplo, mire este código:
class Columns extends React.Component {
render() {
return (
<div>
<td>Hello</td>
<td>World</td>
</div>
);
}
}
<table>
<tr>
<div>
<td>Hello</td>
<td>World</td>
</div>
</tr>
</table>
Los fragmentos resuelven este problema.
