frontend-forms

Frontend Forms & Error Display

Thesis: Display page-load errors in Switch/Match states, submission errors via toast, and field-level errors inline. Keep user-visible submit state batched with its success or error branch.

Error Display Decision Tree

• API call fails during page load → Switch/Match error state with <Alert> component
• API call fails during form submit → toast.error() with message
• Field-level validation errors from backend → inline error messages under each input
• Network/auth errors → handled by api.ts automatically (401 refresh, etc.)

Form Submission Pattern

Uses batch() in both try and catch; do not put user-visible submit state in finally.

const [saving, setSaving] = createSignal(false);
const [fieldErrors, setFieldErrors] = createSignal<Record<string, string>>({});

const handleSubmit = async () => {
  setSaving(true);
  setFieldErrors({});
  try {
    await api.create(formData);
    if (!alive) return;
    batch(() => {
      setSaving(false);
      toast.success("Created successfully");
    });
    onClose(); // or refetch
  } catch (err) {
    if (!alive) return;
    const apiErr = err as {
      message?: string;
      details?: Record<string, string>;
    };
    batch(() => {
      setSaving(false);
      if (apiErr.details) {
        setFieldErrors(apiErr.details);
      } else {
        toast.error(getErrorMessage(err, "Failed to create"));
      }
    });
  }
  // setSaving(false) is in both branches, wrapped in batch()
};

Why No finally

// BAD — finally runs unbatched after catch, creating intermediate visible state
try { ... }
catch { batch(() => { setError(msg); setSaving(false); }); }
finally { setSaving(false); } // runs AFTER catch, unbatched — error + saving both true briefly

// GOOD — setSaving(false) inside both branches, always in batch()
try {
  if (!alive) return;
  batch(() => { setSaving(false); toast.success("Done"); });
} catch {
  if (!alive) return;
  batch(() => { setSaving(false); toast.error("Failed"); });
}