Saltar al contenido
Framework Ecosystems LabsUn contrato, muchos ecosistemas, la misma prueba.

Por qué sí y por qué no — Efectos y ciclo de vida#

⬅️ Clase 087 · 📚 Parte 6

Por qué sí Por qué no Qué se paga
React Una sola herramienta para todo, y una lista que se puede ajustar a propósito Esa misma lista es la fuente de sus dos errores más caros Mantener a mano lo que los otros tres deducen
Vue Separa ciclo de vida de reacción: cada herramienta dice para qué es Hay que saber cuál toca, y quien viene de React busca una sola Aprender dos APIs donde antes había una
Svelte $effect deduce sus dependencias: el error de olvidar una no existe Tampoco se puede acotar a propósito sin rodeos Menos control sobre cuándo se repite
SolidJS La suscripción por lectura es la misma en el render y en el efecto: un solo modelo Leer una señal donde no querías suscribirte crea repeticiones sorpresa Vigilar dónde se lee, no dónde se declara

🧭 Lo que este contrato no puede probar#

💡 Lo que hay que llevarse#

Un efecto es una puerta al mundo de fuera: lo que no se puede calcular a partir del estado y hay que ir a buscar o registrar en alguna parte.

De ahí salen las tres reglas que aguantan en las cuatro tecnologías:

  1. Si se puede calcular, no es un efecto. Derivar un valor del estado se hace al renderizar. Guardarlo en otro estado desde un efecto duplica la verdad y añade un render.
  2. Todo lo que se abre, se cierra. Suscripción, temporizador, observador, conexión: la limpieza no es opcional, es la otra mitad del efecto.
  3. Lo que tiene que estar en el primer HTML no puede vivir en un efecto. Es la conclusión verificada de esta clase, y la que más consecuencias tiene: explica el parpadeo, explica por qué los buscadores a veces no ven el contenido, y explica la parte 7 entera.

La diferencia entre los cuatro es más pequeña de lo que parece: todos deducen las dependencias menos React, y React no lo hace por una razón defendible — poder acotar el efecto aunque lea más cosas de las que declara. Esa libertad es también su trampa, y el ecosistema entero de reglas de linter para useEffect existe por eso.

Si uno se lleva una sola frase: un efecto no es «código que corre al renderizar», es código que corre cuando el componente ya está en la pantalla — y por eso en el servidor, donde no hay pantalla, no corre nunca.

Fuentes#