¿Qué cambia en tu enfoque cuando el dato vive en servidor y no en el cliente?

¿Qué cambia en tu enfoque cuando el dato vive en servidor y no en el cliente? en React: criterios sobre asincronía y estado del servidor, errores comunes y r...

3 min de lecturaIntermedio
Media AsincroníaEstado del servidorCaché

"¿Qué cambia en tu enfoque cuando el dato vive en servidor y no en el cliente?" toca un punto muy concreto de React: cómo tomar decisiones de asincronía sin esconder el problema bajo una abstracción vistosa.

La respuesta mejora cuando explicas qué parte del problema resuelves ahora con asincronía en React para "Qué cambia en tu enfoque cuando el dato vive en servidor y no en el cliente", qué dejas derivado en estado del servidor y cómo detectarías pronto que la solución empieza a quedarse corta.

Qué evalúa el entrevistador

  • Si distingues qué parte de "Qué cambia en tu enfoque cuando el dato vive en servidor y no en el cliente" pertenece a asincronía y cuál debería resolverse en estado del servidor.
  • Si conviertes la respuesta en criterios observables: límites claros, impacto en el mantenimiento y forma de detectar regresiones.
  • Si identificas la fuente de verdad, el estado derivado y los puntos donde podría aparecer sincronización manual o duplicada.

Respuesta sólida

  • Nombra primero la fuente de verdad y deja claro qué datos deberían derivarse en vez de almacenarse dos veces.
  • Explica dónde viviría cada pieza de estado: local si solo afecta a una interacción, compartido si cruza componentes y remoto si depende del servidor.
  • Añade cómo evitarías sincronizaciones manuales, renders accidentales y errores por datos obsoletos.

Compromisos y errores comunes

  • Duplicar estado entre store, formularios, URL o caché acaba generando inconsistencias que son difíciles de reproducir.
  • Mover demasiado pronto una preocupación al estado global hace visible el problema, pero no lo arregla.

Ejemplo de código

Este fragmento sirve para bajar "Qué cambia en tu enfoque cuando el dato vive en servidor y no en el cliente" a código ejecutable y mostrar qué decisiones conviene hacer explícitas cuando asincronía empieza a cruzarse con estado del servidor.

import { memo, useMemo, useState } from 'react';

const ProductList = memo(function ProductList({ products }: { products: string[] }) {
  return <ul>{products.map((product) => <li key={product}>{product}</li>)}</ul>;
});

export function SearchPanel({ products }: { products: string[] }) {
  const [query, setQuery] = useState('');
  const visibleProducts = useMemo(
    () => products.filter((product) => product.toLowerCase().includes(query.toLowerCase())),
    [products, query],
  );

  return (
    <>
      <input value={query} onChange={(event) => setQuery(event.target.value)} />
      <ProductList products={visibleProducts} />
    </>
  );
}

Fíjate en que el ejemplo deja claras las fronteras de "Qué cambia en tu enfoque cuando el dato vive en servidor y no en el cliente", nombra los estados relevantes y evita trabajo implícito que luego cuesta depurar.

Ejemplo o caso real

Un caso creíble para "¿Qué cambia en tu enfoque cuando el dato vive en servidor y no en el cliente?" aparece cuando una funcionalidad de React mezcla asincronía con estado del servidor y el equipo empieza a tocar demasiados puntos para un cambio pequeño. Ahí conviene probar la solución sobre una pantalla o flujo acotado, medir si reduce fricción y solo después extender el patrón.

Frase corta de entrevista

Primero aclaro qué problema resuelvo con asincronía y luego elijo la técnica; no al revés.

¿Completaste esta sección?

Marcarla como leída actualiza tu progreso.