Skip to content

Resolve "Queue pages fail to render on volunteer dashboard"

Ahlad Pataparla requested to merge 239-queue-pages-fail-to-render-on-volunteer-dashboard into develop

Overview

This MR fixes a critical bug that prevented all queue pages (Vitals Queue, Consultation Queue, Prescriptions Queue, etc.) from rendering, leaving them as blank pages. The root cause was a mismatch between translation file structure and how those translations were used in React components.

What does this MR do and why?

Motivation: Volunteers could not access any queue pages, making the system unusable for patient management workflows.

Root Cause: The translation key common.doctor was defined as an object in translation files, but components were using it directly as a JSX child. When i18next returned an object, React's rendering engine threw an error: "Objects are not valid as a React child".

Approach Taken:

  1. Restructured translation keys to ensure critical UI keys are strings, not objects
  2. Updated code to use appropriate nested keys for structured data
  3. Added comprehensive regression tests to prevent this class of bugs from recurring

Trade-offs: None - this is a straightforward bug fix with proper abstractions maintained.

Changes Made

Files Modified

  • src/locales/en/translations.json - Changed common.doctor from object to string
  • src/locales/te/translations.json - Changed common.doctor from empty string to proper Telugu translation
  • src/locales/hi/translations.json - Changed common.doctor from empty string to proper Hindi translation
  • src/pages/DashboardPage.tsx - Updated t('common.doctor.actions') to t('common.doctorActions')
  • src/pages/doctor/DoctorPage.tsx - Updated t('common.doctor.actions') to t('common.doctorActions')
  • src/pages/doctor/DoctorHomePage.tsx - Updated t('common.doctor.actions') to t('common.doctorActions')

Files Added

  • tests/TranslationValidation.test.tsx - Monitors console errors for React object rendering issues
  • tests/TranslationStructure.test.tsx - Direct validation of translation key types

Technical Details

Root Cause Analysis:

The translation file had this structure:

"common": {
  "doctor": {
    "_": "| Doctor:",
    "actions": "Doctor Actions",
    "manageQueue": "Manage your consultation queue and view medicine availability"
  }
}

But components used it as:

<span>{t('common.doctor')}</span> // Returns object → React error

React cannot render objects as children, causing error:

Objects are not valid as a React child (found: object with keys {_, actions, manageQueue})

This affected all queue pages because they depend on PatientCard and QueueDisplay components, which use these critical translation keys directly in JSX.

How Fix Addresses It:

  1. Translation files: Changed critical keys to strings:

    "common": {
  "doctor": "Doctor:",
  "doctorActions": "Doctor Actions",
  "doctorManageQueue": "Manage your consultation queue and view medicine availability"
}

  2. Component updates: Changed nested key usage where needed:

    // Before: t('common.doctor.actions')
// After: t('common.doctorActions')

  3. Cross-language consistency: Added proper translations for Telugu and Hindi, not just English

  4. Test coverage: Added tests that would have caught this bug:

    • Tests monitor console.error for React rendering errors
    • Tests validate that critical translation keys are strings, not objects
    • Tests verify components render without errors using real translation files

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

Screenshots or Screen Recordings

Before (Bug) After (Fix)
Queue pages blank with console error Queue pages render correctly

How to Set Up and Validate Locally

  1. Pull this branch / checkout MR
  2. Install dependencies (no changes needed): 
    bun install
  3. Update environment variables (no changes needed): 
    # .env
VITE_SERVER_URL=https://api.ehrs.swecha.org
  4. Run development server: 
    bun dev
  5. Navigate to specific pages and verify:
    • Visit queue pages: /volunteer/vitals-queue, /volunteer/consultation-queue
    • Verify patient cards display with all information (name, book number, doctor info, etc.)
    • Check that filters (doctor, gender, specialization) work correctly
    • Verify no console errors appear
  6. Expected behavior:
    • Queue pages load with patient lists
    • Patient cards display all information correctly
    • No "Objects are not valid as a React child" errors in console
    • All volunteer queue pages (Vitals, Consultation, Prescriptions, Verify Medicines, Counseling) work

No backend changes required - this is a frontend-only fix.

Testing Done

  • Manual testing completed
  • Unit tests added/updated

Test Cases Covered:

Scenario Expected Result Status
Navigate to any volunteer queue page Page loads with patient list ✅
Patient cards display patient information Name, book number, doctor shown correctly ✅
Filter by doctor, specialization, gender Filters work, results update ✅
Search for patient by name/book number Search works, results filter correctly ✅
No console errors on queue pages No "Objects are not valid as a React child" errors ✅
Translation structure validation tests pass All critical keys are strings ✅
Console error monitoring tests pass Components render without errors ✅

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
# Result: 3 warnings (pre-existing), 0 errors

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)
  • Documentation added: tests/TRANSLATION_TESTS.md explains translation test coverage

Known Limitations / Technical Debt

No known limitations or technical debt introduced by this MR.

Recommendation: Consider adding a TypeScript type checker for translation keys in future to prevent type mismatches at compile time.

Additional Notes

Why This Bug Was Not Caught Earlier:

  • Existing test suite did not render queue pages with actual translation files
  • No tests monitored console.error for React rendering errors
  • No validation of translation file structure

Test Coverage Improvement: Added two new test files specifically for catching this class of bug:

  1. TranslationValidation.test.tsx - Monitors for React rendering errors
  2. TranslationStructure.test.tsx - Validates translation key types

These tests verify that critical translation keys used directly in JSX are always strings, not objects, preventing this bug from recurring.

Critical Translation Keys Validated: The following keys are now tested to ensure they are strings (not objects):

  • common.doctor - Used in PatientCard, QueueDisplay
  • common.bookNo - Used in PatientCard
  • common.symbol40, common.symbol41 - Used in PatientCard
  • common.joined - Used in PatientCard
  • common.searchPatients - Used in QueueDisplay
  • common.specialization - Used in QueueDisplay

MR Acceptance Checklist

  • Bug reproduction steps now produce expected behavior
  • All test cases pass (existing + new)
  • No console errors related to this issue
  • Fix works on all affected browsers (tested in Chrome, Firefox, Safari)
  • Fix works on all affected viewport sizes (mobile, tablet, desktop)
  • No regressions in related functionality (all queue pages work)
  • Unit tests added to prevent recurrence
  • Error boundaries handle similar cases gracefully (not implemented in this MR, can be follow-up)

Closes #239 (closed)

Edited by Ahlad Pataparla

Merge request reports