It was pretty easy to reuse my validation logic and make the necessary changes. I used the same bookBodySchema and safeParse, and the only big change was the SQL query itself where I do UPDATE instead of INSERT INTO. The validation of the data is pretty much the same, but the operation differs. I also had to check if result is undefined when a user tries to edit a book ID that doesn't exist, which wouldn't apply for the POST requests I wrote.
Fairly straightforward since they followed the same pattern as my POST tests. I wrote happy path tests first to verify the database updated and then tested edge cases with PUT/DELETE on a non-existent book ID. I told myself I would do TDD this time around, but I was lazy and wrote the endpoints first. I added tests for editing that ensured that invalid data such as an empty title or non-existent author_id would be rejected with a 400 error, similar to my POST tests.
I chose an in-line editing design where the row transforms into text fields and dropdowns when they click the edit icon. I chose this to allow the user to modify the data without needing to go to a new page or requiring additional context. For deletion, I have a confirmation dialog pop up when the user clicks the delete icon to prevent accidental deletions. The assignment said explicitly that destructive operations should prompt the user for confirmation before they’re performed. I also did some basic UI/UX research with online resources, such as this article.
I had issues with function signatures, in particular passing my edit function to the onClick handler. Originally I was doing onClick={saveEdit} which caused React to pass the mouse event object instead of the bookID, causing API calls to undefined. I fixed this by refactoring saveEdit to use the editingID state variable instead of passing it as a parameter. Most of the other issues were small bugs so it was fairly smooth overall.
The API was cool, but it's very verbose with a ton of different components I had to read up on and learn how to use such as TableContainer, TableHead, TableRow, etc. The look and feel of it was excellent out of the box however; the input fields had nice focus animations, the icons were sleek, and the overall design was much more modern and professional than I had thought. I can see myself using it for future projects to polish the look and feel quickly rather than wasting time writing CSS.
It was easy but incredibly repetitive and tedious. The logic itself wasn't difficult, but I had to replace all the standard HTML tags like <h1> or <tr> with their MUI equivalent such as <Typography> or <TableRow>. I also had to swap standard <input> elements for MUI components like <TextField> and <Select> and utilize <Container> to ensure that the styling stayed consistent with my old design and looked good.