CS 478 HW 3: Reflection

It was rather easy for me to reuse my add book request handler logic for the edit handler. Since both handlers needed to validate similar data structures. I changed the SQL query from an INSERT statement to an UPDATE statement instead to edit a book. I ran into an issue where my reused Zod schema required an id field in the request body. Initially, my Edit logic only passed the id in the URL parameters. I had to adjust my frontend to send the id in the JSON body as well so the validation wouldn't fail.

I found that writing the tests for editing and deleting endpoints was pretty straightforward since I followed my previous test logic. I used vitest and axios which helped verify that my API correctly handled the edge cases. For the edit endpoint, I tested scenarios such as editing a non-existent book, providing invalid data types, and successfully updating a book's details. For the delete endpoint, I ensured that deleting data with dependencies (like authors with books) was handled correctly and that a successful deletion removed the book from the database. The tests gave me confidence that my endpoints handled various situations correctly.

chose to add the Delete and Edit buttons directly into the table for quick user access. However, clicking the Edit button navigates to a dedicated page rather than editing inside the table. I made this decision because the book entity has multiple fields (Title, Author, Year, Genre), and trying to fit input fields inside a single table row would have made the UI cramped and overwhelming. Using a dedicated page also allowed me to efficiently reuse the clean form layout I had already designed for the 'Add Book' feature.

I initially struggled with the syntax for the Edit button. I ended up wrapping the button in a React Router Link since it is the cleanest way to handle navigation without needing complex event handlers. I ensuredthat when a user deleted a book, the UI updated immediately without needing a page refresh. I achieved this by filtering the local state array after the API confirmed the deletion.

I feel that the look and feel of Material UI is very modern and clean. The components like AppBar, Paper and Button gave the a cohesive appearance and little CSS was needed to make additional changes. However, I found the API to be somewhat strict. Material UI relies heavily on specific props (like variant, sx, and elevation) and correct imports. While this structure ensures consistency, I had to specifically ensure that I was using the correct properties for each component.

Refactoring was more challenging than I expected, largely due to versioning issues. Swapping simple components like buttons and text fields was straightforward, I struggled significantly with the layout components. I encountered errors with the Grid components because I was inadvertently mixing syntax from Material UI v5 and v6. To resolve this without getting stuck figuring out this versioning issue, I refactored my forms to use Stack and Box components instead. This actually turned out to be a better solution, as Stack handled the vertical spacing of my form fields much more naturally than manually configuring grid rows and columns.