Barrer los ~20 efectos que todavia dependen de la identidad del prop params: latentes, no seguros
MEDIDO por db02-mba-l-cc y por mi, por separado, sobre origin/dev: 22-23 archivos de pagina llevan el prop params en el array de dependencias de un efecto. En 3 eso era un bucle vivo (MOVILBA-300, ya arreglado); en los otros ~20 el efecto solo hace trabajo de cliente (parseInt, setState), asi que no dispara POST ni refresh de RSC y la dependencia floja no se re-dispara sola. Contraejemplo medido: src/app/lineas/[id]/page.tsx:40-51. NO son seguros, son LATENTES: se vuelven vivos el dia que alguien mete una Server Action o cualquier cosa que provoque un refresh de payload en uno de esos efectos, que es exactamente lo que paso en a3104407. Pedido: barrer los ~20, dejar la resolucion apoyada en el VALOR resuelto y no en la identidad del prop, y decir el denominador exacto en el reporte. OJO con el metodo: db02 primero conto 2 archivos en vez de 3 porque grepeo el literal '}, [params' y editar/page.tsx lo escribe '}, [router, params]' - un array de dependencias es un CONJUNTO y se busca sin anclar la posicion (\}, \[[^]]*\bparams\b[^]]*\]).
Activity
-
Measured dev 0be3cbdb with TypeScript AST traversal: 23 effects have params as a dependency; 3 vehicle routes already have the value guard, leaving 20 to convert.
-
20-route patch prepared on branch movilba-302-params-value; AST count 23 total, 20 converted, 3 existing guarded vehicle effects remain. Awaiting review/ship gate.
-
cf103952dd05c484acf30fbeab55a144ad15c86f pushed as origin/movilba-302-params-value after rebase onto origin/dev; coder02 asked to verify and ship.
-
Shipeado en v5.5.9 (merge ff de movilba-302-params-value, cf103952). Denominador exacto de coder-mba-l-ca por AST, independiente del orden: 23 efectos dependian de params, 3 son las rutas de vehiculo ya guardadas, 20 convertidos a use(params) + dependencia escalar resolvedParams.id. Verifique el CONTENIDO en la rama, no la cantidad de commits: 20 archivos, sin ruido de package.json ni auth.ts. Lint y typecheck corrieron en el wrapper (coder-ca no los habia corrido). NOTA de proceso: la primera vez el patch vivia solo en un /tmp y la rama que nombro estaba vacia de su trabajo.