davide
49b6c8a7e9
Il CLAUDE.md e la memory affermavano una sincronizzazione CSI e una persistenza server-side dei risultati partita che non esistono nel codice: la classifica è un array hardcoded (demo) e il risultato scoutato vive solo nel localStorage di chi segna.
1.3 KiB
1.3 KiB
name, description, type
| name | description | type |
|---|---|---|
| Efficienza Cloud | Regole per minimizzare query, traffico e invocazioni Cloud (piano 20 crediti/mese, 17 utenti) | feature |
- Nessun polling (
refetchInterval) verso il database; sincronizzazione locale via BroadcastChannel/storage dove possibile. - QueryClient globale: staleTime 5 min, gcTime 30 min, refetchOnWindowFocus/Mount/Reconnect disattivati, retry 1.
- Dopo una mutazione aggiornare la cache con
setQueryData, noninvalidateQueries(evita riletture). - Scout live: scrive solo l'utente che segna; gli altri leggono dati già salvati.
- Statistiche, badge e classifiche: "write once, read many" — calcolate e salvate una volta a fine partita, mai ricalcolate a ogni apertura pagina.
- Dati CSI: al momento è un array hardcoded in
src/lib/crapp-data.ts, marcato "(demo)" in UI — nessun sync reale, da implementare. Anche il risultato di una partita scoutata (ScoutMatch) oggi vive solo nellocalStoragedel dispositivo di chi scouta, non su Supabase. - Push solo per eventi importanti: convocazioni, promemoria allenamento/partita, turno palloni, esito finale.
- Niente foto/video/chat o funzionalità pesanti.
- Schema target: team_id, eventi, presenze, azioni_scout, statistiche_aggregate, classifica_csi, notifiche, con indici sui campi di filtro/relazione.