/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.
