fix: camp signup flag issue
Overview
What does this MR do and why?
Changes Made
Technical Details
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 |
|---|---|
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 anyunless 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.exampleupdated (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.