Frontend form validation does not match backend validation — sync error messages and rules

[Just-Bamford]

Summary

The frontend has form validation on ballot creation, voter upload,
and vote submission pages, but the validation rules and error messages
do not match what the backend enforces. A voter can submit a form that
passes frontend validation but fails at the backend with an unclear
error, leaving them confused about what went wrong. Frontend validation
should mirror backend validation exactly so users get consistent,
actionable feedback.

Background

For example, the vote submission form may accept a token of any length
on the frontend, but the backend requires exactly 32 bytes (64 hex
characters). A voter enters an incorrect token, sees no frontend error,
submits, and gets a cryptic backend error. The error messages are also
inconsistent — frontend says "Token invalid" but backend says "Invalid
token format".

Scope

Frontend

• Audit all form validation in:
  • Ballot creation form (POST /api/ballots)
  • Voter list upload (POST /api/eligibility)
  • Vote submission form (POST /api/votes)
  • Token input field
• Compare each form's validation rules against the corresponding
  backend endpoint's validation in backend/src/middleware/validate.ts
• Update frontend validation to match backend exactly:
  • Token must be 64 hex characters (32 bytes)
  • Ballot title must be 3-200 characters
  • Deadline must be in the future
  • Vote option must be a valid option from the ballot
  • Voter email must be a valid email format
• Sync error messages between frontend and backend:
  • If backend returns error code INVALID_TOKEN, frontend should
    show the exact same message: "Token must be 64 hex characters"
  • If backend returns BALLOT_CLOSED, frontend should show
    "Voting for this ballot has closed"
• Add a validation utilities file frontend/src/utils/validate.ts
  that exports validation functions and error messages imported
  from a shared constants file

Backend

• Create backend/src/constants/validationMessages.ts that exports
  all validation error messages as constants
• Export validation functions that the frontend can reuse

Tests

• Test each form field with:
  • Valid input (passes)
  • Invalid input (fails with correct error message)
  • Boundary cases (min/max length, edge values)
• Verify frontend error message matches backend error message exactly

Relevant Files

• frontend/src/components/BallotForm.tsx
• frontend/src/components/VoterUploadForm.tsx
• frontend/src/pages/VoteForm.tsx
• frontend/src/utils/validate.ts (new)
• backend/src/middleware/validate.ts
• backend/src/constants/validationMessages.ts (new)
• frontend/src/tests/forms.test.ts

Acceptance Criteria

• Frontend validation matches backend validation for all fields
• Error messages match between frontend and backend exactly
• Shared validation constants exported from backend
• All form field tests pass (valid, invalid, boundary cases)
• A user entering invalid data sees the same error message on
  frontend and backend
• No TypeScript warnings
• All tests pass

Out of Scope

• Real-time validation as user types — validation on submit only
• Backend response error message changes — frontend adapts to current backend

Note for Contributors

This is about consistency and user experience. When a frontend shows
"Invalid token format" and the user submits anyway and gets a different
error from the backend, trust is broken. Make them match exactly. The
frontend should catch as many errors as possible so the user knows
immediately what to fix.

[pgreat123]

I'm a full-stack developer contributing to AnonVote's codebase. Frontend/backend validation drift breaks trust — a voter who passes frontend checks then hits a cryptic backend error doesn't know what went wrong.

My approach: I'll read backend/src/middleware/validate.ts as the source of truth (token = 64 hex chars, title 3-200 chars, deadline in future, valid option, email format). I'll move messages and validation functions into backend/src/constants/validationMessages.ts. I'll audit BallotForm.tsx, VoterUploadForm.tsx, VoteForm.tsx, and the token field against that source, then build frontend/src/utils/validate.ts importing the shared constants directly — no re-implementing rules, so messages can't drift again. I'll map error codes (INVALID_TOKEN, BALLOT_CLOSED, etc.) to exact backend message text.

For tests, I'll cover valid/invalid/boundary cases per field, plus explicit checks that frontend and backend error messages match exactly. In scope: submit-time validation only, no real-time checks, no backend message rewording.

I can submit within 4 days.

[grantfox-oss]

🦊 GrantFox — @pgreat123 has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #39)
2. Your PR will be reviewed by the AnonVote maintainers

Good luck! Track your progress on GrantFox.