Validate the Entry Before Sending It

Open client/src/components/EntryForm.jsx.

The starter prevents some invalid submissions, but it does so silently. A silent return forces the learner to guess why clicking add appeared to do nothing.

Replace the silent guard with explicit checks that explain the first problem found:

const amount = Number(form.amount);

if (!form.date) {
  setError("Date is required.");
  return;
}

if (!form.description.trim()) {
  setError("Description is required.");
  return;
}

if (!Number.isFinite(amount) || amount <= 0) {
  setError("Amount must be greater than zero.");
  return;
}

if (form.type === "expense" && !form.category) {
  setError("Choose a category for this expense.");
  return;
}

Each branch does three things:

1. Detects one invalid condition.
2. Writes a message into error so the user can see what to fix.
3. Returns before addTransaction() can send the invalid data.

Clear old errors once validation has passed:

setError(null);

Keep server failures separate from form validation:

try {
  await addTransaction(entry);
} catch (err) {
  setError(err.message || "Couldn't save that entry");
}

A validation error means the form has not been sent. A caught API error means the request was attempted but something outside the form failed. Keeping the two cases separate makes the UI message useful.

Do not add the final real-calendar-date validator or integer-cent parser here. Those rules are deliberately introduced later, when the application has reusable finance helpers and a matching server data model.

Test it

Try these values one at a time:

empty description
empty amount
0
-10
expense with no category
valid expense
valid income

Invalid entries should stay on the form and show a specific message. Valid entries should continue into the API workflow.

Checkpoint

The learner can tell exactly why an invalid form submission is blocked, and invalid input does not reach the create request.