SPA parametrica sul pericolo, selettore invisibile con un solo hazard (Fase 1e di #57) - #94
Merged
Conversation
…#57) La SPA smette di dare per scontato che il rischio mostrato sia quello delle frane. Un contesto `HazardProvider` risolve il pericolo da `/api/hazards` — la lista dei pericoli che *questo* deployment sa davvero valutare — e ogni componente che interroga il backend gli passa il parametro. Il selettore **non rende nulla con meno di due pericoli disponibili**: in Fase 1 il deployment ne valuta uno solo, e un controllo con una scelta sola sarebbe rumore. La Fase 1 resta invisibile all'utente. Tre pannelli non possono seguire il selettore, perché leggono viste SQL fissate sul pericolo di default (migrazione 028: una sorgente di tile deve dare una geometria per cella; `mv_comune_risk` classifica per esposizione con una chiave che solo il breakdown delle frane ha). Invece di restare fermi facendo credere di aver cambiato, mostrano `LandslideOnlyBadge`. La superficie multi-pericolo di quelle viste è #58. La legenda prende i cutoff da `/api/legend?hazard=...` invece che dalle costanti statiche: le soglie sono per pericolo da #84, e quelle in `RISK_CLASSES` etichetterebbero male i colori di un altro pericolo (oltre a essere costanti di scoring nel codice, contro l'invariante di progetto). Restano solo come ripiego a backend irraggiungibile. Otto difetti trovati in revisione, tutti la stessa radice: un effetto che guadagna `hazard` fra le dipendenze senza azzerare lo stato che possiede lascia in pagina i dati del pericolo precedente durante la nuova fetch. La cache di `CellTrendSparkline` è ora indicizzata per `${cellId}|${hazard}`. Refs #57, #87
This was referenced Sep 5, 2026
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Chiude #87. Ultima delle sei sotto-issue di #57.
Cosa cambia
HazardProviderrisolve il pericolo daGET /api/hazards— la lista di ciòche questo deployment sa davvero valutare (motore registrato + soglie) —
e ogni componente che interroga il backend passa il parametro.
Il selettore non rende nulla con meno di due pericoli disponibili. È il
requisito che tiene la Fase 1 invisibile all'utente: oggi il deployment ne
valuta uno solo.
I tre pannelli che non possono seguire il selettore
Mappa, rollup comunale e quadro nazionale leggono viste SQL fissate sul
pericolo di default (migrazione 028: una sorgente di tile deve dare una
geometria per cella;
mv_comune_riskclassifica per esposizione con unachiave che solo il breakdown delle frane ha). Restare fermi in silenzio
sarebbe peggio che non cambiare: sembrerebbero numeri del pericolo scelto.
Mostrano
LandslideOnlyBadge, invisibile finché il pericolo scelto è quellosu cui la vista è fissata. La superficie multi-pericolo di quelle viste è #58.
Legenda dal backend
I cutoff arrivano da
/api/legend?hazard=...invece che daRISK_CLASSES:le soglie sono per pericolo da #84, e quelle statiche etichetterebbero male
i colori di un altro pericolo — oltre a essere costanti di scoring nel
codice, contro l'invariante di progetto. Restano solo come ripiego a backend
irraggiungibile.
Revisione
Otto difetti, una sola radice: un effetto che guadagna
hazardfra ledipendenze senza azzerare lo stato che possiede lascia in pagina i dati del
pericolo precedente durante la nuova fetch (
RegionAccordion,ForecastList,LegendPanel, l'analisi regionale). La cache diCellTrendSparklineè oraindicizzata per
${cellId}|${hazard}— prima due pericoli sulla stessa cellasi sovrascrivevano. Rimosso un flag
readycalcolato e mai consumato.Gate
tsc -b, ESLint,npm run build: pulitiruff check+ruff format --check,mypy --strict: pulitipytest tests/unit: 624 passatiRefs #57