diff options
Diffstat (limited to '_posts')
| -rw-r--r-- | _posts/2023-05-29-weekly-essay-5.md | 350 |
1 files changed, 350 insertions, 0 deletions
diff --git a/_posts/2023-05-29-weekly-essay-5.md b/_posts/2023-05-29-weekly-essay-5.md new file mode 100644 index 0000000..1a8aee3 --- /dev/null +++ b/_posts/2023-05-29-weekly-essay-5.md @@ -0,0 +1,350 @@ +--- +title: To-Do App +categories: [Weekly Essay] +tags: [] +# math: true +--- + +After a long time since the last post, we're back! Let's try to explain our +latest project: _A To-Do App_. + +You can see the complete code on my personal Git page or in my GitHub account. + +| Personal Git Page | GitHub | +| :------------------------------------------------: | :--------------------------------------------------------: | +| [Front End](https://cgit.hisiste.com/ToDo-App-FE/) | [Front End](https://github.com/Hisiste/ToDo-App-Front-End) | +| [Back End](https://cgit.hisiste.com/ToDo-App-BE/) | [Back End](https://github.com/Hisiste/ToDo-App-Back-End) | + +## Goals and Requirements + +As the name implies, this project is about creating and managing to-dos. We have +the following functional requirements for this app: + +- [x] Create a "to-do" specifying the name, a priority, and possibly a due + date. +- [x] Ability to edit name, priority and due date for existing "to-do" tasks. + - Being able to specify a due date or clear the due date (because you may + not be interested in when to finish that "to-do"). +- [x] Being able to filter "to-dos" specifying the name (or part of the name), + the priority and if they are done/undone. +- [x] Being able to sort the "to-do’s" by priority and/or due date. + - For example, be able to sort items where their due date is soon and sort + them also by priority to see what tasks are more urgent or less urgent. +- [x] Mark "to-do’s" as done (clicking in a checkbox) or to undo a "to-do". + - The undone functionality is just there if there is a mistake. :D +- [x] Since it is possible that you can have a lot of "to-dos" there's the + need to paginate the list of "to-dos". +- [x] Ability to know, in average, the time between creation and done for all + "to-dos". This should be shown in general for all done "to-dos" and + also grouped by priority. + - This could be a metric to measure performance. + +The project was separated into two projects: The _Front End_ part and the _Back +End_ part. Each part has its own details and technologies. Let's discuss all of +them. + +### The Front End + +We'll follow this markup to design the app: + + + +1. Search/Filtering Controls. +2. New To Do Button. This should open a modal to type the "to-do" data. +3. Priority column should show in the header the classic up and down arrows to + allow the user to sort. +4. Due date column should show in the header the classic up and own arrows to + allow the user to sort. +5. Action column to show actions (links/buttons) to allow the user to delete or + edit a "to-do". + - To Edit is ok to show a modal similar to the one to create a "to-do". +6. Pagination control. Showing the pages, its number and the next + and previous page is enough. +7. Area to show the metrics. + +We're restricted to use the following technologies for this project: + +- JavaScript. +- ReactJS. +- Redux. + +Neither of which I've used before. So this will be an interesting project. + +### The Back End + +This is further broken into two parts: the _model_ and the _API_. The _model_ is +the information we're storing for every to-do. The _API_ will be our connection +between the Front End and the Back End. Let's detail the requirements for each +part. + +#### Model + +Every to-do should have: + +- ID. This could be a number or string or a combination. Must be unique. +- Text (required). Max length is 120 chars. +- A due date (optional). +- Done/undone flag. +- A done date. When the "to-do" is marked as done this date is set. +- Priority (required). Options: High, Medium and Low. +- Creation date. + +#### API + +- A GET endpoint (/todos) to list "to-dos". + - **Include pagination. Pages should be of 10 elements.** +- Sort by priority and/or due date. +- Filter by: + - The name or part of the name. + - Done/Undone. + - Priority. +- A POST endpoint (/todos) to create "to-dos". + - Validations included. +- A PUT endpoint (/todos/{id}) to update the "to-do" name, due date + and/or priority. + - Validations included. +- A POST endpoint (/todos/{id}/done) to mark "to-do" as done. + - This should update the "done date" property. + - If "to-do" is already done nothing should happen (no error returned). +- A PUT endpoint (/todos/{id}/undone) to mark "to-do" as undone. + - If "to-do" is already undone nothing should happen. + - If "to-do" is done, this should clear the done date. + +Finally, we're restricted to using the following technologies: + +- Java. +- Maven. +- Spring Boot. + +And again, none of which I have experience. Oh, boy. + +## What I have learned + +A LOT. Not only have I learned enough of each technology to (barely) make a +functional To-Do App from almost scratch in less than 3 weeks, but we're +restricted to **NOT** use a database. At first, I thought "well, I don't know +anything about databases either, so this is something one technology less to +learn." Later I finally understood that this requirement: + +> No need to use a database by now, storing data could be in memory using Java +> Collections, and it is ok if data is lost when the application is +> shutdown. But they are asking you to design the persistent layer such that it +> will be somehow easy to switch from in-memory implementation to a database +> implementation. + +will cause me a lot of trouble. Well, not that much trouble, but things would +have been smoother if we're allowed to use databases. (Or at least that was my +conclusion.) + +So, without further ado, let's summarize everything I've learned during this +whole new project: + +### Front End + +To use [_Redux_](https://redux.js.org/), we have to understand key-concepts +like: + +Functional Programming : Decomposing a problem into a bunch of small and +reusable pieces. + +Higher Order Functions : A function that takes a function as an argument and/or +returns a function. + +Pure Functions : Where a function with the same arguments yield the same +outputs. No external behavior should alter the output. + +And little more. + +Redux was heavily used at first. Creating the store and developing the reducers +to store all to-dos was my first move. Not the best, but my first. I learned +about [Bootstrap](https://getbootstrap.com/) and used it to create the UX/UI. +Buttons, a table for the to-dos, containers with borders, and very messy **but +functional** forms for adding a new to-do, editing a to-do and filtering through +to-dos. Every time a reducer worked, I celebrated it. It wasn't very difficult +to make them work, but it was an achievement for me, a math student who +specialized solely on Python. + +I realized that JavaScript wasn't that much different from C++, but where +everything is a class and objects are mutable. ~~And when something failed, +`undefined` was returned instead of an error... Why?~~ + +[React](https://react.dev/) was a breeze of fresh air and something easy to +pick-up. It has its funny quirks like using `className` instead of `class`, the +style needs to be defined as a JSON object and not a string, or that inside a +loop, every new item needs to have a key, but they weren't serious problems. + +I always had Google opened (well, it was Bing, but you get the point). Every +time I was stuck or lost, I tried to Google it. StackOverflow was my savior most +of the time, but not always. Even _Googling_ can be seen as a skill. Let me tell +you a funny story on why I said this: + +Because I was too into Bootstrap, I searched for a date-picker input using +Bootstrap. After a long search, I stumbled upon a +[**Bootstrap date-picker**](https://github.com/uxsolutions/bootstrap-datepicker) +plugin developed by [**uxsolutions**](https://github.com/uxsolutions). I really +thought it was the only (actively developed) solution and I forced it into my +project. (See commit +[163398](https://cgit.hisiste.com/ToDo-App-FE/commit/?id=163398f68444d278eb83543ba9798a6441c8af9f) +([same but on GitHub](https://github.com/Hisiste/ToDo-App-Front-End/commit/163398f68444d278eb83543ba9798a6441c8af9f)).) +**TWO** days later and after having LOTS of troubles with `onChange`, I just +found out that I could have used HTML5's date input. By just doing + +```html +<input type="date" /> +``` + +ALL of my problems with date picking suddenly vanished. You can even see part of +my frustration on commit +[3d4a58](https://cgit.hisiste.com/ToDo-App-FE/commit/?id=3d4a589e5dc8f97a5fe94f5f8f42b97f2b6c7b52) +([GitHub link](https://github.com/Hisiste/ToDo-App-Front-End/commit/3d4a589e5dc8f97a5fe94f5f8f42b97f2b6c7b52)). +I attribute this problem to me trying to solve and forcing myself to solve +everything with Bootstrap. I thought (and still think) that it is a very cool +library, but it cannot do everything. + +### Back End + +Working on the Back End was something else. I felt a little more restricted +using Java than using JavaScript. But at the end, Spring Boot helped me in +simplifying the API creation. Like, a lot. I felt really happy and relieved when +my first API call worked instantly. It was just a "Hello World!", but after +seeing how simple it was to write it, I was calmer than when I started this +project. + +{: file="Main.java"} + +```java +@SpringBootApplication +@RestController +public class Main { + public static void main(String[] args) { + SpringApplication.run(Main.class, args); + } + + // GET request on page `http://localhost:9090/greet`. + // Returns the string "Hello world!". + @GetMapping("/greet") + public String greet() { + return "Hello world!"; + } +} +``` + +As simple as that! I was happy... Until the "database" came along. + +Apparently, after setting up a database and linking it with the back end, all I +had to do was: + +{: file="ToDosRepository.java"} + +```java +public interface ToDosRepository extends JpaRepository<ToDos, Integer>{} +``` + +`ToDosRepository` would have been our database variable, `ToDos` is our class +[model](#model), and `Integer` is the data type of our ID. The database would +have functions like `findAll`, `save`, `deleteById` and many more. But because +we're restricted to not use a database, WE HAD to implement those functions by +ourselves. So we had to do something like this: + +{: file="ToDosRepository.java"} + +```java +public class ToDosRepository implements JpaRepository<ToDos, Integer> { + List<ToDos> todos; + + // Constructor + public ToDosRepository() { + this.todos = new ArrayList<>(); + } + + // Return all to-dos. + @Override // <- We HAVE to write our own implementations. + public List<ToDos> findAll() { + return this.todos; + } + + // Sort and return all to-dos. + @Override + public List<ToDos> findAll(Sort sort) { + // Figure out how to use the Sort class. >:3 + } + + // We HAVE to override EVERY function that JpaRepository offers. Even if + // we won't need it. (You can always return `null` as a solution.) +} +``` + +Notice how instead of an _interface_, we have created a _class_, and instead of +_extending_ the **JpaRepository**, we're _implementing_ it. + +The "database" took me way longer than I've expected. But at the end I made it +work. Somehow. There were hiccups here and there, like when I tried to pass a +request body to a GET request, just to then find out that this is a bad +practice. At the end, there were no major "blockers" in this project. + +### Connecting both projects + +I HAD to run and implement this as fast as possible. Time was not on my side and +the connection wasn't as smooth as I wanted to. For this part, I used +[Axios](https://axios-http.com/) on the Front End. This library allowed me to +make HTTP requests to the Back End. These were my major takeaways from this: + +- Discovered about a `'Access-Control-Allow-Origin' header` problem and found + about CORS Policy.[^CORS] At the end the problem was fixed by making the + Back End (port 9090) allow requests from the Front End (port 8080). + + ```java + @SpringBootApplication + @RestController + @RequestMapping() + public class Main { + // Edit this origin and set where the Front End is allocated. + private static final String allowed_origin = "http://localhost:8080/"; + + // ... + + // Get all to dos. + @CrossOrigin(origins=allowed_origin) // <- Allow HTTP request. + @GetMapping("/todos") + public List<ToDos> getToDos() { + return toDosRepository.findAll(); + } + } + ``` + + Every request had to have the `@CrossOrigin(origins=allowed_origin)` line in + order for the Front End to successfully make the HTTP request. + +- Apparently the GET requests should not have a body.[^GET] Although `curl` + CAN send a body on GET requests, Axios doesn't support it. + +- Filters, sorting, pagination and more can be done pretty quickly on the Back + End. It is bad practice to do this stuff in the Front End. ~~There goes work + to waste. D:~~ + +- APIs are a GREAT way to connect projects, each written in their own + languages, having their own frameworks and their own databases. + +## Conclusion + +This project was a fun ride. Full of new technologies, new ways of creating +applications and turning theory into practice. I celebrated each personal +milestone, from deploying the whole app to writing my first API call. It's not +hard to write code in a new programming language, but it's hard to write clean +code. My app works (I hope), but the code is most likely a complete mess with +lots of bad practices that I don't know about. The only way to get better at it +is to **practice**. Keep practicing, learning and trying new and challenging +things. + +--- + +## Footnotes + +[^CORS]: + To know more about this issue, see commit + [5fccbc](https://cgit.hisiste.com/ToDo-App-BE/commit/src/main/java/com/encora?id=5fccbca45f7ad6837f46b4f5967c06c85e588e8c) + ([GitHub](https://github.com/Hisiste/ToDo-App-Back-End/commit/5fccbca45f7ad6837f46b4f5967c06c85e588e8c)) + +[^GET]: + See the following link for more information: + [[StackOverflow] HTTP GET with request body](https://stackoverflow.com/a/983458). |