Homework 3 Reflection

Node

Reusing the code was pretty simple, if you mean copy and paste. I need to break down both my creation and book management forms into smaller components and move them to a utilities folder. That will probably happen during my next iteration before doing homework 4. Structurally, the pages were very similar. However, I couldn't reuse the form that I made for the book creation; I wanted to support partial updates without explicit field filling, so I made fields optional for the edit page. I am now (at 9PM) building an idea in my head to support direct write-in fields for the PUT request. That is, the user requests for a Book ID and they get back a form that has all the fields pre-filled. That way, they know what the value of certain things are before they edit them, and they don't have to switch between views to determine that.

I didn't write any "new" tests for the delete endpoint when I wrote it because it was included in the first assignment (I think). When I did it, it was fine, since I wrote tests that would really only occur if the primary way of interacting with the server was the frontend client that I designed. I wrote the tests for the PUT (edit) endpoint first because I wanted to write my code according to the expectations of the use cases that I came up with. It was pleasant.

React

Book editing and Deletion are in a tab called "Manage Book Entry". Both deletion and editing are "managing" a book's state, so I thought it made sense to put them in the same tab. I used the same forms as the book creation because it gave consistency across the screens that were available for book operations.

There were no React-related issues with implementing the Edit/Delete in the UI. All the issues I encountered were with Material UI.

Material UI

I think that Material UI is nice and simple. If you are creating a functional app that isn't customer-facing, but rather something that is used internally as a tool to do something, it handles a lot of the heavy-lifting for you and has exceptional clarity. For something customer facing, it's an exhausted and tired set of UI elements that would make your product look bland against the other several thousand Material UI websites on the internet.

It was somewhat easy to refactor my existing UI to use Material UI. The documentation is pretty good, the live code sandboxes are useful, and there's a lot of code snippets online that show you how to produce most kinds of website behavior. The biggest hurdle that took me several hours (ALL FOR NOTHING!) was the table. I should've just left it as a table initially instead of trying to make Material UI's DataGrid work. I wanted to use the live edit and delete buttons mounted to the table instead of creating different pages for the UI. But I couldn't (and still can't) figure out what higher-level parent container was dictating the width of my DataGrid. After I decided to abandon the idea, I simply refactored my raw HTML to use the MUI Table component following their documentation.