Implement registration form validation with LMS integration for Plan Details Register substep

[Copilot]

This PR implements a comprehensive registration form validation system for the Plan Details Register substep, demonstrating how to validate registration forms without altering the app's architectural layout by reusing the existing RHF + Zod resolver pattern.

What this PR does

1. LMS Registration Validation Service

Created src/components/app/data/services/registration.ts that:

• POSTs to ${LMS_BASE_URL}/user_api/v1/account/registration/ with isPublic: true for validation-only requests
• Maps 4xx error responses to structured field errors with friendly messages
• Provides validateRegistrationFields(values) helper returning { isValid, errors }
• Includes resilient error mapping where unknown LMS keys fall back to root errors

2. Real Zod Schema Implementation

Replaced the empty PlanDetailsRegisterPageSchema in src/constants/checkout.ts with a complete validation schema featuring:

• Client-side validation: email format, required fields, min/max lengths, username pattern matching, password confirmation
• Server-side integration: superRefine that defers to LMS registration endpoint when client checks pass
• Field coverage: adminEmail, fullName, username, password, confirmPassword, country
• Error mapping: LMS validation errors properly mapped back to Zod issues with field-specific targeting

3. Registration UI Implementation

Updated src/components/FormFields/RegisterAccountFields.tsx to render actual form fields:

• Replaced placeholder copy with 6 functional form fields using existing Field/FieldContainer primitives
• Pre-populates and locks Work email when already available (mirrors LoginFields pattern)
• Maintains existing layout and styling consistency
• Includes proper field types (email, password, text, select) with country dropdown options

4. Comprehensive Testing

Added 11 new unit tests covering:

• Form field rendering and proper input types
• Schema validation for all validation scenarios (email format, password requirements, field matching)
• UI component structure and accessibility
• Complete registration form workflow demonstration

Technical Approach

This implementation follows the established patterns in the codebase:

• Mirrors quantity validation: Uses async Zod refinement pattern like existing validateFieldDetailed usage
• Follows LoginFields pattern: Pre-population and field locking behavior matches existing login implementation
• Preserves architecture: No changes to routing, stepper logic, or core application structure
• Type safety: Full TypeScript compliance with proper interface definitions

Usage

The registration form is accessible at /plan-details/register and provides:

• Immediate client-side validation feedback
• Server-side validation integration with LMS registration endpoint
• Field-specific error messaging sourced from LMS responses
• Pre-populated email from previous step data
• Complete form coverage matching design requirements

Testing

All tests pass (172 total), including:

• ✅ TypeScript compilation with no errors
• ✅ ESLint rules compliance
• ✅ Comprehensive unit test coverage for new functionality
• ✅ No breaking changes to existing functionality

The implementation successfully demonstrates registration form validation integration without architectural changes while maintaining code quality and test coverage standards.

This pull request was created as a result of the following prompt from Copilot chat.

Goal
Demonstrate how we can validate a registration form in the Plan Details Register substep without altering the app’s architectural layout, by reusing the existing RHF + Zod resolver pattern and adding a small LMS-facing validation service.

Context

• The stepper already includes a PlanDetailsRegister page, but its schema is empty and RegisterAccountFields renders only copy. We want to minimally implement:
  • Client-side Zod validation for the fields shown in the attached mock
  • A superRefine that defers to the LMS registration endpoint to surface server messages (email/username uniqueness, password policy, etc.)
• This mirrors how quantity validation is done in PlanDetails (using an async Zod refinement), but targets the LMS endpoint rather than the BFF validation API.

Design reference

What this PR does (POC scope)

1. Add a new LMS registration validation service
   • src/components/app/data/services/registration.ts
   • POSTs to ${LMS_BASE_URL}/user_api/v1/account/registration/ with isPublic: true
   • Returns success for 200/201; maps 4xx error payloads to field errors and a friendly structure
   • Helper validateRegistrationFields(values) returns { isValid, errors }
2. Implement a real Zod schema for the PlanDetailsRegister substep
   • src/constants/checkout.ts: implement PlanDetailsRegisterPageSchema() with fields
     • adminEmail (Work email)
     • fullName (Full name)
     • username (Public username)
     • password, confirmPassword (Confirm)
     • country
   • Basic client checks: email format, required, min/max, username pattern, password length
   • superRefine: if client checks pass and passwords match, call validateRegistrationFields and map LMS errors back into Zod issues (email, username, password, name, country)
3. Make the registration UI render these fields
   • src/components/FormFields/RegisterAccountFields.tsx: render Field controls to match the mock, reusing existing Field/FieldContainer primitives so layout remains unchanged
   • Pre-populate and lock Work email when it already exists from Plan Details (mirrors LoginFields pattern)

Notes

• This keeps the existing routing and stepper intact; we only added a new service + schema + form fields.
• The submit handler in PlanDetailsPage for PlanDetailsRegister remains a no-op (navigate back) as this PR focuses on validation. A follow-up could trigger a real registration POST (not just validation).
• Error mapping is resilient: unknown LMS keys fall back to a root error.
• No changes to query keys, loaders, or BFF APIs.

Testability/Local use

• Navigate to /plan-details/register to exercise the schema.
• Try invalid formats or values that LMS rejects (e.g., existing username/email) and observe inline errors sourced from LMS.

Follow-ups (out of scope here)

• Add a real registration submit flow (account creation) and success redirect.
• Debounce per-field server validation (patterned after validateFieldDetailed) if needed.
• Replace the country select with the platform list (or fetch from LMS).

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.