maximus/simpl-liste

Fork 0

fix: show all tasks in widget (#23) #24

Merged

maximus merged 4 commits from fix/simpl-liste-23-widget-task-count into master

2026-03-13 00:25:22 +00:00

medic-bot commented

2026-03-12 23:48:30 +00:00

Collaborator

Problème

Le widget affichait une liste incomplète de tâches :

Le compteur en haut à droite montrait 9 tâches
La liste n'en affichait que 8
L'app en comptait 10 (dont 1 avec une date éloignée)

Cause

Deux problèmes dans le code du widget :

widgetSync.ts : le filtre lte(dueDate, twoWeeksEnd) excluait les tâches avec une date > 2 semaines
TaskListWidget.tsx : tasks.slice(0, maxItems) limitait l'affichage à 8 items (Large) / 4 (Medium), mais le compteur affichait tasks.length — causant une incohérence

Fix

Retrait de la limite de 2 semaines → toutes les tâches futures sont incluses
Retrait du maxItems slice → la ListWidget scrollable affiche toutes les tâches
Le compteur correspond maintenant exactement à la liste affichée

Fixes #23

## Problème Le widget affichait une liste incomplète de tâches : - Le compteur en haut à droite montrait 9 tâches - La liste n'en affichait que 8 - L'app en comptait 10 (dont 1 avec une date éloignée) ## Cause Deux problèmes dans le code du widget : 1. **`widgetSync.ts`** : le filtre `lte(dueDate, twoWeeksEnd)` excluait les tâches avec une date > 2 semaines 2. **`TaskListWidget.tsx`** : `tasks.slice(0, maxItems)` limitait l'affichage à 8 items (Large) / 4 (Medium), mais le compteur affichait `tasks.length` — causant une incohérence ## Fix - Retrait de la limite de 2 semaines → toutes les tâches futures sont incluses - Retrait du `maxItems` slice → la `ListWidget` scrollable affiche toutes les tâches - Le compteur correspond maintenant exactement à la liste affichée Fixes #23

medic-bot added 1 commit 2026-03-12 23:48:30 +00:00

fix: show all tasks in widget without date or count limits dde33acdf2

Remove the 2-week date filter from widget task query so tasks with
distant due dates are included. Remove the maxItems truncation from
the scrollable ListWidget so the displayed list matches the counter.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

maximus added 1 commit 2026-03-13 00:04:42 +00:00

feat: add configurable widget display period setting (#23 ) f040ec7902

Instead of removing the time filter entirely, let users choose the
widget display period (1 week, 2 weeks, 4 weeks, or all tasks) from
Settings. Default remains 2 weeks for backward compatibility.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

medic-bot commented

2026-03-13 00:07:25 +00:00

Author

Collaborator

Reviewer automatique — needs-fix

Le fix retire la limite maxItems (corrige le 8 vs 9), mais le défaut widgetPeriodWeeks=2 ne résout pas le cas de la tâche à date éloignée — l'utilisateur devrait découvrir le nouveau réglage pour voir ses 10 tâches. De plus, l'ajout d'une UI de configuration complète est du scope creep par rapport à l'issue qui demande simplement d'afficher toutes les tâches.

Suggestions de simplification

app/(tabs)/settings.tsx : L'issue demande d'afficher toutes les tâches dans le widget, pas d'ajouter un réglage de période configurable. Toute la section UI Widget (55 lignes) est hors scope. Le fix minimal est de retirer le maxItems ET le filtre 2 semaines dans widgetSync.ts (ou mettre le défaut à 0). Si une configuration de période est souhaitée, ça devrait être une issue séparée.
src/i18n/fr.json : Les 4 clés i18n ajoutées (period, periodWeek_one, periodWeek_other, periodAll) ne servent qu'à la section settings hors scope. À retirer si la simplification de settings.tsx est appliquée.

Problèmes détectés

src/stores/useSettingsStore.ts:29 [high] Le défaut widgetPeriodWeeks: 2 ne résout pas l'issue. L'utilisateur rapporte que la tâche à date éloignée n'apparaît pas — avec un défaut de 2 semaines, elle restera invisible. Le défaut devrait être 0 (toutes les tâches) pour réellement corriger le bug rapporté, ou simplement retirer le filtre de période sans ajouter de configuration.
src/services/widgetSync.ts:40 [medium] La lecture directe d'AsyncStorage avec settings?.state?.widgetPeriodWeeks dépend de la structure interne de persistance de Zustand ({ state: { ... } }). Si le middleware change de format, cette lecture échouera silencieusement et tombera sur le défaut 2. Extraire le nom de la clé et la structure dans une constante partagée, ou exposer une fonction utilitaire depuis useSettingsStore pour lire la valeur hors contexte React.

## Reviewer automatique — needs-fix Le fix retire la limite maxItems (corrige le 8 vs 9), mais le défaut widgetPeriodWeeks=2 ne résout pas le cas de la tâche à date éloignée — l'utilisateur devrait découvrir le nouveau réglage pour voir ses 10 tâches. De plus, l'ajout d'une UI de configuration complète est du scope creep par rapport à l'issue qui demande simplement d'afficher toutes les tâches. ### Suggestions de simplification - **app/(tabs)/settings.tsx** : L'issue demande d'afficher toutes les tâches dans le widget, pas d'ajouter un réglage de période configurable. Toute la section UI Widget (55 lignes) est hors scope. Le fix minimal est de retirer le maxItems ET le filtre 2 semaines dans widgetSync.ts (ou mettre le défaut à 0). Si une configuration de période est souhaitée, ça devrait être une issue séparée. - **src/i18n/fr.json** : Les 4 clés i18n ajoutées (period, periodWeek_one, periodWeek_other, periodAll) ne servent qu'à la section settings hors scope. À retirer si la simplification de settings.tsx est appliquée. ### Problèmes détectés - **src/stores/useSettingsStore.ts:29** [high] Le défaut `widgetPeriodWeeks: 2` ne résout pas l'issue. L'utilisateur rapporte que la tâche à date éloignée n'apparaît pas — avec un défaut de 2 semaines, elle restera invisible. Le défaut devrait être `0` (toutes les tâches) pour réellement corriger le bug rapporté, ou simplement retirer le filtre de période sans ajouter de configuration. - **src/services/widgetSync.ts:40** [medium] La lecture directe d'AsyncStorage avec `settings?.state?.widgetPeriodWeeks` dépend de la structure interne de persistance de Zustand (`{ state: { ... } }`). Si le middleware change de format, cette lecture échouera silencieusement et tombera sur le défaut 2. Extraire le nom de la clé et la structure dans une constante partagée, ou exposer une fonction utilitaire depuis useSettingsStore pour lire la valeur hors contexte React.

maximus added 1 commit 2026-03-13 00:10:47 +00:00

fix: default widget period to all tasks (#23 ) 2e13528c6b

Change default widgetPeriodWeeks from 2 to 0 (all tasks) so that the
issue is resolved out of the box without requiring the user to discover
the new setting.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

medic-bot commented

2026-03-13 00:19:13 +00:00

Author

Collaborator

Reviewer automatique — needs-fix

Le défaut widgetPeriodWeeks=0 et le retrait de maxItems résolvent l'issue originale. Cependant, retirer TOUT plafond de tâches dans le widget est risqué (crash mémoire Android), la clé i18n 'widget.title' semble manquante, et aucun test n'est ajouté.

Suggestions de simplification

src/services/widgetSync.ts : Plutôt que lire AsyncStorage manuellement et parser le JSON, considérer exporter une fonction utilitaire depuis useSettingsStore.ts qui lit la valeur depuis AsyncStorage (hors contexte React). Cela centralise l'accès et évite la duplication du chemin de stockage.

Problèmes détectés

src/widgets/TaskListWidget.tsx:477 [high] Le retrait complet de maxItems signifie que le widget rendra TOUTES les tâches sans limite. Les widgets Android ont des contraintes mémoire strictes (~10 MB). Un utilisateur avec 50+ tâches risque un crash ou un widget blanc. Il faut garder un plafond d'affichage raisonnable (ex: 20-30 items) même si on ne filtre plus par période. L'ancien maxItems=8 était trop bas, mais 0 est dangereux. Suggestion : const displayTasks = tasks.slice(0, 30); et utiliser displayTasks dans le rendu.
src/i18n/fr.json:138 [medium] settings.tsx utilise t('widget.title') (ligne 308) mais ni fr.json ni en.json n'ajoutent la clé 'title' dans le bloc widget. Si elle n'existait pas déjà, l'UI affichera la clé brute 'widget.title' au lieu d'un libellé. Vérifier que cette clé existe dans les fichiers i18n complets, sinon l'ajouter (ex: 'Widget' en fr, 'Widget' en en).
src/services/widgetSync.ts:38 [medium] La lecture directe d'AsyncStorage avec le chemin hardcodé 'simpl-liste-settings' + state.widgetPeriodWeeks duplique la config zustand persist. Si le nom du store ou la structure change, ce code cassera silencieusement (fallback à 0 sans erreur visible). Ajouter au minimum un commentaire avec une référence croisée vers useSettingsStore.ts pour signaler ce couplage implicite.
src/services/widgetSync.ts:37 [low] Aucun test n'est ajouté pour valider le comportement du filtre par période (widgetPeriodWeeks=0 retourne tout, widgetPeriodWeeks=2 filtre à 2 semaines). C'est la logique centrale du fix — un test unitaire sur la construction des conditions de requête serait pertinent pour éviter les régressions.

## Reviewer automatique — needs-fix Le défaut widgetPeriodWeeks=0 et le retrait de maxItems résolvent l'issue originale. Cependant, retirer TOUT plafond de tâches dans le widget est risqué (crash mémoire Android), la clé i18n 'widget.title' semble manquante, et aucun test n'est ajouté. ### Suggestions de simplification - **src/services/widgetSync.ts** : Plutôt que lire AsyncStorage manuellement et parser le JSON, considérer exporter une fonction utilitaire depuis useSettingsStore.ts qui lit la valeur depuis AsyncStorage (hors contexte React). Cela centralise l'accès et évite la duplication du chemin de stockage. ### Problèmes détectés - **src/widgets/TaskListWidget.tsx:477** [high] Le retrait complet de maxItems signifie que le widget rendra TOUTES les tâches sans limite. Les widgets Android ont des contraintes mémoire strictes (~10 MB). Un utilisateur avec 50+ tâches risque un crash ou un widget blanc. Il faut garder un plafond d'affichage raisonnable (ex: 20-30 items) même si on ne filtre plus par période. L'ancien maxItems=8 était trop bas, mais 0 est dangereux. Suggestion : `const displayTasks = tasks.slice(0, 30);` et utiliser displayTasks dans le rendu. - **src/i18n/fr.json:138** [medium] settings.tsx utilise `t('widget.title')` (ligne 308) mais ni fr.json ni en.json n'ajoutent la clé 'title' dans le bloc widget. Si elle n'existait pas déjà, l'UI affichera la clé brute 'widget.title' au lieu d'un libellé. Vérifier que cette clé existe dans les fichiers i18n complets, sinon l'ajouter (ex: 'Widget' en fr, 'Widget' en en). - **src/services/widgetSync.ts:38** [medium] La lecture directe d'AsyncStorage avec le chemin hardcodé 'simpl-liste-settings' + `state.widgetPeriodWeeks` duplique la config zustand persist. Si le nom du store ou la structure change, ce code cassera silencieusement (fallback à 0 sans erreur visible). Ajouter au minimum un commentaire avec une référence croisée vers useSettingsStore.ts pour signaler ce couplage implicite. - **src/services/widgetSync.ts:37** [low] Aucun test n'est ajouté pour valider le comportement du filtre par période (widgetPeriodWeeks=0 retourne tout, widgetPeriodWeeks=2 filtre à 2 semaines). C'est la logique centrale du fix — un test unitaire sur la construction des conditions de requête serait pertinent pour éviter les régressions.

maximus added 1 commit 2026-03-13 00:20:48 +00:00

fix: cap widget task list at 30 items to prevent memory issues 9a8bb13e97

Add safety limit of 30 rendered tasks in the widget to avoid Android
memory constraints. Also add cross-reference comment for the implicit
AsyncStorage coupling with useSettingsStore.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

medic-bot commented

2026-03-13 00:24:03 +00:00

Author

Collaborator

Reviewer automatique — approved

Le fix résout correctement l'issue : défaut widgetPeriodWeeks=0 affiche toutes les tâches, le cap à 30 items protège contre les crashs mémoire Android, et l'UI de configuration est propre et cohérente. Les problèmes soulevés aux rounds précédents ont été adressés. L'absence de tests est justifiée par l'absence d'infrastructure de tests dans le projet.

Suggestions de simplification

app/(tabs)/settings.tsx : Le header de section utilise t('widget.title') qui retourne 'Simpl-Liste' (le titre affiché DANS le widget). Pour la section paramètres, un libellé comme 'Widget' serait plus clair et cohérent avec les autres sections ('Notifications', 'Calendrier'). Considérer ajouter une clé i18n dédiée (ex: 'settings.widget') ou simplement afficher 'Widget'.
src/services/widgetSync.ts : La lecture manuelle d'AsyncStorage + JSON.parse pour accéder à widgetPeriodWeeks crée un couplage implicite avec la structure du store Zustand (clé 'simpl-liste-settings', chemin state.widgetPeriodWeeks). Le commentaire documente bien ce couplage, mais une constante partagée pour la clé AsyncStorage et le chemin réduirait le risque de désynchronisation si le store évolue.

## Reviewer automatique — approved Le fix résout correctement l'issue : défaut widgetPeriodWeeks=0 affiche toutes les tâches, le cap à 30 items protège contre les crashs mémoire Android, et l'UI de configuration est propre et cohérente. Les problèmes soulevés aux rounds précédents ont été adressés. L'absence de tests est justifiée par l'absence d'infrastructure de tests dans le projet. ### Suggestions de simplification - **app/(tabs)/settings.tsx** : Le header de section utilise t('widget.title') qui retourne 'Simpl-Liste' (le titre affiché DANS le widget). Pour la section paramètres, un libellé comme 'Widget' serait plus clair et cohérent avec les autres sections ('Notifications', 'Calendrier'). Considérer ajouter une clé i18n dédiée (ex: 'settings.widget') ou simplement afficher 'Widget'. - **src/services/widgetSync.ts** : La lecture manuelle d'AsyncStorage + JSON.parse pour accéder à widgetPeriodWeeks crée un couplage implicite avec la structure du store Zustand (clé 'simpl-liste-settings', chemin state.widgetPeriodWeeks). Le commentaire documente bien ce couplage, mais une constante partagée pour la clé AsyncStorage et le chemin réduirait le risque de désynchronisation si le store évolue.