I had already implemented PUT request handlers previously, so reusing that logic to modify, edit, and delete records was straightforward. However, I had to refactor the code to make the functions more modular. This was necessary to ensure I could properly test updating a single value independently of others without side effects.
Writing tests for the edit and delete endpoints was tedious and repetitive. I found myself writing the same test logic across different classes to ensure every entity was updating correctly. Despite the repetitive nature, it was valuable because I did uncover actual errors in my logic during the process.
I integrated Material UI directly, initially believing it was a strict requirement (though I later realized it wasn't). I utilized the recommended editing flow for Data Grids in Material UI: I included an specific "Edit" mode that users must enter to modify rows. I chose this design to prevent accidental data loss—users have to intentionally click to edit and then save their changes.
Editing the author name was a massive struggle because of the foreign key relationship. Since the author data lives in a separate table, I had to ensure that editing a book allowed the user to choose a different author, rather than accidentally renaming the author itself (which would affect other books). Connecting the Book table to the Author table in a way that preserved the ID integrity was the hardest part of the UI implementation.
The look and feel is very modern and polished out of the box, which is a significant upgrade from standard HTML tables.
Refactoring the existing UI to use Material UI was surprisingly easy—until I got to the interactive parts. Including the editing and deleting of rows directly inside the table structure added a layer of complexity that was much harder than just displaying static data.