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.
This commit is contained in:
parent
56f53e2c23
commit
82d0399c86
5 changed files with 343 additions and 7 deletions
|
|
@ -1,7 +1,7 @@
|
|||
{
|
||||
"gmaps": {
|
||||
"key": "",
|
||||
"serverKey": ""
|
||||
"key": "AIzaSyFAKE-KEY-FOR-LOCAL-REPRO-0000000",
|
||||
"serverKey": "AIzaSyFAKE-KEY-FOR-LOCAL-REPRO-0000000"
|
||||
},
|
||||
"piwik": {
|
||||
"url": "http://localhost:9/piwik.php",
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue