# Mappa Sintomi → Ipotesi → Aree di Indagine

## Sintomo: Flicker della Summary/Footer al primo caricamento

**Osservazione reale**: La riga di summary o footer della griglia appare e scompare rapidamente (flicker) nei primi 0.5-1 secondi dal caricamento della pagina, poi si stabilizza.

**Ipotesi probabile**: 
- **Race condition di timing**: il footer viene renderizzato prima che l'altezza totale della griglia sia calcolata; quando i dati arrivano e vengono inseriti, il container si ridimensiona e il footer "salta".
- **Conflitto di display/visibility**: il footer ha un delay di mount rispetto alla griglia principale, oppure viene renderizzato in due passate (prima vuoto, poi con dati).

**Aree di indagine**:
1. Ispeziona il bounding rect del footer e del container griglia al primo frame visibile del sintomo (durante il flicker).
2. Verificare il timing di mount nel codice componente: il footer viene dichiarato prima che `isDataReady` o `isInitialized` sia true?
3. Controllare CSS: il footer ha `position: absolute` o `position: fixed` che potrebbe causare calcoli di posizione errati prima del ridimensionamento?
4. Verificare se esiste una `will-change` o una proprietà CSS che forza un reflow/repaint ritardato.
5. Controllare se il footer dipende da un calcolo dinamico di altezza (es. `height: calc(100% - gridHeight)`): se la gridHeight non è ancora disponibile, il footer riceve un valore fallback che poi viene corretto.

**Azione rapida**: 
- Aggiungi un delay di render al footer (`setTimeout(() => setShowFooter(true), 100)`) per forzarlo dopo il mount della griglia.
- Oppure fissa l'altezza del container griglia prima che il footer venga renderizzato.

---

## Sintomo: Layout glitch al primo caricamento, griglia visibilmente storta

**Osservazione reale**: Al primo load della pagina, la griglia appare con colonne disallineate, larghezza errata, o elementi che sovrastano i confini previsti. Dopo 1-2 secondi, il layout si "aggiusta" da solo.

**Ipotesi probabile**:
- **Timeout di ispezione CSS**: il componente griglia calcola le larghezze delle colonne in base a misure del DOM (ex. `offsetWidth` del parent), ma al primo render il parent non ha ancora una dimensione valida (potrebbe essere fuori dalla viewport o non completamente renderizzato).
- **Virtualizzazione non inizializzata**: le righe virtualizzate usano un'altezza di riga stimata al primo render; se la stima è sbagliata (es. 40px invece di 48px), il layout della virtualizzazione è storto finché l'altezza reale non viene calcolata.
- **Contenitore parent senza dimensione fissa**: se il parent della griglia non ha width/height esplicita, le colonne vanno in calcolo fallback.

**Aree di indagine**:
1. Usa `getBoundingClientRect()` sul parent della griglia al primo render visibile: ha width/height positiva? È dentro la viewport?
2. Controlla il CSS del parent: ha `width: auto` o `width: 100%`? Se è 100%, il 100% è rispetto a chi? (viewport, container, corpo)
3. Ispeziona l'altezza di riga della virtualizzazione nel codice del componente: è hardcoded o calcolata? Se calcolata, quando avviene il calcolo (mount? dopo primo render?)
4. Verifica se esiste una callback di `onAfterRender` o lifecycle hook analogo che ricalcola le larghezze delle colonne.
5. Controlla se il CSS include `box-sizing: border-box` su griglia e colonne; se manca, i calcoli di larghezza potrebbero essere sfalsati.

**Azione rapida**:
- Aggiungi `width: 100%; height: 100%;` esplicite al contenitore griglia nel CSS.
- Oppure fissa un'altezza di riga esplicita nella virtualizzazione: `itemSize={48}` invece di calcolo dinamico.
- Oppure aggiungi un hook di lifecycle che ricalcola le dimensioni dopo il primo render completato.

---

## Sintomo: Scrollbar della griglia esce dal limite inferiore/superiore

**Osservazione reale**: La scrollbar verticale della griglia appare spostata rispetto al bordo del container, o si estende oltre il limite inferiore della griglia (es. esce nel footer). Spesso il sintomo scompare se la finestra viene ridimensionata (trigger di reflow).

**Ipotesi probabile**:
- **Overflow hidden mancante o errato**: il container della griglia non ha `overflow: auto` o ha `overflow: visible`, permettendo alla scrollbar interna di renderizzarsi oltre i confini.
- **Calcolo di altezza container errato**: se l'altezza totale del container griglia include padding/border non conteggiati in `box-sizing`, la scrollbar può non avere lo spazio corretto.
- **Z-index conflittuale**: la scrollbar o un elemento overlay sopra di essa ha z-index errato, facendola apparire "fuori posto" rispetto alla griglia.
- **Scroll event listener con sideeffect**: un listener di scroll che modifica il DOM potrebbe causare recalcoli di altezza del container non sincronizzati con la scrollbar.

**Aree di indagine**:
1. Ispeziona il container griglia con `getComputedStyle()`: che valore ha `overflow`? È `auto`, `hidden`, o `visible`?
2. Controlla `height` e `padding` del container: sono coerenti con il layout atteso? Usa `getBoundingClientRect()` per verificare l'altezza effettiva.
3. Verifica il z-index della scrollbar e di elementi vicini nel DOM (header, footer, overlay).
4. Ispeziona le righe virtualizzate: hanno un'altezza coerente? Se le righe hanno altezze diverse, il calcolo dello scroll potrebbe essere errato.
5. Esegui un resize della finestra browser (F12 + drag del frame di debug): il sintomo scompare? Se sì, indica un calcolo non aggiornato al primo render.

**Azione rapida**:
- Assicurati che il container griglia abbia `overflow: auto` e `height: 100%` (o height esplicita).
- Aggiungi `box-sizing: border-box` al container e alle righe.
- Richiama un resize handler forzato dopo il mount della griglia: `window.dispatchEvent(new Event('resize'))` o un hook di recalcolo della scrollbar.

---

## Sintomo: Drag e drop rotto su griglia virtualizzata con 100+ righe

**Osservazione reale**: Il drag-and-drop funziona su poche righe, ma quando la griglia ha 100+ righe (virtualizzate), il drag non funziona, oppure funziona ma la preview del drag appare nel posto sbagliato, oppure il drop non registra la riga corretta.

**Ipotesi probabile**:
- **Coordinate di mouse non sincronizzate con scroll virtuale**: il componente di drag calcola le coordinate del mouse rispetto al DOM visibile, ma la griglia virtualizzata renderizza solo una finestra di righe. Se il calcolo non tiene conto dell'offset di scroll della virtualizzazione, le coordinate di drop sono sbagliate.
- **Transform CSS su elementi virtualizzati**: se le righe virtualizzate usano `transform: translateY()` per il posizionamento (anziché top/left assoluti), il calcolo di bounding rect per il drag potrebbe non contare il transform.
- **Event listener su elemento non virtualizzato**: il listener di drag è registrato sul container griglia non virtualizzato, ma gli elementi trascinabili sono dentro il viewport virtualizzato; l'event delegation non funziona correttamente.
- **Pointer events: none accidentale**: un overlay (loader, tooltip) sopra le righe virtualizzate potrebbe avere `pointer-events: none` non esplicitamente disabilitato dopo il caricamento, bloccando il drag.

**Aree di indagine**:
1. Prendi il bounding rect di una riga trascinabile: corrisponde alla posizione visiva sullo schermo? Se usi `transform: translateY()`, verifica che `getBoundingClientRect()` includa il transform (dovrebbe).
2. Verifica il listener di drag: è registrato sul parent della griglia o su ogni singola riga? Se è su ogni riga, potrebbe non funzionare se le righe non virtualizzate non hanno listener configurato.
3. Controlla se esiste un calcolo manuale di offset di scroll virtualizzato nel codice di drag: se manca, il calcolo di drop è probabilmente sbagliato.
4. Ispeziona il CSS delle righe: hanno `transform: translateY()` o `top/left` assoluti? Hanno `pointer-events: auto` esplicita?
5. Verifica se esiste un overlay (es. skeleton loader) sopra la griglia con `pointer-events: none` che non viene rimosso dopo il caricamento.

**Azione rapida**:
- Aggiungi il calcolo dello scroll offset del container virtualizzato al calcolo di mouse position nel drag: `dragX = mouseX + scrollContainer.scrollLeft`, `dragY = mouseY + scrollContainer.scrollTop + virtualScrollOffset`.
- Oppure usa `getBoundingClientRect()` direttamente sull'elemento draggato, non su calcoli manuali di posizione.
- Aggiungi `pointer-events: auto` esplicito alle righe trascinabili e verifica che nessun overlay blocchi i pointer events.

---

## Sintomo: "La griglia non si comporta bene al primo caricamento", generico

**Osservazione reale**: L'utente riporta che la griglia è "instabile", "scattosa", o "non si carica correttamente" al primo render, senza descrivere un sintomo specifico. Dopo un resize o interazione, il comportamento migliora.

**Ipotesi probabile**:
- **Rendering asincrono non sincronizzato**: il componente griglia ha logica di rendering asincrona (load dati, calcolo dimensioni) che non è resa sincrona con il mount del componente. Il render iniziale è fallback, il rendering "corretto" avviene dopo.
- **CSS media query mancante o errore di viewport**: la griglia ha stile responsive che non si applica correttamente al primo load (es. media query `(min-width: 768px)` che non triggera al primo render).
- **Stato di componente non inizializzato**: il componente ha stato di virtualizzazione/dimensioni non inizializzato correttamente al mount.

**Aree di indagine**:
1. Apri la console browser e raccogli i messaggi di warning/error al primo load della pagina.
2. Verifica il CSS applicato: controlla se `@media` query si applicano correttamente al viewport attuale.
3. Ispeziona il codice di mount del componente griglia: ci sono `useEffect` con dipendenze mancanti che causano render ripetuti?
4. Prova un resize della finestra (F12, drag frame): il comportamento migliora? Se sì, c'è una mancanza di sincronizzazione tra mount e calcolo delle dimensioni.
5. Verifica se il componente ha uno stato di "loading" che applica stile CSS fallback (es. `display: none` su righe virtualizzate durante il loading): questo potrebbe causare il comportamento "scattoso".

**Azione rapida**:
- Aggiungi una callback di recalcolo dopo il mount del componente, con un piccolo delay (`setTimeout(..., 0)` per push verso il prossimo frame).
- Oppure assicurati che tutte le dimensioni critiche (altezza container, altezza di riga, numero di righe visibili) siano calcolate in modo sincrono al mount, non asincrono.
- Aggiungi esplicitamente `window.addEventListener('resize', recalculateGrid)` per garantire la sincronizzazione dopo viewport changes.