Un hijo con `OnPush` no repinta cuando cambia el padre: ¿cómo lo depurarías paso a paso?

Esta pregunta de Angular sobre "Un hijo con OnPush no repinta cuando cambia el padre: ¿cómo lo depurarías paso a paso" deja ver rápido si conviertes escenarios reales en decisiones operativas o si te quedas en teoría.

En una entrevista fuerte gana peso la persona que habla de costes, señales de degradación, deuda aceptada y plan de validación para "Un hijo con OnPush no repinta cuando cambia el padre: ¿cómo lo depurarías paso a paso", no solo de API o sintaxis.

Qué evalúa el entrevistador

• Si distingues qué parte de "Un hijo con OnPush no repinta cuando cambia el padre: ¿cómo lo depurarías paso a paso" pertenece a escenarios reales y cuál debería resolverse en detección de cambios.
• Si conviertes la respuesta en criterios observables: límites claros, impacto en el mantenimiento y forma de detectar regresiones.
• Si entiendes qué dispara trabajo real de render o hidratación y cuándo merece la pena optimizar frente a cuándo solo estás moviendo complejidad.

Respuesta sólida

• Explica qué unidad quieres volver a pintar, conservar o diferir y por qué esa decisión mejora la experiencia sin complicar el árbol.
• Relaciona la solución con claves, memoización, detección de cambios, hidratación o virtualización solo si el cuello de botella está realmente ahí.
• Si propones optimización, acompáñala de una forma de medirla con herramientas o métricas visibles.

Compromisos y errores comunes

• Optimizar sin perfilar antes suele desplazar la complejidad hacia el componente sin tocar el verdadero cuello de botella.
• Forzar memoización, cachés o control fino del render donde no hace falta complica la depuración y suele envejecer mal.

Ejemplo de código

No se trata de memorizar esta implementación, sino de enseñar cómo ordenar el flujo de escenarios reales en Angular sin mezclar responsabilidades ni perder de vista detección de cambios.

import { ChangeDetectionStrategy, Component, computed, signal } from '@angular/core';

@Component({
  selector: 'app-product-filter',
  standalone: true,
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `
    <input [value]="query()" (input)="query.set(($any($event.target)).value)" />
    <ul>
      @for (product of filteredProducts(); track product.id) {
        <li>{{ product.name }}</li>
      }
    </ul>
  `,
})
export class ProductFilterComponent {
  readonly query = signal('');
  readonly products = signal([{ id: 1, name: 'Angular' }, { id: 2, name: 'RxJS' }]);
  readonly filteredProducts = computed(() =>
    this.products().filter((product) =>
      product.name.toLowerCase().includes(this.query().trim().toLowerCase()),
    ),
  );
}

En entrevista yo usaría un ejemplo de este tamaño para "Un hijo con OnPush no repinta cuando cambia el padre: ¿cómo lo depurarías paso a paso": suficiente para demostrar criterio y lo bastante pequeño como para discutir riesgos y variantes sin perderse.

Ejemplo o caso real

Un caso creíble para "Un hijo con OnPush no repinta cuando cambia el padre: ¿cómo lo depurarías paso a paso?" aparece cuando una funcionalidad de Angular mezcla escenarios reales con detección de cambios 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

Prefiero una solución comprobable y reversible a una respuesta brillante que nadie sepa mantener dentro de seis meses.