Flatiron School JavaScript Phase 4 Project

PROJECT PLANNING —

For Phase 4 of Flatiron School our project was the first FullStack Project that we had to encounter. The previous three projects all had to deal with Backend Languages such as Ruby, Sinatra, and Rails. This time we had to utilize a Rails backend as an API, and a HTML, CSS, and JavaScript frontend. The parameters were that the backend had to use restful conventions of Creating, Reading, Editing/Updating, and Deleting our objects that the Users were creating. It also had to have a has-many relationship, so that meant we had to have at least two tables for our Database schema. And for our frontend we had to use Object Oriented Programming through JavaScript. The challenge? None of us had touched, or were familiar with the frontend until it came screaming into our lives like a new born baby. Loud and intimidating? Sure. But we all ended up loving it just the same, especially me.

THE PROJECT —

The project that I created is an App called “Tasker”. It is a application that creates a to-do list for a new or existing user. They can choose what they need to get done, and upon creating their task they can edit, or delete, or complete each task. The beauty of tasker is, if you logout, and forgot to complete or edit a task, they are still there waiting for you. What good is a list if you cant find it?

Now I know what some of you might be thinking. A to-do list? “……zzzzzzzzz”. I know, I get it! At it’s core it is a very simple project. Which harkens on my K.I.S.S method when it comes to projects like these: “KEEP IT SIMPLE STUPID”. I’m not saying don’t go for it, but I have a theory that we build things that people need, right? No matter how simple, or complicated, it can even be an idea, of an idea that has already been made or something someone uses else where. But the trick is to make it better, make it inviting, make it something a User wants to interact with and use everyday.

THE BACKEND — RAILS API

So for my backend we were required to build a Rails API that used RESTful conventions and had to Create, Read, Edit, Delete(CRUD) on our Objects on the front end. It didn't make sense to have a show page for each individual task that the user created, because they instantiate on the DOM after the user hits submit. It made more sense for the user to be able to create, edit, and delete them as you would with any list, or task that changes over time. We also had to make three AJAX calls using fetch to communicate with our BackEnd. Through this we were able to create, edit, and delete our posts.

AJAX was new for all of us. It stands for Asynchronous JavaScript and XML. And is used primarily in your front end code to receive data from your API, and return a Promise to your front end.

We got a lot of practice with CRUD in the last project since we didn't have a frontend to throw information to. Usually with a backend project you follow a MVC structure. Model, View, and Controller. If we think of them as a restaurant a Model is the chef. A Controller is the server, and the View is what you order. The Controller talks to the customer(user) and finds out what it wants. They then choose which action to use to talk to the Model(the chef), the model then goes in the walk-in(the database) and sees if it is available. If it is the Model prepares the plate(the data), passes it to the server(the controller), the server then takes the plate and presents it to the customer(user), and the customer takes in their order(the View). Easy right?

With that in mind, the way we used to do it was pass the info to a View file and render it in ERB, or Evaluated Ruby and mimic a front end. The only difference with the Controllers and Views in this project was that instead of rendering a View file with an instance variable. We are now rendering JSON data. Which stands for JavaScript Object Notation. We now render that and pass it to your fetch call. Inside the body of the fetch call we are stringfying the data, then collecting a response, and then passing it a callback method to tell JavaScript what to do, and how to style the information.

I built the BackEnd part of my project weeks in advance. I knew that if I had a solid BackEnd, I could spend most of my time constructing the FrontEnd and make my life a little bit easier.

THE FRONTEND — JAVASCRIPT

In this cohort we had spent months learning how the BackEnd functioned as a brain and processor for the user. *Enter Stage Right: JAVASCRIPT*. For me this was not an easy task switching your thinking from the BackEnd to the FrontEnd and then eventually to both simultaneously. That being said, I decided to go part-time with my track to get a better understanding of what this language was doing. To me it was mystifying, and knew it couldn’t be, it was tangible, we had objects on the screen that we could interact with and had a separate language to do it for us, I was in search of a pattern or sandwich code:

• Make the element with HTML
• Give it an id
• Grab that id off the DOM and save it to a variable in your JS file
• Then in an eventListener or function manipulate that element and impress your friends

For some reason, and don't ask me why cause I don't know, I don't make things easy for my self. That being said our project required is to build OOP JavaScript, meaning our JS had to have classes to interact with the DOM as well. I eventually built it that way, but first I built it the “old-fashioned” way, or as dev’s call it Vanilla JS.

I truly wanted to understand how this was going to work before I created Classes for my Models. I wanted to see how the fetch calls worked with buttons on the DOM and eventListeners in the FrontEnd code. THEN I moved it into Object Oriented programming. The difference? this…

No seriously, “this”. Ohhhhhhhhhhhhhhh, sorry. In reference to this can be a number of things in JavaScript, it can be the window on the DOM, it can be an id of a Task object, it can also be a Task it self. Given the proper instance of this, you can find out what “this” is.

Typically in OOP JS we use this in the constructor, which is a function that creates an instance of a class. So instead of dynamically setting the id every single time you want to create an object. In the constructor you can set an id, a string, even a users name to => this.name = user.name. Put that inside your constructor and every time a new user is created, this.name will be instantiated automatically without having to go find the element, find the id, and then find the innerText of a childNode and setting it equal to a variable to be called on later.

At the end of the day OOP JS can become a bit confusing, but it is more abstract and as programmers if we can do it in less code, we’re going to.

THE FINSIHED PROJECT — TASKER

I made sure I took the entire time period in which to complete the project to use it to my advantage. I didn’t want this to be an ordinary to do list. I wanted someone to have something good to look at.

The user is greeted with our logo and the sign in form, which is a fetch request for “POST” on the frontend and goes to our Create action on the backend, and given if they are already a user, they either get a new id, or Rails finds the existing one.

From there, they are presented with their tasks if they have not been deleted or completed yet. As you can see I took the liberty of making post it notes for each task. Who wants to look at a list all day?

And then given what the user needs to do, they can hover over the Post-it note, task object and choose between three buttons, edit, and delete, which are two separate fetch calls, completing our three AJAX fetch calls requirement. If you decide to Edit a task, given that this is a single page application or SPA. We needed to hide the Create a Task form and present the user with an edit task form. After they have made up there mind they can then hit submit and voila, updated task right on the DOM, and the Task form reappears for your convenience to create more tasks.

For Delete, its pretty self explanatory, if you hit that button….you will never see this task again!!!!!!!!!! The completed button was just some added functionality I wanted for the user. It will put a line through in the text and not disappear from the DOM just in case the user still needs to see it.

This was an intense labor of love. Every day I was excited to work on this project. It did not come without its frustrations, but once finished I had the biggest smile on my face. Coming from a full-time track, to now a part-time track and taking the extra time to better understand JavaScript was the best decision I could have made. I can proudly say that I will probably use it every day from now on.