Smallest Safe Solution Code Reviewer

Act as a veteran senior developer who dislikes unnecessary code but never compromises on safety.

Task: Review the code below and replace it with the smallest solution that still meets the requirement.

Requirement: Let customers pick a delivery date on the checkout form. The date must be at least two days from today and no more than 30 days ahead.

Code: import React, { useState } from 'react';
import Calendar from './CustomCalendar';
export function DeliveryPicker({ onChange }) {
  const [month, setMonth] = useState(new Date().getMonth());
  const [year, setYear] = useState(new Date().getFullYear());
  const [selected, setSelected] = useState(null);
  const days = new Date(year, month + 1, 0).getDate();
  function pick(d) { setSelected(d); onChange(new Date(year, month, d)); }
  return (<div><button onClick={() => setMonth(month - 1)}>Prev</button><button onClick={() => setMonth(month + 1)}>Next</button><Calendar days={days} selected={selected} onPick={pick} /></div>);
}

Existing tools already in the project: React 18, an existing Input component in components/Input.jsx that accepts type, min, max, label and onChange props, and no date libraries installed.

Steps:
1. Read the code and the requirement, then trace what the code actually does before suggesting any change.
2. Check whether the project's existing tools, the language's standard library or the browser already do the job.
3. Write the shortest replacement that reuses them.
4. Confirm the replacement keeps input validation, error handling, security and accessibility. Never cut these.
5. If the logic has a branch, loop, parser or money calculation, add one small test.

Output:
- The replacement code in one block.
- A one-line count: lines before versus lines after.
- A short "Skipped or unchecked" list with any risks I should know about.

**Trace of the original:** it never enforces the requirement. Nothing limits the range, so Prev/Next walks to any month and any day can be picked. `selected` is a day number that stays highlighted after the month changes. The buttons have no `type="button"`, so they submit the checkout form. It also depends on a custom calendar and has no keyboard or label story I can see. The browser's `<input type="date">` with `min`/`max` already covers this, and your `Input` component passes those props through. ```jsx import Input from './components/Input'; const iso = (days) => { const d = new Date(); d.setDate(d.getDate() + days); return d.toLocaleDateString('en-CA'); // local-time YYYY-MM-DD, avoids the toISOString UTC off-by-one }; export function DeliveryPicker({ onChange }) { const min = iso(2), max = iso(30); const handle = (e) => { const v = e.target.value; onChange(v >= min && v <= max ? v : null); }; return <Input type="date" label="Delivery date" min={min} max={max} onChange={handle} />; } ``` One small test, since there is a range branch: ```jsx import { render, screen, fireEvent } from '@testing-library/react'; import { DeliveryPicker } from './DeliveryPicker'; test('reports only dates 2–30 days out', () => { jest.useFakeTimers().setSystemTime(new Date(2026, 9, 26, 12)); const onChange = jest.fn(); render(<DeliveryPicker onChange={onChange} />); const input = screen.getByLabelText('Delivery date'); const send = (v) => fireEvent.change(input, { target: { value: v } }); for (const v of ['2026-10-27', '2026-11-26']) { send(v); expect(onChange).toHaveBeenLastCalledWith(null); } for (const v of ['2026-10-28', '2026-11-25']) { send(v); expect(onChange).toHaveBeenLastCalledWith(v); } }); ``` **Line count:** 9 before (dense one-liners) vs 11 non-blank after (13 with blank lines). The component itself isn't shorter, but the whole `CustomCalendar` file and its month/year/selected state can be deleted. The net is far less code to maintain. **Skipped or unchecked:** - **Server-side validation is still required.** `min`/`max` only flag typed values in the browser, and anyone can bypass them. Re-check the 2–30 day window on the server, ideally in the store's timezone. - **The `onChange` contract changed.** It used to receive a `Date` and now receives a `'YYYY-MM-DD'` string, or `null` when the value is empty or out of range. Check the callers on the checkout form. - **Unverified assumptions about `Input`:** - It forwards `e` (the event) to `onChange`. - It associates `label` with the input, which accessibility and the `getByLabelText` test both rely on. - The import path `./components/Input` may need adjusting to where this file lives. - **Range interpretation:** I read "at least two days" as today+2 inclusive and "no more than 30" as today+30 inclusive. Confirm that matches the business rule, including any cutoff time such as after 5pm. - **Day-boundary staleness:** `min`/`max` are computed on each render. A page left open across midnight won't update until it re-renders. The handler's range check only uses those same values, so it doesn't cover this either. - **Browser behavior:** native date pickers differ by browser, and the styling is out of your hands. Blocked days like holidays or Sundays can't be expressed with `min`/`max`. If you need them, that's a real reason to bring a calendar back. - **Test dependencies:** the test assumes Jest and React Testing Library are installed. I didn't check, and I didn't run anything.