OVERVIEW

This technical log is about the development of my ToDo Application. The functionality of this app is to add, delete, edit and control ToDo objects. The App is built with Java, Maven, Spring, React, Javascript, HTML, and CSS technologies. This was a project with a month's due date. In that period I had to develop an understanding of Java, Maven, Spring, and React because this was my first time making a complete app with those technologies. I received tutorial and reference information. I use websites, youtube, and Oreally tutorials for many concepts.

CONTEXT

This context is divided in three main sections; Functional Requirements, Technical Requirements, and Engineering Requirements. Next I'm going to break down a short explication of the requirements in this app.

Functional Requirements

client needs to implement a to do list to help manage their tasks in their daily job. The client asked you to implement the following functionality:

1. Create a “to do” specifying the name, a priority, and possibly a due date
2. Ability to edit name, priority and due date for existing “to do” tasks They want to be able to specify a due date or clear the due date (because they are not interested in when to finish that “to do”)
3. Be able to filter “to do” specifying the name (or part of the name), and the priority, and if they are done/undone.
4. Be able to sort the “to do” 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
5. Mark “to do” as done (clicking in a checkbox) or to undone a “to do” The undone functionality is just there if there is a mistake.
6. Since it is possible that the client will have a lot of “to do” they need to paginate the list of “to do”
7. Ability to know, in average, the time between creation and done for all “to do”. This should be shown in general for all done “to do” and also grouped by priority. This is important for the client since this is a metric, they follow to measure performance.

Technical Requirements

The UI Requirements are specified for the the client as the following 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” a. 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

Extra details you can add:

1. Show the row with background colors depending on the due date:
   
   • No due date --> No background color
   • One week between due date and today --> Red background color
   • 2 weeks between due date and today --> Yellow background color
   • More that 2 weeks between due date and today --> Green background color
2. Strikethrough fonts for those tasks marked as done

Engineering Requirements

The Engineering team of the client is asking you to implement the functionality using the following recommendations:

Model

• 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 done/undone
  • Filter by the name or part of the name
  • Filter by 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 PUT/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/POST 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

Database

No need to use a database by now, storing data could be in memory using Java Collections (no in-memory databases like H2) 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 (they are planning to implement the database implementation later).

Repositories

They need 2 git repositories. Front end and back end. In both repositories the main branch must be the one ready for production. It's up to you the other branches.

Frontend Technology

• JavaScript
• ReactJS
• Up to you to use Redux or React Context

They need at least the following commands to run the project:

• npm run start -> To run the front-end application
• npm run tests -> To run all tests in the front-end application

Backend Technology

• Java
• Maven
• Spring Boot

They need at least the following commands to run the project:

• mvn spring-boot:run ->To run the back-end application
• nvn test -> To run all tests in the back-end application

Back-end project must run in port 9090.

Your API should handle correct http return codes:

• Successful/Normal responses should return 200 (OK)
• Responses where a resource is not found (saying if you are trying to get a specific resource or deleting one that no longer exists) should return 404 (Not Found) When a ToDo is created, it should return 201 (Created)
• Validation errors when creating a ToDo should return 400 (Bad Request) and their respective error message indicating what happened (stylistic Json format).

DEVELOPMENT

This is the section where I'm going to explain the developing sections of my app I'll add some sections of code about how I did the required features.

Watch a video about the results: Video To Do App

Functional Requirements

I did this section building a Class with specific variables that are part of a Todo.

Ability to edit name, priority and due date for existing “to do” tasks They want to be able to specify a due date or clear the due date (because they are not interested in when to finish that “to do”)

Be able to filter “to do” specifying the name (or part of the name), and the priority, and if they are done/undone.

The filter section cost me some time to figure out how to connect API and Frontend to send the variables. I used parameters through the URL, then in a Request GET I built a series of lines to validate what was coming.

Be able to sort the “to do” 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

The sort section took me some time, as well. I was learning how to manage maven and Spring boot. Also, took me time to figure out how to call a request from the Frontend. I did the filter and sort at the end of the date delivery. At first, I felt complicated the sort because it wasn't working, but then I figured out the problem was in my type of list. The sort libraries need a mutable list.

Mark “to do” as done (clicking in a checkbox) or to undone a “to do” The undone functionality is just there if there is a mistake.

It wasn't complicated. It was to look for the id and change the value for Done. Something to work in this section is more in the frontend. If a task is done it affects the Metrics section and the view of the task. I could improve how a Done task is showing, but the blockers (Sort, filter, pagination) took me some time and I couldn't make a better presentation of my app.

Since it is possible that the client will have a lot of “to do” they need to paginate the list of “to do”

The pagination in the app was new. It's my first time making pagination on an app. Some information made it pretty difficult to follow. It didn't take me too much time but for the first time understanding the classes was confused. Actually, because our application doesn't have a repository, Most of the information on the Web was using some libraries from the Repository. The intention of this exercise was to figure out how to make pagination without those tools. I used a DTO class to add values that had nothing to do with a task at all; like metrics, and pagination information. Then my front end could take that data to build pagination and the metrics section. At the end this was my result:

Ability to know, in average, the time between creation and done for all “to do”. This should be shown in general for all done “to do” and also grouped by priority. This is important for the client since this is a metric, they follow to measure performance.

The difficult part of the metrics was working on building a function to change the seconds received from the API into the kind of unit time it is; like hours, minutes and seconds.

Talking about date variables, I learned that Data was a string in my Frontend but I need it to send the request like an Object. This problem was more part of the Frontend Section than in the API. It affects when you build a new task because I had an error request. I fix it like this:

Api

This section was successful complited.

• A GET endpoint (/todos) to list “to dos”
• 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 PUT/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/POST 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

General RESULTS and CONCLUSION

This application has a lot of improved areas/ opportunities. In this section of the results I want to talk about those details I missed.

Tests: I couldn't finish the test area. Actually, I was working in improving everting from the Back-end and front-end then at the end I could make time to search for how to build a test.

In the Back-end: I found the sort section has a mistake when is working without due dates. It is important because the client asked for the ability to add due dates without a specific date.

Frontend: This is something that I would have liked to fix in time. I forgot to fix the problem with the buttons that aren't hidden when a module comes out.
Also, sometimes the application didn't reload when it was a new time or when you clicked Done/Undone It happened because I used a variable that in time doesn't change because the component isn't active. I should connect better that section. It's because I have to practice the use of hooks, and I might need to understand better how the hooks are working in React. Moreover, I should make betters practices when I'm building components, it would make it easy to fix and get improvements in the code.

CONCLUSION

I learned in this project a lot of information. Actually, I'm still learning how to manage the new tools; for example the tools of React, Java, and Spring Boot.

I can see the reason because I couldn't make a better view and code in the App, and the missing parts of the requests from the client. I think it's because I built a whole application without too much support when I had too many questions. It means I may look for ways to make self-learning. I used youtube, Websites, and some questions in groups of experts. I'm still trying to find a way to make me more independent in coding and I would start with the interpretation of those sources.

In general, I can see how I need to improve the organization of my code. I should acomplish good practices as I'm writing code. It's like the English, you get better if you practice. This is my firt time making an App like this. I'm sure I'm going to make time to fix those details, but right now this is the result of my firts try.