Homework 3 Reflection

• Node
  • Using my GET /book request handler for the edit handler was a very seamless process since the two methods are largely accomplishing the same thing. The main changes I needed to make were extracting the queried Book ID from the request parameters and then providing this value to an UPDATE statement rather than an INSERT statement, since the add book handler used INSERT to create an entirely new record in the DB.
  • I already had tests written for my DELETE endpoints back in Homework 1, which saved me some time on testing for this assignment. As for including the new edit book PUT endpoint tests, I found it to be mostly similar to testing POST requests, but with an existing record being provided to the request handler. For the delete and edit tests, I mainly had to keep track of which books are still in the table so that I can distinguish tests where I'm passing valid vs. invalid IDs. I also had to think about the kinds of response statuses we would typically see from a server for edit and deletion rather than insertion, which helped make my tests more exhaustive. For the most part, the approach was the same, since I knew what kind of JSON structure to expect for a successful request and the kind of error I would need to check for after an invalid request.
• React
  • To integrate the book editing and deletion into the UI, I realized I needed to separate my UI into multiple components across multiple pages. For adding new authors and books, I included separate links to those forms as part of the top navigation bar so that users can easily access them from the main page. This meant that I had more room on the root HTML page to display my "library" of book records in a larger, well-formatted table. I added two additional columns, so that each row had its own edit and delete button. I decided on this UI design because it seems very intuitive. An user would enter the site and they would immediately see both the table and the options to edit/delete any specific record. This is a low-effort action on the user's end as they do not have to manually visit a separate page for a given book record just to press the edit/delete button.
  • One thing I struggled with when implementing edit/delete in the UI is determining what aspects of my add author/book components I should utilize and what requests I would need to make on page render even prior to actually submitting a POST or DELETE request. For editing books, I realized that the edit component would need to first render the existing details for that book, meaning I needed to pass the ID of the book to a specific GET request just to populate the page with information, and then I also needed to request all current authors into a list to properly display their dropdown menu. For the deletion button design, I struggled with having a dialogue popup on the screen to prompt the user to confirm their decision, and how to properly update the state setter that tracked the book being deleted.
• Material UI
  • I found the Material UI API installation very straightforward, and importing all of their CSS components was not complicated either. The API definitely helped me make better use of the whitespace on each page when comparing against the raw HTML result. In terms of look and feel, I found the pages to look much cleaner in terms of presentation. After making the necessary changes, the text boxes and dialogue prompts appeared more modern and easier on the eyes. The buttons were automatically bigger and the components all appeared to have a minimalist aesthetic. However, the only other CSS library I have ever used is Bootstrap from many years ago, so it's hard for me to compare MUI against any specific UI APIs.
  • I would say that refactoring my original code to Material UI was one of the more tedious parts of this assignment. One of the key struggles was not fully understanding what tags would be the appropriate equivalent of the pre-MUI tags that I was using to take in user input, such as 'select' and 'input', as well more general tags for displaying text, such as replacing 'p' and other similar tags with Typography. A lot of this section required going back and forth between the UI rendering and the MUI documentation to ensure things were displaying as expected. For prompting the user for confirmation in the deletion request, I needed to use the MUI documentation to develop the popup, and then more CSS to clean up its appearance. For onChange functions, I consistently faced an error due to using imported MUI tags instead of the regular HTML tags, as the onChange input requires specification of the kind of HTML that data is being received through.