Homework 3 Reflection

Node

1. How easy was it to reuse your add book request handler logic for your edit handler? What changes did you need to make and why?

My add (POST) book request handler was very similar to my edit (PUT) book request handler and thus it was easy to implement the edit book request handler. Both add and edit books verify the schema of the request body fields, ensures the title is a non-empty string, and verifies the author_id is associated with an author that currently exists. Both return an object with the book information. The one difference between the two is that I added an additional check in the edit book request handler. A 404 is thrown when there is an attempt to edit a book that does not exist (the book id does not exist).

2. What was your experience writing tests for your edit and delete endpoints?

The tests for the edit endpoints were pretty much the same as the add endpoints. In both instances, I tested the endpoints with a valid body, missing required data, invalid author_id, empty title, invalid pub_year, invalid genre, and non-existent book id. This is because both endpoints expect the same request body. The only difference is that we are creating a book for the add endpoints and we are updating an existing book for the edit endpoints.

The tests for the delete endpoints were straightforward. I made two tests: deleting with a valid book id and an invalid book id. There are a lot of different ways for the edit endpoints to fail (and thus there are many tests), but the delete endpoints either work or it doesn't work (based on the book id given).

React

1. How did you integrate the book editing and deletion into your UI? Why did you choose the design you did?

For both the book editing and deletion, I added new columns into the books table UI. The edit column has buttons with pencil icons and the delete column has buttons with trash can icons. These icons are typical representations of editing and deleting. I chose to add new columns to the books table UI to allow users to choose which book they wanted to edit or delete (instead of letting the user fill out information from scratch). When the user selects to edit a book, the update form is filled with the book's current information, allowing the user to easily change only the fields they want to change (and keep the other fields the same). When the user selects to delete a book, all the user needs to do is click confirm (instead of needing to enter the book's id to some input form).

2. What parts, if any, did you struggle with when implementing edit/delete in the UI?

The edit book form UI was straightforward because it's the same components as the add book form UI (with different values, onChange functions, and API call). There isn't any delete form UI (just a confirmation dialog when the user selects the book to delete from the books table).

Initially, I was unsure how to save the book information to each row. While I printed out each book's contents to the table, I wasn't sure if each row maintained the book object (so that the object could be edited or deleted later on). From my understanding, JavaScript closures allows each row to maintain the book object in its local scope. So, when the onClick() functions for the edit and delete buttons on clicked (on a given row), the frontend knows which book object to send to the web server (to edit or delete). Thus, my code works as expected.

Material UI

1. How did you feel about Material UI's API and its look and feel?

It's easy and simplier to use Material UI's API compared to regular HTML. In HTML, if I wanted to create an input field with a label, I would need a input component surrounded by a label component. In Material UI, I only need to define one TextField component (which has a label property). Additionally, it was easy to implement Material UI's Snackbar notifications. I imagine this component would be hard to implement using HTML/CSS/TypeScript and React.

In terms of its look and feel, I find Material UI much nicer compared to plain HTML/CSS/TypeScript. Material UI add animations and modern styling to all of my components. It makes the website more interactive.

2. How easy was it to refactor your existing UI to use Material UI?

It was pretty easy to refactor everything. HTML and Material UI components share many properties, so most of it was just renaming the component from the HTML name to the Material UI name. There were some minor adjustments to make. For instance, Material UI tables are wrapped with TableContainer components (so, there's an additional layer compared to plain HTML tables). But, it was overall easy and straightforward to refactor my UI.

Home