Node

1. Reusing add book logic for the edit endpoint

Reusing my add book request handler for the edit endpoint was pretty manageable since the validation rules didn't really change. I was already validating the request body with a Zod schema, so I could reuse that directly. The main change was switching from an INSERT to an UPDATE query and adding checks to confirm that the book being edited actually exists. One thing I had to watch out for was accidentally creating new rows instead of updating existing ones, which I initially ran into and then fixed once the tests exposed it.

2. Writing tests for edit and delete endpoints

Writing tests for the edit endpoint was more involved than earlier assignments because there were a lot of edge cases to cover, including invalid IDs, missing or extra fields, invalid publication years, and non-existent authors or books. The delete endpoint and its tests were mostly carried over from Homework 1, so I didn't need to make many changes there. That part was fairly straightforward at the time and worked as expected. Overall, the tests were still useful for catching mistakes in the edit logic and gave me confidence that the endpoints behaved correctly as I iterated.

React

1. Integrating edit and delete into the UI

I integrated editing and deletion directly into the main books table by adding action controls to each row. Editing routes the user to a separate page with a form that's pre-filled with the book's current information, while deletion is handled inline with a confirmation prompt. I chose this approach because it's intuitive and mirrors how similar CRUD interfaces usually work.

2. Challenges with edit/delete UI implementation

The biggest challenge was getting the edit form to pre-fill correctly. Passing the existing book data through routing and syncing it with component state took some trial and error. I also had to make sure the UI updated immediately after an edit or delete so changes were visible without requiring a page refresh.

Material UI

1. Experience using Material UI

Material UI felt slightly overwhelming at first. The API took some getting used to, especially with imports and component composition. Once I adjusted to it, the components made it easier to create a cleaner and more consistent UI without relying heavily on custom CSS.

2. Refactoring the UI to use Material UI

Refactoring my existing UI to use Material UI was doable. I replaced elements gradually and adjusted layouts as needed. While it took some extra time, the end result felt more polished, and the built-in styling and accessibility made the effort worthwhile.