todos-contra-el-fuego-web/imports
vjrj 82d0399c86
All checks were successful
build-image / test (push) Successful in 3m15s
build-image / build (push) Successful in 13m51s
fix(maps): el mapa de /fires se quedaba en gris cuando hay clave de Google
Síntoma: en staging /fires no pintaba teselas ni fuegos, no creaba la
suscripción `activefiresmyloc` y se quedaba con "Actualizando…" para siempre. Se
había atribuido a que el navegador de las pruebas no compone; no era eso. El
mismo navegador pinta la portada, y pinta /fires perfectamente contra un
servidor local.

La diferencia era la clave de Google. `DefMapLayers` montaba el control de capas
con dos capas base (OSM color y gris) y, cuando `Gkeys` resolvía la clave,
volvía a renderizar añadiendo tres capas de Google. En esa segunda pasada
react-leaflet se dejaba por el camino la capa base marcada, y el mapa se quedaba
sin ninguna. En desarrollo no hay clave, así que la segunda pasada no añadía
nada y el bug no se veía nunca.

El control se monta ahora una sola vez, con la lista de capas ya cerrada, y con
un tope de 5 s por si el script de Google no llega: las capas de Google son un
extra, el mapa tiene que salir igual.

Reproducido en local poniendo una clave falsa en settings-ci.json (0 teselas
antes del arreglo, 15 después). Esa clave falsa se queda ahí a propósito, para
que la suite e2e recorra el mismo camino que staging y producción, y
e2e/tests/fires-map.spec.js lo fija: teselas, una única capa base marcada,
suscripción por viewport, y que no se quede en "Actualizando…".

16 tests e2e en verde.
2026-08-01 23:17:50 +02:00
..
api fix(users): use updateAsync for Meteor 3 server-side user writes 2026-07-30 10:13:21 +02:00
modules quality: web debt batch (tests runner, FireContainer, rate-limit, maps, i18n) 2026-07-21 22:59:06 +02:00
startup perf(subsUnion): unión en árbol, menos vértices, timeout y cota de memoria 2026-08-01 22:32:37 +02:00
ui fix(maps): el mapa de /fires se quedaba en gris cuando hay clave de Google 2026-08-01 23:17:50 +02:00