Reusing my add book request logic for my edit handler was easy to do. The structure was the same, but the way I retrieved a book's properties was different. In add a book, it keeps track of the state of the fields as it is changed, and that is used directly to make the request. In the edit handler, the edited book's properties is passed from my editBookModal to the BookDashboard as the whole book.
My experience writing tests for my edit and delete endpoints was repetitive. Using LLMs to write more repetitive edit tests was very helpful. Otherwise writing the tests was straightforward as I wanted enough coverage to ensure my endpoints were working.
I integrated the book editing and deletion as buttons in another column in my book dashboard table. I choose this design as it makes editing and deletion more intuitive as users can directly see the books they want to edit or remove entirely. This minimizes the amount of separate pages and allows users to see their changes immediately.
When implementing the edit UI, I struggled with creating the edit modal. In particular, I had to figure out what to pass to the modal to work and how to get it to open/close. Additionally, since I did not use <form>, I did not get any free validation and had to figure out Material UI's validation for text fields to enforce simple client-side validation.
Material UI was easy to import and ready to use without any additional integration. I found that the components looked very clean and had predefined styling which resulted in less work on my end to get my components to look presentable. However, I had some challenge in how strict Material UI's component type checking was. I especially had trouble with my optional enum genre type which gave me a lot of trouble. Material UI was easy to import and ready to use without any additional integration. I found that the components looked very clean and had predefined styling which resulted in less work on my end to get my components to look presentable. However, I had some challenge in how strict Material UI's component type checking was. I especially had trouble with my optional enum genre type which gave me a lot of trouble.
It was simple to refactor my existing UI to use Material UI. There were a lot of components where I could map one-to-one, such as the table, tablehead, and tablecell, which made converting my book dashboard table to use Material UI components easy. All I had to do was replace the names, such as from <table> to <Table>.