Forms and validation

Choose a form example based on its behavior, not just its appearance. The source includes basic controls, layout examples, validation examples, and a schema-driven form.

Choose a starting point

src/routes/components/forms/BasicControls.tsx and FormLayouts.tsx are useful for ordinary React Bootstrap composition. FormValidation.tsx demonstrates validation presentation.

For a form with several enhanced controls, inspect src/routes/components/forms/FormSchema.tsx. It combines React Hook Form, Zod, and native controls including React Select and Datepicker. Its successful submission displays a normalized payload locally; it does not save that payload to your service.

The Projects create/edit page is a separate practical example in src/routes/apps/projects/ProjectFormPage.tsx. It uses page-local values and validation; do not assume every Totems form is built around the same form library.

Keep the field relationship intact

A usable field includes a label, control, and readable error message. React Bootstrap's Form.Group controlId connects ordinary form controls and labels. Native integrations may need an explicit ID prop.

For React Select, retain inputId, its compatibility classes, and the form controller's value, change, blur, name, and ref connections. An invalid select uses aria-invalid and aria-errormessage linked to the feedback element. Preserve the ref so the form can focus an invalid control.

Do not copy only the visual is-invalid class and drop the actual validation or accessible error relationship.

Decide what gets submitted

Use a schema or explicit validation to define accepted values, then transform them into your API's payload. A select's option object, a JavaScript Date, and a browser File are UI values; they are not automatically the storage format your service expects.

When adapting the schema form, update its defaults, schema, inferred types, and payload normalization together. Keep the reset behavior aligned with the new defaults and clear stale submission feedback when the user starts again.

Add a real submission flow

Replace local success handling with your application request. Validate again on the server, disable duplicate submissions while a save is pending, show actionable errors, and announce success only after the service accepts the change.

Preserve entered values on a recoverable failure. Decide explicitly whether Cancel discards changes and where it returns the user. Avoid using a success toast as evidence of persistence before the request has completed.

File inputs need an upload service and server-side checks. Client-side type and size limits improve the form experience but cannot enforce storage permissions or content safety.

Check the complete form

Try an empty submit, each invalid field, correction followed by resubmission, Reset, Cancel, and a failed save. Navigate using the keyboard and confirm focus reaches invalid fields and returns sensibly after a dialog closes.

For rich text, the Tiptap example's paste cleanup is only one part of handling content. Your application owns server validation, allowed content, stored format, and safe rendering.