1.
It was really easy to reuse the add book request handler to create the edit handler since it used the same bookBodySchema. All I had to do was switch the INSERT to an UPDATE sql query.
2.
The tests were pretty easy. I just had to make sure there is existing data to edit/delete in order to check that the edit/delete worked.
1.
I added edit and delete directly on the table. I had an editing ID state that toggled when the user clicks edit, which changes each cell to input fields. Save calls the patch request to modify the data, and cancel exits edit mode. Delete was a button next to the row that calls the delete book endpoint. I chose this because to be honest I was too lazy to do a lot of refactoring and use a router. I also thought the UI was pretty intuitive.
2.
The hardest part is the edit state and which row was being edited. It was also tricky when I was editing the table's local state, so I refetched books instead.
1.
It was pretty simple to use, everything was a 1:1 with standard HTML tags. It looks pretty nice and smooth as well and now I don't have to do fancy css.
2.
I didn't change everything to material UI, but the table and buttons were pretty easy to refactor into. Theres a material UI equivalent to most HTML tags and it wasn't very difficult, mostly 1:1.