Écriture hors ligne #15

New issue

Open

opened 2026-08-30 14:07:05 +01:00 by claudeagent · 0 comments

claudeagent commented

2026-08-30 14:07:05 +01:00

Collaborator

Description

Hors ligne, l'application sert une page en lecture seule : les listes et tâches de la famille active, état coché compris (D35). On consulte, on ne coche pas. Or cocher un article de courses dans un magasin sans réseau est précisément le cas d'usage visé.

Pourquoi c'est bloqué, et pas seulement pas fait
Dépend de #5.
D26 fait du serveur l'autorité sur l'état du client : toute mutation renvoie le snapshot complet et le client remplace son état plutôt que de calculer un résultat optimiste. Une écriture mise en file hors ligne puis rejouée est exactement l'inverse — le client décide de ce qui s'est passé pendant son absence. La détection de conflits doit exister d'abord ; ce ticket en dépend et ne peut pas commencer avant.

La contrainte technique du hors-ligne, à ne pas oublier
Le service worker enregistré à travers le proxy AppAPI hérite d'un default-src 'none' : fetch() y échoue toujours, connecté ou non (D35). Une file d'écritures rejouée par le worker au retour du réseau est donc impossible telle quelle — ce serait à l'application, une fois rouverte, de rejouer.

Ce qu'il faut trancher, le moment venu

Quelles écritures. Cocher et décocher couvrent presque tout l'usage hors ligne réel et sont les plus faciles à réconcilier. Créer, renommer et supprimer ouvrent des cas autrement plus larges.
Où vit la file. Cache Storage sert déjà les snapshots ; une file d'écritures est une donnée d'un autre genre (IndexedDB).
Ce que voit l'utilisateur d'une écriture en attente, et d'une écriture refusée au retour du réseau.

Plan d'action

TODO

Recette

Revue technique personnelle
Mise à jour du wiki (décision, schéma, interface, périmètre)
Revue fonctionnelle

Plan de MEP

TODO Planification de la livraison

## Description Hors ligne, l'application sert une page en lecture seule : les listes et tâches de la famille active, état coché compris (D35). On consulte, on ne coche pas. Or cocher un article de courses dans un magasin sans réseau est précisément le cas d'usage visé. **Pourquoi c'est bloqué, et pas seulement pas fait** Dépend de #5. D26 fait du serveur l'autorité sur l'état du client : toute mutation renvoie le snapshot complet et le client remplace son état plutôt que de calculer un résultat optimiste. Une écriture mise en file hors ligne puis rejouée est exactement l'inverse — le client décide de ce qui s'est passé pendant son absence. **La détection de conflits doit exister d'abord** ; ce ticket en dépend et ne peut pas commencer avant. **La contrainte technique du hors-ligne, à ne pas oublier** Le service worker enregistré à travers le proxy AppAPI hérite d'un `default-src 'none'` : `fetch()` y échoue toujours, connecté ou non (D35). Une file d'écritures rejouée par le worker au retour du réseau est donc impossible telle quelle — ce serait à l'application, une fois rouverte, de rejouer. **Ce qu'il faut trancher, le moment venu** - Quelles écritures. Cocher et décocher couvrent presque tout l'usage hors ligne réel et sont les plus faciles à réconcilier. Créer, renommer et supprimer ouvrent des cas autrement plus larges. - Où vit la file. Cache Storage sert déjà les snapshots ; une file d'écritures est une donnée d'un autre genre (IndexedDB). - Ce que voit l'utilisateur d'une écriture en attente, et d'une écriture refusée au retour du réseau. ## Plan d'action - [ ] TODO ## Recette - [ ] Revue technique personnelle - [ ] Mise à jour du wiki (décision, schéma, interface, périmètre) - [ ] Revue fonctionnelle ## Plan de MEP - [ ] TODO Planification de la livraison