I changed the book GET sql statement to return the books sorted by alphabetical by default. I believed this would be easiest to have a default sort already done by the server. Any additional custom sorting can be done by the client. I also followed the activity examples and refactored the types into it's own file called type.ts. If I go back in time and could change my HW1, I would have liked to put in a bit more effort into thinking about if there was an sort order when returning books/author.
When adding books and authors, I used both server-side validation and client-side validation. I let the server enforce the conditions of the fields such as year cannot exceed this year. However, I use client-side validation for ensuring users fill out required fields for a better user experience. Pros of server-side validation is that it is the true source of the validation logic so it can be trusted but the validation could be slow since the user needs to submit the request before finding out. Meanwhile, client-side validation is more instant and allows the user to catch errors before sending a back request to the server. Conversely, client-side validation cannot validate everything and has to match server-side validation. In my case, using both ensures that there are less bad requests being sent to the server and the server can still enforce the field conditions as the source of truth.
My general experience using React so far has been good! I like the component usability aspect, where UI can be broken into pieces. I also feel like there is less logic I have to constantly rewrite or the code to do the same logic is way less. However, I do still struggle with understanding state management. I find it a bit difficult to follow the flow in the code when state triggers some code logic which then triggers a re-render.
Writing plain JS DOM manipulation code is less intuitive. For example, creating a table requires manually making the element, then appending the rows and cells. With React, I am able to write out what the table should look like. Additionally, state management using JS DOM got complex very fast as I had to add many event listeners. React on the other hand can update the UI automatically. In my personal experience, I found writing JS DOM code very grueling as you have to do everything manually resulting in much more code written to achieve a simple button press. In React, writing the code for a button press was significantly less code and less complex. I prefer React as components can be easily created and reused. This reduces the amount of code duplication and allows for more readable code.
I had a bit of struggle writing types on the frontend especially when the input was not text. For example, I was a bit confused initially as to why I was having a type error when trying to assign the pub_year which I typed as a number to text input. I realized that TS was just enforcing the type. I did catch one bug! The genre field is optional, but my genre state did not have a null type. Therefore I was not able to create a book with no genre as TS enforced types. I still am figuring typing, and trying to understand what is best practice for typing. I think typing is tedious but good at enforcing rules.
I used LLMs to help create the initial div layout hierarchy for the form, writing css, write a basic eslint config, and explaining some typing issues. I typically find that LLMs are helpful in troubleshooting configuration errors and creating skeleton code to work with.
LLMs makes the process of coding less tedious. For example, I often run into configuration problems but LLMs are pretty good at trouble shooting simple issues tailored to your situation. I also find adding basic CSS sometimes to be a pain as there are so many options so using a LLM creating basic css gives me a template to start with. Then I can easily adjust to my taste. I don’t think LLMs took away from my learning experience much for this assignment, but I realize I might not learn as much about configuration issues as I rely on LLMs a lot to help me solve them.