Quiz 2 — État & données (P6-P8)

Le plus local possible : useState pour l’UI locale, Zustand pour le partagé éphémère (session), AsyncStorage/persist pour les préférences, SQLite pour les données requêtables.

Autour des FlatList (items memo, handlers stables) et des composants mémoïsés — partout ailleurs, c’est du bruit (profiler d’abord).

Le JS est gelé/throttlé en arrière-plan : les ticks se perdent. La vérité = endsAt comparé à Date.now() (+ resync au retour AppState).

Pour réagir à chaque visite d’un écran (les écrans restent montés sous pile/tabs — useEffect([]) ne joue qu’au montage initial).

Les sélecteurs fins (useSession(s => s.score)) — jamais le store entier, qui abonne le composant à tout changement.

useStore.getState() / setState() — l’accès hors composants, sans hook ni abonnement.

Chaque phase porte SES données (endsAt qu’en playing), les combinaisons absurdes sont irreprésentables, TS force l’exhaustivité — et les gardes refusent les transitions illégales.

Sérialise le store dans AsyncStorage à chaque set et le réhydrate au démarrage — name (la clé) et version+migrate (les évolutions sans casser les données).

Les secrets (→ expo-secure-store), les données de masse/requêtables (→ SQLite), et tout objet non-JSON-sérialisable.

Pas de navigateur → pas de same-origin. Revers : tout ce qui est dans l’app est PUBLIC (décompilable) — aucune clé secrète embarquée, jamais.

staleTime = fraîcheur (frais → servi du cache sans réseau ; stale → servi + refetch en fond). gcTime = rétention mémoire d’une donnée inutilisée avant éviction.

onlineManager ← NetInfo et focusManager ← AppState — les remplaçants des événements window du web (reconnexion, retour au premier plan).

JSON par thème dans un repo GitHub public servi par raw.githubusercontent, fetch + zod + cache offline — mise à jour par git push, zéro serveur, scores locaux.

Strict sur l’ENVELOPPE du fichier (corrompu = erreur franche), safeParse PAR QUESTION (une invalide = ignorée + warning, le jeu continue) — tolérance proportionnée au dégât.

Les types TS dérivent du schéma zod (une seule source de vérité) : validation runtime et types compilés ne peuvent plus diverger.

Avec : les données + bandeau (un MODE, pas une erreur). Sans : ErrorState + retry + la banque de secours bundlée (jouable même à la première ouverture en avion).

On ne persiste que ce qui est en mémoire : une donnée garbage-collectée avant maxAge n’existe plus au moment de sauvegarder.

SELECT CAST(SUM(correct_count) AS REAL) / NULLIF(SUM(total), 0) FROM sessions WHERE theme = ? — CAST contre la division entière, NULLIF contre la division par zéro, paramètre contre l’injection.

PRAGMA user_version + tableau ordonné de migrations + une transaction chacune — on n’édite JAMAIS une migration livrée, on en ajoute. (Et foreign_keys = ON à chaque ouverture !)

Elles ne changent que par NOS écritures : l’invalidation explicite (onSuccess de la mutation) est le seul rafraîchissement nécessaire — zéro re-requête spontanée.