Sélection de recettes : barre de recherche commune à toutes les sources #133

Closed
opened 2026-09-09 13:20:11 +02:00 by kyuno · 1 comment
Owner

Contexte

Origine : ticket #3, puce 6 — « Dans la sélection de recettes, il faut faire en sorte que la barre de recherche soit commune à toutes les sources ».

Le catalogue (RecipesPage, /recettes) a un onglet par source activée du foyer, en plus de Favoris/Perso/Foyer/Publique (RecipeTabs, RecipeTabs.tsx). Aujourd'hui :

  • RecipesPage a son propre champ recherche (search/debouncedSearch) affiché uniquement pour les onglets réels (activeSourceKey === null, RecipesPage.tsx:182-190).
  • Sur un onglet source, c'est RecipeSourcesPanel qui rend son propre champ recherche, avec son propre search/debouncedSearch (RecipeSourcesPanel.tsx:85-86, :298-306).
  • RecipeSourcesPanel est remonté à chaque changement d'onglet source (key={activeSourceKey}, RecipesPage.tsx:202-204) ⇒ la requête tapée est perdue dès qu'on passe d'une source à une autre (ou d'un onglet réel à une source).

Comportement souhaité

Une seule barre de recherche, dans l'en-tête de RecipesPage, dont la valeur persiste quand on change d'onglet source (et idéalement entre onglets réels et sources). Taper « poulet » puis basculer de TheMealDB à Marmiton garde « poulet » et relance la recherche sur la nouvelle source.

Conception proposée

Remonter l'état de recherche dans RecipesPage et le passer en props à RecipeSourcesPanel au lieu qu'il le possède :

  • RecipesPage : rendre le champ recherche toujours (retirer la condition activeSourceKey === null, RecipesPage.tsx:182). search/debouncedSearch déjà présents (RecipesPage.tsx:77-89).
  • RecipeSourcesPanel : search/debouncedSearch deviennent des props ; supprimer le useState + l'<input> + le useEffect de debounce internes (RecipeSourcesPanel.tsx:85-86, :155-158) ; l'effet de fetch dépend désormais de la prop (RecipeSourcesPanel.tsx:160-181). Le key={activeSourceKey} peut rester (remonte la liste/le prefetch, ce qui est voulu) — la recherche vit maintenant au-dessus.
  • Conséquence : la recherche est partagée aussi avec les onglets réels (listRecipes({ search })). Cohérent avec « commune ». Voir « Points à trancher » si on veut garder réels/sources séparés.
  • ?search= deep-link (RecipesPage.tsx:64-66) : inchangé, il seed déjà search.
  • SCSS : .recipes-page__header--sources (recipes.scss:367-369) n'a plus de champ à styler ; l'en-tête unique de RecipesPage sert pour tous les onglets.

Découpage proposé

Une PR — changement petit et localisé à 2 fichiers.

Tests (obligatoires, cf. specs/dev-conventions.md)

  • Cypress mode layout / recipe-sources.feature : taper une requête sur un onglet source, basculer vers un autre onglet source ⇒ la requête est conservée et la liste de la nouvelle source est filtrée ; basculer réel ↔ source conserve aussi ; effacer la requête recharge la liste complète. Mock GET /sources/:key/browse en vérifiant le param query.
  • Non-régression : infinite scroll / prefetch de RecipeSourcesPanel (le key de remontée est conservé).

Documentation à mettre à jour

  • specs/frontend-architecture.md — section catalogue recettes / onglets sources : la recherche est au niveau page, pas par panneau.

Points restant à trancher en revue

  • Recherche vraiment commune réels + sources (un seul champ pour tout le catalogue, recommandé), ou seulement entre sources (deux champs : un pour les onglets DB, un pour les sources) ? La puce dit « commune à toutes les sources ».
  • Garder key={activeSourceKey} sur RecipeSourcesPanel (remonte liste + prefetch au changement de source, la recherche restant portée au-dessus) — a priori oui, rien à changer là.
  • Debounce : une seule valeur debouncedSearch portée par RecipesPage sert les deux chemins (300 ms, déjà la même constante des deux côtés).

🤖 Filed by Claude Code

## Contexte Origine : ticket #3, puce 6 — *« Dans la sélection de recettes, il faut faire en sorte que la barre de recherche soit commune à toutes les sources »*. Le catalogue (`RecipesPage`, `/recettes`) a un onglet par source activée du foyer, en plus de Favoris/Perso/Foyer/Publique (`RecipeTabs`, [RecipeTabs.tsx](apps/web/src/features/recipes/RecipeTabs.tsx)). Aujourd'hui : - `RecipesPage` a son propre champ recherche (`search`/`debouncedSearch`) affiché **uniquement pour les onglets réels** (`activeSourceKey === null`, [RecipesPage.tsx:182-190](apps/web/src/pages/recipes/RecipesPage.tsx#L182-L190)). - Sur un onglet source, c'est `RecipeSourcesPanel` qui rend **son propre** champ recherche, avec **son propre** `search`/`debouncedSearch` ([RecipeSourcesPanel.tsx:85-86](apps/web/src/features/recipes/sources/RecipeSourcesPanel.tsx#L85-L86), [:298-306](apps/web/src/features/recipes/sources/RecipeSourcesPanel.tsx#L298-L306)). - `RecipeSourcesPanel` est **remonté** à chaque changement d'onglet source (`key={activeSourceKey}`, [RecipesPage.tsx:202-204](apps/web/src/pages/recipes/RecipesPage.tsx#L202-L204)) ⇒ la requête tapée est **perdue** dès qu'on passe d'une source à une autre (ou d'un onglet réel à une source). ## Comportement souhaité Une **seule** barre de recherche, dans l'en-tête de `RecipesPage`, dont la valeur **persiste** quand on change d'onglet source (et idéalement entre onglets réels et sources). Taper « poulet » puis basculer de TheMealDB à Marmiton garde « poulet » et relance la recherche sur la nouvelle source. ## Conception proposée Remonter l'état de recherche dans `RecipesPage` et le passer en **props** à `RecipeSourcesPanel` au lieu qu'il le possède : - `RecipesPage` : rendre le champ recherche **toujours** (retirer la condition `activeSourceKey === null`, [RecipesPage.tsx:182](apps/web/src/pages/recipes/RecipesPage.tsx#L182)). `search`/`debouncedSearch` déjà présents ([RecipesPage.tsx:77-89](apps/web/src/pages/recipes/RecipesPage.tsx#L77-L89)). - `RecipeSourcesPanel` : `search`/`debouncedSearch` deviennent des props ; supprimer le `useState` + l'`<input>` + le `useEffect` de debounce internes ([RecipeSourcesPanel.tsx:85-86](apps/web/src/features/recipes/sources/RecipeSourcesPanel.tsx#L85-L86), [:155-158](apps/web/src/features/recipes/sources/RecipeSourcesPanel.tsx#L155-L158)) ; l'effet de fetch dépend désormais de la prop ([RecipeSourcesPanel.tsx:160-181](apps/web/src/features/recipes/sources/RecipeSourcesPanel.tsx#L160-L181)). Le `key={activeSourceKey}` peut rester (remonte la liste/le prefetch, ce qui est voulu) — la recherche vit maintenant au-dessus. - Conséquence : la recherche est partagée **aussi** avec les onglets réels (`listRecipes({ search })`). Cohérent avec « commune ». Voir « Points à trancher » si on veut garder réels/sources séparés. - `?search=` deep-link ([RecipesPage.tsx:64-66](apps/web/src/pages/recipes/RecipesPage.tsx#L64-L66)) : inchangé, il seed déjà `search`. - SCSS : `.recipes-page__header--sources` ([recipes.scss:367-369](apps/web/src/features/recipes/recipes.scss#L367-L369)) n'a plus de champ à styler ; l'en-tête unique de `RecipesPage` sert pour tous les onglets. ## Découpage proposé Une PR — changement petit et localisé à 2 fichiers. ## Tests (obligatoires, cf. `specs/dev-conventions.md`) - **Cypress** mode layout / `recipe-sources.feature` : taper une requête sur un onglet source, basculer vers un autre onglet source ⇒ la requête est conservée et la liste de la nouvelle source est filtrée ; basculer réel ↔ source conserve aussi ; effacer la requête recharge la liste complète. Mock `GET /sources/:key/browse` en vérifiant le param `query`. - Non-régression : infinite scroll / prefetch de `RecipeSourcesPanel` (le `key` de remontée est conservé). ## Documentation à mettre à jour - `specs/frontend-architecture.md` — section catalogue recettes / onglets sources : la recherche est au niveau page, pas par panneau. ## Points restant à trancher en revue - Recherche vraiment **commune réels + sources** (un seul champ pour tout le catalogue, recommandé), ou seulement **entre sources** (deux champs : un pour les onglets DB, un pour les sources) ? La puce dit « commune à toutes les sources ». - Garder `key={activeSourceKey}` sur `RecipeSourcesPanel` (remonte liste + prefetch au changement de source, la recherche restant portée au-dessus) — a priori oui, rien à changer là. - Debounce : une seule valeur `debouncedSearch` portée par `RecipesPage` sert les deux chemins (300 ms, déjà la même constante des deux côtés). --- 🤖 Filed by [Claude Code](https://claude.com/claude-code)
kyuno added the
enhancement
planned
labels 2026-09-09 13:20:11 +02:00
kyuno added the
Medium
label 2026-09-09 13:23:59 +02:00
Author
Owner

Implémenté par la PR #140, mergée dans main (0c4e8d0). Les 6 jobs CI étaient verts. Barre de recherche remontée dans RecipesPage/RecipePickerDialog et passée en prop à RecipeSourcesPanel ; le terme persiste désormais au changement d'onglet source.

Implémenté par la PR #140, mergée dans `main` (`0c4e8d0`). Les 6 jobs CI étaient verts. Barre de recherche remontée dans `RecipesPage`/`RecipePickerDialog` et passée en prop à `RecipeSourcesPanel` ; le terme persiste désormais au changement d'onglet source.
kyuno closed this issue 2026-09-09 19:19:25 +02:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: kyuno/batchCooking#133
No description provided.