`useForm`: support client-side validation (or at least `setError`)
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 54/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- typescript
- Domain
- frontend
Research direction
Start by locating the useForm implementation and its tests in the @void/react package; the issue does not name specific files. Trace how errors, clearErrors, and setData are handled, then check how server validation maps errors into the form. Done means the chosen proposal works through form.errors and has tests for setting errors and, if implemented, clearing them on change.
Written by the indexing model from the issue text.
Description
Version
void / @void/react 1.1.12
Problem
useForm only fills errors from the server's withValidator() response. There's no way to validate in the browser and show errors through the same errors object:
- there's no
setError/setErrors, onlyclearErrors, - the Zod schema already used in
withValidator()can be run on the client by hand, but its results can't be wired intoform.errors, - errors don't clear when a field changes, so each
onChangeneeds its ownclearErrors(field)call.
As a result, apps that want inline validation as the user types either keep a second error state next to form.errors, or switch to another form library and lose useForm's typed action URL, pending and server error mapping.
Proposal
Any of these, from smallest to largest:
setError(field, message): lets apps run their own validation and show the result throughform.errors.- An option to clear a field's error on change, e.g.
clearErrorsOnChange: true, sosetData(field, …)also clearserrors[field]. - Optional client-side validation with the action's schema, e.g.
useForm(url, defaults, { validate: createNoteSchema, validateOn: 'blur' | 'change' }). That would give the same messages in the browser and on the server, from one schema.
(1) and (2) are small and unblock building (3) in userland.
Related: #523, #524
- Dominant language
- TypeScript
- Stars
- 402
- Forks
- 32
- Avg merge
- 10h 18m
- Merged PRs (30d)
- 113
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from voidzero-dev/void
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
voidzero-dev/void#529 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 1/5 1-3 hours Newbie friendliness 78/100
voidzero-dev/void#428 ·
Maintainers usually reply within 1 day
-
Auth config regeneration in dev can reuse a cached configPossibly taken @Brooooooklyn claimed this today. Open
Difficulty 4/5 3-5 days Newbie friendliness 35/100
voidzero-dev/void#550 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 46/100
voidzero-dev/void#547 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 38/100
voidzero-dev/void#546 ·
Maintainers usually reply within 1 day
All issues in voidzero-dev/void
Similar issues
-
area:agent-view area:tui bug platform:macos
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
anthropics/claude-code#104558 ·
Maintainers usually reply within 1 day
-
updater
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
UniversityOfHelsinkiCS/oodikone#5141 ·
-
maintanance
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
inmanta/web-console#7606 ·
Maintainers usually reply within 1 day
-
bug skills
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
equinor/fusion-framework#5846 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 74/100