Form

When to use

Form is the container for every form with several fields that is submitted. It checks fields on submit and stops the submit when there are problems.

When not to use

• For settings that apply at once: controls such as Switch do not wait for a submit.
• For search: SearchInput handles its own submit.

Anatomy

Full name* required

Email* required

Send

LightDark

Copy code

import { Button, Form, TextInput, Provider } from '@bigbang/ui';

export default function Default() {
  return (
    <Provider locale="en-GB">
      <Form className="max-w-md">
        <TextInput label="Full name" name="name" required autoComplete="name" />
        <TextInput label="Email" name="email" type="email" required autoComplete="email" />
        <Button type="submit" className="self-start">
          Send
        </Button>
      </Form>
    </Provider>
  );
}

1. Summary: Above the form when a submit stops; a heading and problem links.
2. Fields: With their own error messages.
3. Submit button: type="submit".

Behaviour

• On submit it gathers server errors in errors, fields with aria-invalid and browser constraints (required, type="email", pattern).
• If there are problems, the submit stops, the summary appears and focus moves to it. The summary enters again on every stopped submit.
• A summary link scrolls the field to the centre of the screen and focuses it.
• With schema, the form data is checked as an object (a name used more than once becomes a list). Each issue goes to the field named by its path (joined with dots, such as address.city); a field’s own error wins. An issue without a path appears in the summary as text without a link. Schema issues join native and server problems in the same summary.
• An async schema is awaited; meanwhile the submit button stays focusable but is aria-disabled, the form is aria-busy, and a second submit is ignored.
• Without problems, onSubmit is called with FormData and, with a schema, the schema’s output as the third argument.
• If errors changes after a submit, the summary shows them too.

Guidelines

• Show field errors on the field too (error); the summary is only a guide.
• Write error messages as actions: “Enter an email address”, not “Invalid”.
• Do not disable the submit button; users learn what is missing from the summary.

Content

Turkish	English
Devam etmek için 1 alanı düzeltin	Fix 1 field to continue
Devam etmek için {count} alanı düzeltin	Fix {count} fields to continue

Related components

• Field: Label, description and error.
• TextInput: The most common field.