Feature: User Recipe gallery / visualization page or modal

[marcuscastelo]

Feature Request Template

Title:
User Recipe gallery / visualization page or modal

Description:
Currently the app only lets users view recipes via the template search modal, and the only way to create a recipe is by converting a group into a recipe. This makes it hard to discover existing/duplicate recipes and manage a personal collection. Propose a dedicated "My Recipes" gallery page and an optional modal variant that lists the user's recipes and provides management and sharing capabilities (and optionally a public gallery/profile later on).

Motivation:
Users need an easy way to discover whether a recipe already exists before creating a duplicate, to manage visibility (public/private), to share recipes, and to browse/sort their collection by meaningful criteria (name, creation date, main calories, ingredients). This improves discoverability, reduces duplicate content, and enables future public-profile/gallery features.

Proposed Solution:

• Frontend
  • Add a "My Recipes" page (e.g., /recipes/my or /profile/recipes) and a compact modal variant reachable from recipe-related flows.
  • Implement a list/grid of recipe cards with preview (title, main calories, primary ingredients, thumbnail).
  • Sorting/grouping options: alphabetical (A→Z), creation date (new→old / old→new), main calories (desc/asc), and by primary/main ingredients.
  • Search/filter by name, ingredient, tags; support pagination or infinite scroll for large collections.
  • Per-recipe actions on each card: view details (modal or page), edit, duplicate, delete, toggle public/private, share (copy link / social share).
  • Support creating a recipe directly from the gallery UI (form) while preserving the existing "convert group to recipe" flow.
  • Respect styling, accessibility, and existing design systems.
• Backend / API
  • Expose endpoints for the current user: GET /api/recipes?owner=me[&sort=&filter=&page=], POST /api/recipes, PATCH /api/recipes/:id (visibility, edits), DELETE /api/recipes/:id.
  • Ensure visibility (public/private) is persisted and enforced for read endpoints.
  • Consider adding lightweight summary fields (mainCalories, primaryIngredients) to speed listing queries.
• Tests & docs
  • Add unit/integration tests for new API endpoints and key UI behaviors.
  • Document the new route(s) and user flows in docs/ and update any related onboarding or help text.

Acceptance Criteria:

• A "My Recipes" gallery page exists and lists the user's recipes.
• The gallery supports sorting by name, creation date, main calories, and primary ingredient.
• Each recipe exposes a detail view (modal or page) with ingredients, calories, metadata, and actions: edit, duplicate, share, toggle public/private, delete.
• The user can create a new recipe from the gallery UI; the existing "convert group to recipe" flow remains functional.
• Recipes can be marked public/private from the UI and changes persist.
• Searching and filtering by name/ingredient are supported; large lists are paginated or lazily loaded.
• Basic tests exist for the new API endpoints and core UI behaviors; implementation follows repo style and accessibility guidelines.