Node / Backend
Reusing add-book logic for edit
Reusing my existing add-book request handler logic for the edit endpoint was fairly straightforward.
Both endpoints require validating similar fields such as title, author_id,
pub_year, and genre, so I was able to reuse most of the Zod validation logic
with minor changes.
The main difference was that the edit endpoint needed to allow partial updates and check that the
book already existed before performing the update.
Instead of inserting a new row, the edit handler builds an SQL UPDATE query dynamically
based on which fields were provided.
Why changes were needed
Unlike creating a book, editing a book requires verifying that the resource already exists and
handling cases where only some fields are updated.
I also needed to ensure that if the author ID was changed, it still referenced a valid author.
These checks helped keep the API RESTful and prevented invalid or inconsistent data from being saved.
Testing edit and delete endpoints
Writing tests for the edit and delete endpoints using Vitest and Axios was very helpful.
Tests made it easy to verify both success cases and error cases, such as updating a non-existent book
or deleting an invalid ID.
One challenge was making sure the database was reset before each test so tests would not interfere
with one another.
Overall, the tests gave me confidence that my endpoints behaved correctly and handled edge cases properly.
React / Frontend
Integrating edit and delete into the UI
I integrated editing and deletion directly into the main books table by adding Edit and Delete buttons
for each row.
Clicking Edit opens a dialog pre-filled with the book’s existing data, while clicking Delete opens
a confirmation dialog before performing the destructive action.
This design keeps all core interactions accessible from the main interface without requiring users
to manually navigate to different routes.
Design decisions
I chose modal dialogs because they provide a clear, focused interaction without navigating away
from the page.
This approach follows common UX best practices, especially for editing forms and destructive actions.
Confirming deletion helps prevent accidental data loss and makes the UI feel safer to use.
Challenges
The most challenging part of the UI was managing form state for editing, especially keeping the
dialog fields in sync with the selected book.
Handling client-side validation and error messages from the backend also required careful state
management.
Once the state was organized clearly, these issues became much easier to manage.
Material UI
Experience with Material UI
I enjoyed working with Material UI overall.
Its component-based API made it easy to build a clean, consistent interface quickly using pre-built
components like tables, dialogs, buttons, and alerts.
The default styling looks polished without requiring much custom CSS.
Refactoring effort
Refactoring my existing UI to use Material UI was easier than expected.
Most changes involved replacing standard HTML elements with Material UI components while keeping
the same logic and state management.
Although Material UI uses Emotion internally, I did not need to interact with it directly, which
kept the refactor simple and focused.
Overall impression
Material UI helped improve both the usability and appearance of my application.
It encouraged better UI structure and made the app feel more professional with relatively little effort.