Review a progressively enhanced address form

Review exercise · TypeScript

Review brief

Intermediate35 min

Checkout already accepts a normal HTML form post and re-renders invalid addresses with field errors and the submitted values. A browser enhancement now submits the same form asynchronously. Review whether enhancement preserves the server contract and recovers from every response class.

Behavioral contract

Without scripting, the form posts normally; a 422 response re-renders field errors and every submitted value, while an accepted address redirects to /checkout/review.
Street is required after trimming. US postal codes are exactly five digits; Canadian postal codes match letter-digit-letter, space, digit-letter-digit, case-insensitively.
Enhanced 422 responses contain kind validation, a field-to-message errors object, and the submitted values; the browser must render those errors without clearing the inputs.
Accepted enhanced responses contain kind accepted and redirectTo /checkout/review.
A transport failure is not a validation failure: show a form-level retry message, retain all values, and re-enable submission.
Pending feedback and the disabled submit control last only for the active request and clear after success, validation failure, or transport failure.
The country control offers only US and CA, and the only application response bodies in scope are the documented validation and accepted variants.

Review instructions

1Trace the form through browser validation, server classification, and each asynchronous outcome.
2Anchor findings to the narrowest useful line and explain the checkout impact.
3Prioritize no more than five findings and recommend a direction rather than replacement code.

Learning objectives

• Preserve baseline behavior when adding client enhancement
• Keep browser and server validation aligned
• Recover cleanly from validation and transport failures

src/shipping-address-api.tsTypeScript

@@ -0,0 +1,32 @@

1+export interface AddressValues {

2+ street: string;

3+ country: "US" | "CA";

4+ postalCode: string;

5+}

6+

7+export type AddressErrors = Partial<Record<keyof AddressValues, string>>;

8+

9+export type AddressApiResponse =

10+ | { kind: "validation"; errors: AddressErrors; values: AddressValues }

11+ | { kind: "accepted"; redirectTo: "/checkout/review" };

12+

13+const US_POSTAL_CODE = /^\d{5}$/;

14+const CA_POSTAL_CODE = /^[A-Z]\d[A-Z] \d[A-Z]\d$/i;

15+

16+export function validateShippingAddress(values: AddressValues): AddressErrors {

17+ const errors: AddressErrors = {};

18+

19+ if (!values.street.trim()) {

20+ errors.street = "Enter a street address.";

21+ }

22+

23+ const validPostalCode =

24+ values.country === "US"

25+ ? US_POSTAL_CODE.test(values.postalCode)

26+ : CA_POSTAL_CODE.test(values.postalCode);

27+ if (!validPostalCode) {

28+ errors.postalCode = `Enter a valid ${values.country} postal code.`;

29+ }

30+

31+ return errors;

32+}

Reference solution

Findings are ordered by priority.

Findings

1. The form clears the shopper's address before the outcome is known

Location: src/enhance-shipping-address-form.ts:58-63

The handler resets every control to its server-rendered default immediately after entering the pending state. The request body was captured, but the shopper's current values are gone before the server can classify the submission. A validation response or transport failure therefore forces the shopper to re-enter a complete address.

Keep the controls populated through all recoverable outcomes. Clear them only when an accepted response is about to navigate away, if clearing is useful at all.

2. Server field errors are discarded instead of rendered

Location: src/enhance-shipping-address-form.ts:63-67

The validation payload includes field-specific errors and the submitted values, but this branch uses neither. It shows only a generic form message, so the enhanced flow does not tell the shopper which fields the server rejected and cannot restore the values that were cleared.

Render the returned field errors through the existing field outputs and retain or restore the returned values, matching the non-scripted 422 behavior.

3. Validation and transport failures leave the form permanently pending

Location: src/enhance-shipping-address-form.ts:58-74

setPending(false) runs only in the accepted branch. Both the validation return and the catch path leave aria-busy set and the submit button disabled, so the shopper cannot correct or retry the form after a recoverable failure.

Clear pending state in a finally block or in every terminal branch, while ensuring it still spans the active request.

4. Browser postal-code validation disagrees with the server rules

Location: src/enhance-shipping-address-form.ts:9-15 and src/shipping-address-api.ts:13-28

The browser accepts any 4-to-10-character mixture of letters, digits, spaces, and hyphens without considering country. It therefore accepts values the server must reject, such as a four-digit US code or a Canadian code without the required shape, creating avoidable 422 responses after client validation passed.

Share the country-specific rules or generate the browser constraints from the same policy as the server. The client may be less exhaustive, but it must not claim incompatible values are valid.

5. A network failure is reported as a street validation error

Location: src/enhance-shipping-address-form.ts:72-74

The catch path places "We could not validate this address" on the street field. A connection failure says nothing about whether the street is valid, so the message misdirects the shopper and hides that retrying the same values may succeed.

Use the form-level status region for a transport-specific retry message and do not attach a field error without a validation response.

Reasonable non-findings

Calling preventDefault inside the installed enhancement does not break the no-script baseline; without the script, the browser still performs the form's normal post.
Capturing FormData before reset() preserves the outbound request body. The defect is losing the shopper's visible values on recoverable outcomes.
The browser and server agree that a whitespace-only street is invalid.
Clearing pending state before navigating on an accepted response is harmless and gives deterministic state if navigation is intercepted in a test.
The returned cleanup correctly removes the submit listener.