Add PUT /users/:id endpoint to update a user

[kfhawas]

What

Adds PUT /users/:id to update an existing user's name and email.

• db/store.js — new updateUser(id, { name, email }) helper. Reuses getUserById and returns undefined for an unknown id, mirroring how getUserById already signals "not found".
• routes/users.js — new PUT /:id route. Validates that name and email are present (400 otherwise, same response shape as POST /users), then returns 404 if the store reports no such user, else 200 with the updated user.

Behavior notes

• Validation runs before the not-found check, so a request that is both malformed and for an unknown id returns 400, not 404. This matches the existing POST /users style rather than inventing a new convention for this route.
• Only name and email are destructured from the body, so a client cannot overwrite id through the request payload.
• Non-numeric ids are safe: Number("abc") is NaN, which never matches a real id, so the request falls through to 404.

Testing

npm test — 9/9 passing, including the three cases for this endpoint (successful update, 404 for unknown id, 400 for a missing field).

Commits

• Add PUT /users/:id endpoint to update a user — the feature (store helper + route together, since the route is broken without the helper).
• Add NOTES.md write-up deliverable — the task write-up, kept separate from the endpoint logic.

🤖 Generated with Claude Code

[mateacademy-ai-mentor]

Review Summary

I am approving your solution. The PUT /users/:id endpoint correctly validates name and email, returns 404 for unknown users, and responds with the updated user on success, matching the existing patterns. The db/store.js updateUser helper reuses getUserById, updates only allowed fields, and returns undefined when the user is not found, aligning with the repository’s conventions. NOTES.md is clear and covers the plan, model choice, commit rationale, and review findings.

Minor suggestions (non-blocking):

• Consider trimming inputs and optionally adding basic email format checks to prevent accepting whitespace-only or malformed emails.
• For clarity, you could explicitly handle non-numeric :id (e.g., isNaN) before lookup and decide whether to return 400 or 404 per your API conventions.

Overall, well done—clean, consistent, and aligned with the requirements.

---

✨ Please rate this review in the Platform's notification center¹. I will be grateful for your feedback! ✨

Footnotes

1. Rate AI review example ↩