Skip to content

feat: added the food_preferences to the camp_signup page

Bikkumalla Sai Krishna requested to merge adding_food_preferences_in_camp_signup into develop

Overview

This MR introduces food preference selection for volunteers during the Medical Camp registration and "Join Camp" processes. It allows volunteers to specify their dietary needs (Breakfast, Lunch, and Veg/Non-Veg preference) directly in the UI.

What does this MR do and why?

To improve logistics and meal planning at medical camps, it is essential to know the food requirements of volunteers. This change adds:

  • Options to opt for Breakfast and Lunch.
  • Selection of food type (Veg/Non-Veg) when Lunch is selected.
  • Proper integration with the signup and camp-joining API payloads.

Changes Made

  • Frontend Pages:
    • src/pages/VolunteerRegisterPage.tsx: Added food preference section to the registration form.
    • src/pages/JoinVolunteerPage.tsx: Integrated food preferences for authenticated users joining a camp.
  • Types:
    • src/types/api.ts: Updated SignupSchema and CampSignupRequest to include food preference fields.
  • I18n:
    • Added translation keys for food-related labels in en, hi, and te locales.
  • Tests:
    • Updated tests/pages/VolunteerRegisterPage.test.tsx and tests/pages/JoinVolunteerPage.test.tsx to cover the new fields and interactions.
  • Documentation:
    • Updated CHANGELOG.md.

Technical Details

  • State Management: Added food_type, opt for breakfast, and opt for lunch to the form state in VolunteerRegisterPage and JoinVolunteerPage.
  • UI Components: Utilized Switch for opting in/out and Button toggles for food type selection.
  • Conditional Rendering: The "Food Type" selection only appears when "Opt for Lunch" is enabled to keep the UI clean.
  • API Payload: The registration and join camp requests now include the dietary preferences as optional fields.

Type of Change

  • 🐛 Bug fix (non-breaking change that fixes an issue)
  • ✨ New feature (non-breaking change that adds functionality)
  • 💥 Breaking change (fix or feature that would cause existing functionality to change)
  • 📝 Documentation update
  • 🎨 UI/UX improvement
  • ♻️ Refactor (no functional changes)
  • ⚡ Performance improvement
  • 🧪 Test update
  • 🔧 Configuration change
  • 🚨 Security fix

Related Issues / References

#ehrs-fastapi#50 (closed)

Screenshots or Screen Recordings

/home/saikrishna-bikkumalla/Videos/Screencasts/Screencast from 2026-03-21 23-52-44.webm

Before After
(No food options) (Food Preferences)

How to Set Up and Validate Locally

  1. Pull this branch / checkout MR
  2. Install dependencies: 
    bun install
  3. Run development server: 
    bun dev
  4. Navigate to the Volunteer Registration page (/register).
  5. Select "Opt for Breakfast" and "Opt for Lunch".
  6. Observe the "Food Type" toggle appearing.
  7. Complete the registration and verify the network request payload contains: 
    {
  "opt for breakfast": true,
  "opt for lunch": true,
  "food_type": "Veg"
}

Testing Done

  • Manual testing completed
  • Unit tests added/updated

Test Cases Covered:

Scenario Expected Result Status
Select Breakfast/Lunch Switches toggle correctly ✅
Select Lunch Food Type selection appears ✅
Unselect Lunch Food Type selection disappears ✅
Submit registration Payload includes food preferences ✅

Code Quality Checklist

Code Standards

  • Code follows project conventions (naming, structure, formatting)
  • No console.log() or debugger statements left in code
  • No unused imports, variables, or functions
  • No duplicate code and use of existing components for reusability
  • i18n check passed with no hardcoded strings in codebase for i18n support
  • TypeScript types are properly defined (no any unless justified)
  • ESLint and Prettier checks pass 
    bun run lint

React Best Practices

  • Components are properly split and single-responsibility
  • Hooks follow rules (no conditional hooks, proper dependencies)
  • State management is appropriate (local vs global state)
  • No unnecessary re-renders (memoization used where needed)
  • Event handlers are properly cleaned up

Component Patterns

  • shadcn/ui components used correctly
  • Tailwind classes follow utility-first approach
  • Responsive design considered (mobile-first if applicable)
  • Accessibility attributes included (aria-*, role, etc.)
  • Icons from lucide-react used consistently

API & Data Fetching

  • TanStack Query used for server state (if applicable)
  • Loading and error states handled
  • API types defined in src/types/api.ts
  • Axios interceptors handle auth tokens correctly
  • Use of Zod for data validations

Error Handling

  • Errors are caught and handled gracefully
  • User-friendly error messages displayed
  • Errors are being toasted properly
  • Network failures handled appropriately

Documentation

  • README.md updated (if setup steps changed)
  • .env.example updated (if new env vars added)
  • CHANGELOG.md updated (if applicable)

Known Limitations / Technical Debt

  • None identified at this stage.

Additional Notes

  • The food type selection is currently only linked to Lunch opting. If breakfast type is needed in the future, it can be extended.

MR Acceptance Checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Mohana Sri Bhavitha

Merge request reports