El selector que devuelve un objeto nuevo: el bug más común

Hay un error de rendimiento que aparece en prácticamente todas las bases de código con estado global, que ningún test detecta, que ninguna herramienta de tipos previene y que nadie nota hasta que la aplicación crece lo suficiente para que se note todo. Consiste en escribir un selector que construye algo: un objeto con dos campos, un array filtrado, una tupla de valores. El código es correcto, legible y devuelve exactamente lo que promete. Su único defecto es que devuelve un objeto distinto cada vez que se ejecuta, y como el filtro que decide si un componente renderiza es una comparación de identidad, ese componente pasa a renderizar en cada despacho de la aplicación entera, incluso en los que no rozan sus datos. El bug no rompe nada: simplemente cancela la amortiguación y devuelve al componente al mundo del broadcast puro.

Anatomía de una referencia nueva

El mecanismo es tan simple que resulta fácil pasarlo por alto. Cada vez que un literal de objeto o de array se evalúa, JavaScript asigna un objeto nuevo, con una identidad nueva, aunque su contenido sea idéntico al anterior. Un selector es una función que se ejecuta tras cada despacho; por tanto, un selector que contenga un literal, un map, un filter, un slice, un Object.values o un sort produce por construcción una identidad distinta en cada ejecución. El filtro posterior compara identidades y siempre concluye que algo cambió.

// Las cuatro formas cotidianas del mismo error.
useSelector((s: RootState) => ({ nombre: s.u.nombre, rol: s.u.rol }))     // literal de objeto
useSelector((s: RootState) => s.tareas.lista.filter((t) => !t.hecha))     // array derivado
useSelector((s: RootState) => [s.a.total, s.b.total])                     // tupla
useSelector((s: RootState) => Object.values(s.entidades))                 // proyeccion

// La version inofensiva: la identidad del valor coincide con su contenido.
useSelector((s: RootState) => s.u.nombre)

Merece la pena detenerse en un matiz que confunde a mucha gente: el problema no es que el selector devuelva un objeto, sino que lo construya. Devolver estado.usuario es devolver un objeto y es perfectamente estable, porque esa referencia solo cambia cuando el reducer la reemplaza. Lo que rompe la estabilidad es fabricar la estructura dentro del selector, porque entonces su identidad ya no la gobierna el reducer sino el momento de la llamada.

El error tiene además una versión gemela fuera de los selectores que conviene reconocer, porque es el mismo fenómeno con otro disfraz: el valor de contexto construido en el render del proveedor, o el objeto de propiedades fabricado al vuelo que se pasa a un hijo memoizado. En los tres casos el patrón es idéntico —una estructura recién creada cruzando una frontera que compara por identidad— y las soluciones son análogas. Quien entiende el problema en un selector lo reconoce ya en cualquier sitio.

La consecuencia práctica se enuncia mejor en términos de causa, siguiendo el vocabulario de la lección anterior. Un selector estable declara un contrato estrecho: renderízame cuando cambie esto. Un selector que construye declara el contrato más ancho posible: renderízame cuando ocurra cualquier cosa. Da igual que el dato que produce sea siempre el mismo; lo que el sistema observa es que la respuesta nunca coincide con la anterior.

flowchart TD
A[cualquier despacho de la app] --> B[se ejecuta el selector]
B --> C[construye objeto o array nuevo]
C --> D[comparar con el resultado anterior]
D --> E[nunca identico]
E --> F[render garantizado]
F --> G[hijos reconciliados y efectos disparados]
style E fill:#f38ba8,color:#11111b
style F fill:#f38ba8,color:#11111b

Las tres soluciones y cuándo usar cada una

Las tres respuestas canónicas no son intercambiables: cada una ataca el problema en un punto distinto de la cadena y tiene un coste distinto. Descomponer elimina la construcción; comparar superficialmente tolera la construcción pero neutraliza su efecto; memoizar conserva la construcción pero le devuelve una identidad estable. El orden en que las he enumerado es también el orden en que conviene intentarlas.

El criterio de elección es más nítido de lo que parece si te preguntas qué relación hay entre el resultado y el estado. Si el resultado es un reagrupamiento de valores que ya existen tal cual en el store, el problema es de envoltorio y se resuelve descomponiendo o comparando por claves. Si el resultado es un valor que no existe en el store hasta que tu selector lo calcula, el problema es de derivación y solo la memoización lo resuelve, porque ni siquiera una comparación superficial acierta cuando los elementos internos también son nuevos.

// Envoltorio: descompon.
const nombre = useSelector((s: RootState) => s.u.nombre)
const rol = useSelector((s: RootState) => s.u.rol)

// Envoltorio inevitable: compara por claves.
const datos = useSelector((s: RootState) => ({ n: s.u.nombre, r: s.u.rol }), shallowEqual)

// Derivacion: memoiza. Ninguna comparacion barata salva esto.
const selectPendientes = createSelector(
  [(s: RootState) => s.tareas.lista],
  (lista) => lista.filter((t) => !t.hecha),
)
const pendientes = useSelector(selectPendientes)

Hay una trampa clásica en el punto medio entre las dos familias que conviene señalar. Una derivación que devuelve un array de objetos existentes —filtrar una lista sin transformar sus elementos— sí puede rescatarse con una comparación superficial, porque el contenedor es nuevo pero los elementos son las mismas referencias de antes. En cambio, una derivación que además proyecta o transforma cada elemento crea objetos internos nuevos y falla incluso la comparación superficial. Distinguir filtrar de transformar decide, en ese punto, si la solución dos basta o hace falta la tres.

// Filtrar conserva las referencias internas: shallowEqual salva el caso.
const abiertas = useSelector(
  (s: RootState) => s.tareas.lista.filter((t) => !t.hecha),
  shallowEqual,
)

// Transformar crea objetos nuevos: shallowEqual falla en el primer elemento.
const resumen = useSelector(
  (s: RootState) => s.tareas.lista.map((t) => ({ id: t.id, txt: t.titulo })),
  shallowEqual, // inutil aqui: hace falta memoizar
)

Repara además en un coste que la segunda solución arrastra incluso cuando funciona: la comparación superficial de un array recorre todos sus elementos en cada despacho de la aplicación. Para una lista de diez elementos es irrelevante; para una de cinco mil, has cambiado un render inútil por un recorrido de cinco mil comparaciones que se ejecuta constantemente y casi siempre concluye que nada cambió. A partir de cierto tamaño, memoizar no es una alternativa más elegante sino la única que escala.

Los avisos que lo hacen visible

Lo que convierte a este bug en el más común no es su dificultad conceptual, que es nula, sino su invisibilidad: el resultado en pantalla es correcto y la degradación es gradual. Por eso la aportación más útil de las versiones recientes no fue una optimización sino un par de chequeos que se ejecutan solo en desarrollo y hablan en voz alta.

El chequeo de estabilidad ejecuta tu selector dos veces con el mismo estado en la primera llamada y compara ambos resultados. Si difieren, el selector es inestable por construcción y lo dice con nombre y apellidos. El chequeo de identidad detecta el caso contrario y también inútil: un selector cuya función de resultado devuelve su propia entrada, señal de una memoización que no memoiza nada. Ambos existen tanto en useSelector de react-redux como en los selectores de reselect, y ambos se pueden ajustar por hook o globalmente.

// Ajuste por hook: forzar el chequeo siempre, no solo en la primera llamada.
const datos = useSelector(selectAlgo, { devModeChecks: { stabilityCheck: 'always' } })

// Ajuste global al crear el store.
const store = configureStore({
  reducer,
  // los chequeos de selectores viven en el contexto de desarrollo y no
  // afectan al build de produccion, donde se eliminan por completo
})

Hay un tercer nivel de defensa que casi nadie monta y que resulta desproporcionadamente eficaz: hacer que el error no llegue a escribirse. Una regla de análisis estático que prohíba literales de objeto y llamadas a map, filter o sort dentro del argumento de useSelector convierte una clase entera de fallos de rendimiento en un error de compilación. Es la misma jugada que se hace con las dependencias de los hooks, y funciona por la misma razón: el problema es sintácticamente reconocible aunque sea semánticamente sutil.

Merece la pena entender por qué la revisión de código humana falla aquí de forma tan sistemática. El selector culpable no se ve mal: expresa con claridad lo que quiere, no tiene complejidad, no introduce estado y devuelve lo correcto. Un revisor que busque errores de lógica pasará por encima veinte veces, porque el defecto no está en lo que la función calcula sino en la identidad del valor que produce, una propiedad que el código no exhibe en su superficie. Las herramientas ganan a la atención en exactamente esta clase de errores.

Una advertencia de método para cerrar: estos avisos corren solo en desarrollo, y en desarrollo StrictMode duplica ejecuciones y el código no está optimizado. Eso significa que sirven para detectar la clase del error, no para medir su magnitud. Confirmar que un selector es inestable es trabajo de consola; decidir si esa inestabilidad justifica introducir una caché es trabajo de medición, y ese es exactamente el asunto de la última lección de este nivel.