A form is a conversation across the stack

Give each layer a clear job

Consider a fictional project-creation form with a name and a workspace. The browser can help someone fix an empty name immediately. The server must still validate incoming input and check access to the workspace. Database constraints protect the final stored state. These layers support the same workflow, but they solve different problems.

Keep browser feedback useful

Next.js documents native form attributes such as required and type for basic client validation, alongside server-side validation. Start with explicit labels and a sensible submit action. Show an error beside the affected field and preserve the entered values when validation fails. A general alert alone leaves the reader guessing where to act.

Return a result the interface can understand

For the example form, distinguish invalid input from a temporary service failure. The interface needs enough structure to attach feedback to a field or display a form-level recovery action. Avoid returning internal database messages directly to the user.

type CreateProjectResult =
  | { ok: true; projectId: string }
  | { ok: false; fieldErrors: { name?: string };
      message?: string };

Make pending and recovery states explicit

While a request is pending, give the submit button a clear label such as Creating project. Decide whether a second submission should be blocked or recognized as the same intended operation. After failure, leave the form usable and explain whether the user should edit their input or retry. A success message should identify what was created and provide the next action.

Review the entire interaction

Walk through the flow using a keyboard and a slow connection:

• Can every field be reached and understood without placeholder text?
• Does invalid input preserve the user's work?
• Does an unauthorized workspace fail on the server?
• Can someone recover after a timeout?
• Is success visible and announced in the interface?