I was able to reuse most of the add-book logic (validation, parsing request body, and preparing parameterized SQL) when implementing the edit handler. The main changes were switching the SQL from INSERT to UPDATE, adding an identifier (book id) as a required parameter (from the URL or body), and handling the case where the id doesn't exist (return 404).
Writing tests was straightforward. I used integration tests that seed the DB with a known state, then exercised the edit and delete endpoints with HTTP requests. For edit tests I checked, successful update returns updated record, missing/invalid id returns 404/400, and validation errors return 400. For delete tests I checked successful delete removes the record, repeated delete returns 404 or a safe response, and that related constraints (if any) are enforced.
I added edit and delete actions to each row of the book list as small icon buttons (Edit and Delete). Clicking Edit opens a form pre-filled with the book's data (the modal); on submit we call the edit API and refresh or update local state. Delete shows a confirmation dialog before calling the delete API and then removes the item from the list. I chose this design because it keeps the list compact, easy to find, and minimizes navigation, edits happen in-place it's cleaner.
The tricky parts were controlled form state and keeping the table state consistent after updates/deletes. Managing form inputs (prefill, reset on close, validation messages).
I enjoyed using Material UI's API as I've used this during a co-op before so I had small experience with it. It was quite fun and enjoyable so the feel working with this was great.
Refactoring to Material UI was relatively straightforward due to its documentation and component library. I was able to replace existing components with Material UI equivalents with minimal changes to the overall layout and styling. The main effort was in adapting to things like spacing and alignment.