Glosario

54 términos que no se traducen

Acá los términos técnicos van en inglés: se escribe Fiber, no fibra; commit, no confirmación. Traducirlos rompe la búsqueda, corta la continuidad con la documentación oficial y te obliga a aprender cada cosa dos veces. Lo que va en español es la explicación.

En las lecciones, cualquier término subrayado con puntos muestra su definición al pasarle el mouse o al enfocarlo con el teclado.

54 términos

ActionServidortambién: Actions, Server Action: Pasándole una función a la prop action de un form, React se encarga del estado pendiente, del resultado y del error. useActionState devuelve el estado y la acción envuelta; useFormStatus lee el estado del form más cercano hacia arriba, desde un hijo.
se explica a fondo acá →ver también:Server Component
alternateEl motor: Cada Fiber apunta con alternate a su gemelo del árbol opuesto. React mantiene dos árboles — current (lo que se ve) y workInProgress (lo que se construye) — y los recicla alternándolos en vez de asignar objetos nuevos en cada render.
se explica a fondo acá →ver también:double buffering workInProgress
bailoutEl motor: Para hacer bailout tienen que darse tres condiciones: existe un Fiber current, las props son las mismas por identidad (o superficialmente iguales si hay memo) y el Fiber no tiene lanes pendientes. Si se cumplen, React clona los hijos y ni ejecuta la función. El bailout se propaga hacia abajo.
se explica a fondo acá →ver también:memo lane
baseStateEl motor: Cuando React saltea un update de baja prioridad, congela baseState en el valor previo a ese update y guarda el resto de la cola. En la pasada siguiente reaplica todo desde ahí, incluso los updates de alta prioridad que ya se habían aplicado. Así el resultado final depende del orden en que llamaste a los setters, no de cómo React repartió el trabajo.
se explica a fondo acá →ver también:lane update queue
batchingHookstambién: batching automático: React abre un lote y todo lo que se encole adentro se procesa junto. Hasta React 17 el lote existía sólo dentro de manejadores de eventos: un setState en un setTimeout o una promesa disparaba su propio render. Desde React 18, createRoot agrupa en cualquier contexto.
se explica a fondo acá →ver también:update queue lane
beginWorkEl motor: beginWork se llama al bajar por cada Fiber. Chequea si puede hacer bailout; si no, ejecuta la función del componente y reconcilia sus hijos. Devuelve el próximo Fiber a procesar o null si llegó a una hoja.
se explica a fondo acá →ver también:completeWork bailout
cleanupHooks: React guarda la función que devolvés como destroy y la llama antes de ejecutar el efecto siguiente y al desmontar el componente. El orden es siempre cleanup y después create: eso es lo que hace que un efecto sea idempotente y sobreviva al doble montaje de StrictMode.
se explica a fondo acá →ver también:useEffect StrictMode
commitEl motortambién: commit phase, fase commit: El commit tiene tres etapas: mutación (aplica lo que la fase render marcó con flags), intercambio de árboles (root.current = finishedWork) y layout effects. Corre entera de un saque, porque una interfaz a medio actualizar sería peor que una vieja. El navegador pinta después.
se explica a fondo acá →ver también:render phase flags
completeWorkEl motor: Cuando una rama termina, React sube llamando a completeWork en cada Fiber. Ahí se crean o actualizan las instancias host y se enganchan los hijos ya listos al padre. Por eso el árbol del DOM se arma de las hojas hacia la raíz.
se explica a fondo acá →ver también:beginWork host component
dependency arrayHookstambién: array de dependencias, deps: React compara el array nuevo contra el guardado, elemento por elemento, con Object.is. Es una comparación superficial y por identidad: un objeto o una función creados en el cuerpo del componente son siempre distintos entre renders, así que ponerlos ahí equivale a no poner deps.
se explica a fondo acá →ver también:useEffect useMemo
double bufferingEl motor: React nunca tiene un solo árbol: tiene current y workInProgress. Construye en privado, y al terminar el commit hace root.current = finishedWork. Es la misma técnica de los motores gráficos: nadie ve un cuadro a medio dibujar.
se explica a fondo acá →ver también:alternate commit
eager stateHooks: Si la cola está vacía y el Fiber no tiene trabajo pendiente, React aplica el reducer al vuelo. Si el resultado es idéntico por Object.is, tira el update y ni siquiera agenda un render. Por eso setCount(count) no hace nada — y por eso mutar un objeto sin cambiar su referencia tampoco.
se explica a fondo acá →ver también:update queue bailout
elementRender y árboltambién: React element, elemento: JSX compila a llamadas que producen un objeto con $$typeof, type, key y props. Es descartable y se recrea en cada render. No sabe nada del DOM y no tiene métodos: es una descripción de cómo debería verse algo.
se explica a fondo acá →ver también:Fiber JSX
Error BoundaryRender y árboltambién: Error Boundaries: Se declaran con clases porque son los únicos componentes con getDerivedStateFromError — que corre en la fase render y sólo devuelve estado — y componentDidCatch, que corre en el commit y es donde van los efectos como reportar el error. Si no hay ninguno, React desmonta la aplicación entera a propósito.
se explica a fondo acá →ver también:unwinding Suspense
FiberEl motortambién: fibers: Un Fiber es un objeto plano que representa una instancia de un componente en el árbol. Guarda su tipo, sus props, la cadena de hooks en memoizedState, punteros a su hijo, hermano y padre, los flags de qué hacer en el commit y las lanes de trabajo pendiente. Tu estado no vive en tu función: vive acá. Se llama Fiber porque es la unidad de trabajo que el reconciler puede empezar, pausar y retomar.
se explica a fondo acá →ver también:alternate memoizedState reconciler
flagsEl motortambién: effect tags: Cada Fiber lleva un bitmask de flags: Placement (insertar), Update (cambiar props), Deletion (desmontar), Passive (tiene useEffect), Layout (tiene useLayoutEffect). El commit aplica sólo lo marcado; todo lo demás ni se toca.
se explica a fondo acá →ver también:commit
hookHookstambién: hooks: Cada hook es un objeto con memoizedState, baseState, una queue de updates y un puntero next. Se crean en orden de llamada durante el montaje y se clonan en paralelo en cada actualización. De esa estructura salen las dos reglas de los hooks.
se explica a fondo acá →ver también:memoizedState update queue
host componentRender y árbol: React distingue los componentes de función de los host components, que son los que tienen una contraparte real en el destino. Sólo estos tienen stateNode apuntando al nodo del DOM. Por eso, para encontrar el nodo de un componente, hay que bajar hasta el primer host.
ver también:Fiber completeWork
hydrationServidor: React construye el árbol de Fibers sobre nodos que ya están en el documento y les engancha los listeners. Espera que el HTML del servidor coincida exactamente con lo que renderiza el cliente; si no coincide, descarta y vuelve a renderizar del lado del cliente, que es lento y visible.
se explica a fondo acá →ver también:Server Component useId
JSXRender y árbol: JSX no es parte de JavaScript: Babel o SWC lo traducen a jsx(type, props) antes de que el navegador vea nada. En desarrollo el compilador usa jsx-dev-runtime y en producción jsx-runtime — por eso una librería que provee su propio runtime tiene que exportar los dos.
se explica a fondo acá →ver también:element
keyRender y árboltambién: keys: React recorre los hijos en paralelo mientras las keys coincidan; cuando dejan de coincidir arma un mapa por key con los que quedan. Encontrar el Fiber es conservar su estado. Usar el índice del array le dice a React que la identidad es la posición, y al reordenar el estado se queda pegado al lugar en vez de al dato.
se explica a fondo acá →ver también:reconciliation Fiber
laneEl motortambién: lanes: Las lanes son un bitmask de 31 bits donde cada bit es una prioridad. Al llamar setState, React marca la lane subiendo hasta la raíz. Después elige el conjunto de mayor prioridad y renderiza sólo eso, dejando el resto para otra pasada con su propio commit y su propio pintado.
se explica a fondo acá →ver también:baseState transition
memoRendimientotambién: React.memo: Sin memo, el bailout necesita que las props sean el MISMO objeto — cosa que casi nunca pasa, porque el padre las recrea en cada render. memo compara clave por clave con Object.is. Pero alcanza con que una prop sea una función o un objeto inline para que no sirva: es un contrato de dos partes.
se explica a fondo acá →ver también:bailout useCallback
memoizedStateHooks: En un componente de función, fiber.memoizedState apunta al primer hook de una lista enlazada. Cada hook apunta al siguiente con .next. No hay ningún array indexado por nombre: la identidad de un hook es su posición en esa cadena.
se explica a fondo acá →ver también:Fiber hook
portalRender y árbol: createPortal renderiza en otro nodo del DOM, pero el componente sigue en el mismo lugar del árbol de React. Los eventos burbujean por la jerarquía de React y el contexto se lee igual. El árbol de React y el del documento dejan de coincidir, y eso es a propósito.
se explica a fondo acá →ver también:host component
ProfilerRendimiento: Envolvés un subárbol en React.Profiler y recibís un callback por cada commit con la fase (mount o update) y cuánto tardó. Sólo funciona en builds de desarrollo o de profiling: en producción es un no-op.
ver también:commit
React CompilerRendimiento: Analiza tus componentes y agrega el equivalente a useMemo y useCallback donde hace falta, con más precisión que a mano. Sólo puede hacerlo si el código es puro y respeta las reglas de los hooks: no es magia, es análisis estático que necesita garantías.
se explica a fondo acá →ver también:useMemo memo
reconcilerEl motor: El reconciler es el corazón de React: recorre el árbol construyendo un workInProgress, compara cada nivel contra el árbol current y marca con flags lo que hay que insertar, actualizar o borrar. Es independiente del destino: el mismo reconciler alimenta react-dom, react-native y cualquier renderer.
se explica a fondo acá →ver también:reconciliation workInProgress
reconciliationEl motortambién: reconciliación: Comparar dos árboles cuesta O(n³) en el caso general. React lo baja a O(n) con dos suposiciones: dos elementos de tipo distinto producen árboles distintos, y el programador puede marcar qué hijos son «el mismo» con una key. Sólo compara el mismo nivel, nunca en profundidad.
se explica a fondo acá →ver también:key reconciler
refRender y árbol: Las refs se pueblan entre la mutación y los layout effects del commit. Por eso son null durante el render y ya están listas en useLayoutEffect. Desde React 19 ref es una prop común y forwardRef quedó obsoleto.
se explica a fondo acá →ver también:useRef commit
render phaseEl motortambién: fase render: En la fase render React baja con beginWork y sube con completeWork, ejecutando la función de cada componente que lo necesite. Nada de esto toca la pantalla y puede abandonarse a la mitad. Por eso tiene que ser pura: puede ejecutarse dos veces o descartarse.
se explica a fondo acá →ver también:commit beginWork completeWork
Server ComponentServidortambién: Server Components, RSC: Puede leer la base de datos o el sistema de archivos directamente. No tiene estado ni efectos porque no vuelve a ejecutarse. Su salida viaja serializada al cliente. La directiva use client no marca dónde se ejecuta algo: marca dónde EMPIEZA el cliente.
se explica a fondo acá →ver también:use client hydration
snapshotConcurrencia: getSnapshot se llama durante la fase render, no en un efecto. Por eso todo lo que se renderiza en esa pasada ve el mismo valor. React también lo vuelve a leer antes de commitear para detectar si cambió a mitad de camino.
se explica a fondo acá →ver también:tearing useSyncExternalStore
StrictModeRender y árbol: Llama a la función del componente dos veces y descarta un resultado, y desde React 18 monta, desmonta y vuelve a montar cada componente. No es un desperdicio: es un detector. Si tu componente se comporta distinto la segunda vez, tenés un efecto secundario donde no va o te falta un cleanup.
se explica a fondo acá →ver también:cleanup render phase
SuspenseConcurrencia: Suspender es interrumpir el render lanzando una promesa. React hace unwinding hasta el Suspense más cercano, descarta el trabajo y muestra el fallback; cuando la promesa resuelve, reintenta. Es el mismo mecanismo que los Error Boundaries con otra carga.
se explica a fondo acá →ver también:use unwinding Error Boundary
tearingConcurrencia: Con renderizado concurrente, React puede interrumpir un render a la mitad. Si un store externo cambia en ese hueco, los componentes ya renderizados muestran el valor viejo y los que faltan el nuevo. useSyncExternalStore existe exactamente para que eso no pase.
se explica a fondo acá →ver también:useSyncExternalStore snapshot
transitionConcurrencia: Marcar algo como transition no lo hace más rápido: le dice a React que puede quedarse atrás si llega algo urgente. React procesa la prioridad alta primero, commitea, deja pintar, y recién después arranca otra pasada completa para la transición.
se explica a fondo acá →ver también:lane useTransition
unwindingEl motor: Cuando algo se lanza durante el render, React sube por la cadena de punteros return buscando quién lo atrape: un Error Boundary si fue un error, un Suspense si fue una promesa. El trabajo a medio hacer de cada Fiber que atraviesa se descarta y nunca llega al commit.
se explica a fondo acá →ver también:Error Boundary Suspense
update queueHookstambién: cola de updates: setState no cambia nada: crea un objeto update y lo mete en una lista enlazada circular, donde queue.pending apunta al último y pending.next al primero. Así se inserta al final en O(1) y se recorre en orden de llegada. La cola se vacía durante la fase render.
se explica a fondo acá →ver también:batching baseState
useConcurrencia: use() no es un hook común: no guarda nada en la cadena de hooks, así que no tiene posición que se pueda desalinear. Con una promesa suspende el componente hasta que resuelva; con un contexto se comporta como useContext.
se explica a fondo acá →ver también:Suspense useContext
use clientServidor: Todo lo que se importe desde un módulo marcado con use client entra al bundle del cliente. Por eso conviene ponerla lo más abajo posible en el árbol. Todo lo que cruce ese límite como prop tiene que ser serializable: nada de funciones ni de clases.
se explica a fondo acá →ver también:Server Component
useCallbackHooks: useCallback(fn, deps) es exactamente useMemo(() => fn, deps). Sin un memo del otro lado o sin ser dependencia de un efecto, no hace absolutamente nada útil: sólo agrega un nodo a la cadena, un array que asignar y una comparación por render.
se explica a fondo acá →ver también:useMemo memo
useContextHooks: Cuando React atraviesa un Provider empuja su value en una pila del contexto, y lo saca al subir. useContext lee el tope de esa pila. Como no guarda nada en la cadena de hooks, es el único hook que técnicamente podría ir dentro de un condicional.
se explica a fondo acá →ver también:use Provider
useDeferredValueConcurrencia: Usa el mismo mecanismo que useTransition, enganchado al valor en vez de al setter. No es un debounce: no hay espera fija y si llega algo urgente pasa primero. Para que sirva, el componente que recibe el valor diferido tiene que estar memoizado.
se explica a fondo acá →ver también:useTransition transition
useEffectHooks: Llamarlo no ejecuta nada: guarda un objeto con create, destroy y deps, marca el Fiber y encola el efecto. React lo vacía después del commit y después de que el navegador pinta, en una tarea aparte. Si no hay un sistema externo del otro lado, probablemente no necesites un efecto.
se explica a fondo acá →ver también:useLayoutEffect cleanup dependency array
useIdHooks: No es un contador global: el id sale de dónde está el componente en el árbol. Por eso el servidor y el cliente generan el mismo y la hydration no se rompe. Nunca lo uses como key de una lista.
ver también:hydration
useLayoutEffectHooks: Misma firma, distinto momento: corre después de aplicar los cambios al DOM y antes de que el navegador pinte. Sirve cuando medís o ajustás layout y el resultado se ve — un tooltip que hay que reposicionar. El precio es latencia: mientras corre, el navegador no puede pintar.
se explica a fondo acá →ver también:useEffect commit
useMemoHooks: No evita renders: evita recalcular dentro de un render que va a ocurrir igual. Vale la pena si el cálculo es caro de verdad, o si el resultado se pasa a un componente memoizado y lo que importa es la identidad de la referencia.
se explica a fondo acá →ver también:useCallback memo
useReducerHooks: Por dentro es idéntico a useState. Lo que cambia es dónde vive la lógica: los componentes declaran qué pasó y el reducer decide qué significa. Eso permite hacer imposibles los estados contradictorios y probar la lógica sin renderizar nada.
se explica a fondo acá →ver también:useState
useRefHooks: Devuelve el mismo objeto { current } en todos los renders. Su queue es null, así que no hay setter, no hay lane y no hay render. Esa ausencia es exactamente su utilidad: guardar cosas que deben sobrevivir entre renders sin provocar uno.
se explica a fondo acá →ver también:ref
useStateHooks: En el código de React, updateState llama a updateReducer con basicStateReducer, que devuelve la acción o la ejecuta si es una función. De ahí sale la función actualizadora: no es una característica especial, es el reducer por defecto haciendo su trabajo.
se explica a fondo acá →ver también:useReducer update queue
useSyncExternalStoreServidor: Recibe subscribe, getSnapshot y opcionalmente getServerSnapshot. El snapshot se lee durante el render, no en un efecto: por eso todo lo que se renderiza en esa pasada ve el mismo valor. Cuidado con pasar una función subscribe inline: vuelve a suscribir en cada render.
se explica a fondo acá →ver también:tearing snapshot
useTransitionConcurrencia: Son dos hooks: un booleano y una función memoizada. setPendiente(true) entra urgente y se ve al instante; lo que dispares dentro del callback y setPendiente(false) entran por TransitionLane. Por eso isPending baja exactamente cuando la transición termina: viajan en la misma lane.
se explica a fondo acá →ver también:transition useDeferredValue lane
workInProgressEl motor: El árbol workInProgress se arma durante la fase render. Es interrumpible y descartable: si llega trabajo más urgente, React lo tira y arranca de nuevo sin que el usuario vea nada. Sólo pasa a ser visible cuando el commit lo intercambia con current.
se explica a fondo acá →ver también:render phase commit