Causa raíz, encontrada reproduciéndolo con el bundle de producción en local
—con el servidor de desarrollo NO se ve, y por eso llevaba semanas dándose por
un artefacto del navegador sin pantalla:
if ((centerStored !== [0, 0] || geolocation.get()) && geoInit) {
center.set(centerStored || geolocation.get());
geoInit = false;
}
`centerStored !== [0, 0]` compara contra un array recién creado: es SIEMPRE
cierto. En un navegador nuevo —sin centro en localStorage y con la
geolocalización todavía sin resolver— eso hacía `center.set(undefined)` y dejaba
`geoInit` en false, o sea para siempre. Un `<MapContainer>` sin `center` no
recibe `setView`, y un mapa de Leaflet sin vista no carga capa base ni teselas
ni dispara `whenReady`, con lo que tampoco se creaba la suscripción por
viewport. En desarrollo no pasaba porque la geolocalización llegaba a tiempo.
Y de paso el "Actualizando…" que no se quitaba nunca: las suscripciones se
creaban dentro de un `Tracker.autorun` ANIDADO en el withTracker. La computación
de fuera no dependía de `mapSize`, así que `loading` se calculaba con
`subscription` a undefined y no volvía a recalcularse; además cada pasada del
withTracker dejaba otro autorun sin parar. Ahora las suscripciones se crean en
la propia computación reactiva, que es donde Meteor sabe pararlas al invalidarse.
MapReady, además, vigila el contenedor con un ResizeObserver: su comprobación de
tamaño solo podía reintentar con el evento `resize` de Leaflet, que no se emite
si nadie llama a invalidateSize(). No era la causa de esto, pero hacía que la
comprobación no sirviera de nada.
La suite e2e deja de usar selectores por id: TestUtils.testId() los devuelve solo
en desarrollo, así que contra el bundle de producción —lo que levanta el job
nocturno— no existían y la suite entera habría fallado esta noche.
Verificado contra bundle de producción: /fires pasa de 0 teselas y 0 capas a 12
teselas, capa base y las dos suscripciones por viewport, sin "Actualizando…".
90 tests de servidor, 16 e2e y smoke REST byte-idéntico.
/zones y /fires usan el mismo componente con las mismas props y en staging uno
pinta 18 teselas y el otro cero, con el mapa inicializado y con vista en ambos.
Hay que mirar cómo FiresMap monta los hijos del MapContainer, no el componente
de capas. Y el detalle de fuego pide `satellite`, una capa de Google que ni
existe hasta que se resuelve la clave.
Además el script de QA deja de usar selectores por id: TestUtils.testId()
devuelve el id SOLO en desarrollo, así que en staging y producción no existen —
cualquier prueba de navegador escrita con ids pasa en local y falla en staging.
Desplegado en staging, el "montar el control de capas una sola vez" resultó
peor que el bug que arreglaba: /fires seguía en gris Y además la portada y
/zones —que sí pintaban— se quedaron también sin teselas. Con la clave real, el
control acaba montándose después de que el mapa ya esté montado, y entonces no
se le añade ninguna capa base. O sea que la carrera no se arregla retrasando el
montaje: solo cambia de sitio.
Staging revertido a la imagen anterior y comprobado que vuelve a estar como
estaba (portada 36 teselas, /zones 18, /fires 0).
Se conserva todo lo aprendido, que es lo que vale: el bug se reproduce en local
poniendo una clave de Google en settings-ci.json (15 teselas sin clave, 0 con
ella), NO es cosa del navegador sin pantalla, y e2e/tests/fires-map.spec.js lo
deja como test.fixme para que aparezca en cada ejecución. El arreglo bueno pasa
por decidir el conjunto de capas base ANTES de montar el mapa.
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.
