Inicio / Artículos / La velocidad de React comienza con la organización del árbol de componentes.

react performance architecture state frontend rendering

La velocidad de React comienza con la organización del árbol de componentes.

Las re-renderizaciones no son el enemigo: lo es la propagación amplia del estado. Mueva las fuentes hacia los nodos periféricos antes de realizar memorización a nivel micro.

1699 palabras

React hace lo que exige el diseño en forma de árbol. Cuando una aplicación parece lenta, suele ser porque el framework sigue un camino amplio de propagación del estado/actualización, y no porque haya algún fallo misterioso.

El volver a renderizar no es el enemigo

Los renders son lo que mantiene consistente la interfaz de usuario. El verdadero enemigo es el trabajo innecesario que se realiza en grandes subárboles con cada tecla pulsada.

// ❌ count lives in Parent — expensive siblings re-render on every click
function Parent() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <button onClick={() => setCount(c => c + 1)}>Count: {count}</button>
      <ExpensiveComponent />
      <AnotherExpensiveComponent />
    </div>
  );
}

// ✅ count lives in Counter — expensive siblings are untouched
function Counter() {
  const [count, setCount] = useState(0);
  return (
    <button onClick={() => setCount(c => c + 1)}>
      Count: {count}
    </button>
  );
}

function Parent() {
  return (
    <div>
      <Counter />
      <ExpensiveComponent />
      <AnotherExpensiveComponent />
    </div>
  );
}

// ❌ SearchLayout owns state — ExpensiveList re-renders on every keystroke
function SearchLayout() {
  const [query, setQuery] = useState('');

  return (
    <div>
      <input value={query} onChange={e => setQuery(e.target.value)} />
      <ExpensiveList />
    </div>
  );
}

/* ✅ StatefulInput receives expensive content as children
 — its reference stays stable */
function StatefulInput({ children }) {
  const [query, setQuery] = useState('');
  return (
    <div>
      <input value={query} onChange={e => setQuery(e.target.value)} />
      {children}
    </div>
  );
}

function SearchLayout() {
  return (
    <StatefulInput>
      <ExpensiveList />
    </StatefulInput>
  );
}

Dónde debe detenerse la propagación

Mover el origen del estado

Coloca el estado junto a los componentes que lo escriben y lo leen. El texto preliminar de un formulario no necesita estar en la raíz de la aplicación.

Obstruir el camino

Los hijos que reciben propiedades estables pueden evitar este problema. La composición y el uso de hijos como slots suelen ser mejores que la memorización generalizada.

El árbol como decisión de diseño

La organización es una elección arquitectónica: las carpetas de funcionalidades, la división entre contenedores y elementos de presentación, y los proveedores locales limitan el alcance de las actualizaciones.

Partiendo del árbol

Antes de recurrir a microoptimizaciones, determine qué estado debe ubicarse dónde y qué subárboles deben permanecer estables durante actualizaciones frecuentes. La mayoría de los problemas relacionados con la lentitud de React se deben a problemas en el árbol estructural.

Haga un perfil primero, luego reorganice; guarde en memoria los resultados al final.

Los proveedores de contexto forman parte del árbol: un megacontexto que cambia en cada renderizado anula los efectos de la memorización de nodos. Divida los contextos según la frecuencia de actualizaciones.

La división del código a nivel de ruta reduce el tamaño del árbol que se procesa al pintar la pantalla por primera vez; combínelo con el estado local para mantener las navegaciones ligeras.

La virtualización de listas es como una cirugía en el árbol: desmonte las filas que están fuera de la pantalla en lugar de tratar de sincronizar miles de nodos inactivos.

Propiedad de los documentos: qué equipo es responsable del estado de cada subárbol. Los almacenes globales compartidos reproducen el problema de propagación generalizada bajo otro nombre.