Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

`useForm`: support client-side validation (or at least `setError`)

Ouverte
  • Quelque chose ne va pas ?
#525 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@0froq y travaille déjà.

Depuis le 25/10/2026.

  • #4 par @0froq — ouverte

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
54/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
typescript
Domaine
frontend

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

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, only clearErrors,
  • the Zod schema already used in withValidator() can be run on the client by hand, but its results can't be wired into form.errors,
  • errors don't clear when a field changes, so each onChange needs its own clearErrors(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:

  1. setError(field, message): lets apps run their own validation and show the result through form.errors.
  2. An option to clear a field's error on change, e.g. clearErrorsOnChange: true, so setData(field, …) also clears errors[field].
  3. 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

Langage dominant
TypeScript
Étoiles
580
Forks
56
Merge moyen
8 h 36 min
PR mergées (30 j)
110

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de voidzero-dev/void

Toutes les issues de voidzero-dev/void

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.