Fix/familygroup

Overview

Fix Family Creation API Payload Structure

This Merge Request addresses a 422 Unprocessable Entity error encountered when clicking the "Create Family" button in the frontend. Previously, the createFamily API call was passing the book_no and family_role as URL query parameters (params) instead of maintaining alignment with the backend's expected JSON request body schema.

Changes Made

• src/lib/api.ts: Modified the createFamily function to send book_no and family_role as the JSON payload body in apiClient.post, aligning with the backend behavior shown in the Swagger UI.
• tests/lib/api.test.ts: Updated the Axios mock expectation for createFamily tests to enforce strict validation against the new JSON body payload constraint and ensure the test suite continues to pass.
• CHANGELOG.md: Added a new entry under the ### 🐛 Bug Fixes section to reflect this patch.

Why

The backend endpoint strictly expects a JSON body (for example: -d '{"book_no": 16, "family_role": "head"}'). Prior changes inadvertently sent this data as a query string while passing null as the request body, which caused FastAPI to reject the requests with a 422 error. This fix cleanly resolves the mismatch without intrusive changes to the underlying components.

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	After
Create Family triggers 422 Console/Network Error	Family executes successfully and refreshes member log

How to Set Up and Validate Locally

1. Pull this branch / checkout MR: git checkout fix/familygrouping
2. Run development server:

   bun dev
   

Related Issues / References

Screenshots or Screen Recordings

Before	After

How to Set Up and Validate Locally

Testing Done

Test Cases Covered:

Scenario	Expected Result	Status
		✅/❌
		✅/❌
		✅/❌

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

Additional Notes

---

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.