Cocktail-CheckR Javascript Project — Phase 4 Flatiron School
Here we are at Phase 4! During this phase we are studying Javascript and for my project, I decided to keep it quite simple. Since this entire language is brand new to me, and one that honestly I have struggled to grasp, I did not want to get in over my head with a grand idea that ultimately may not be able to meet the project requirements. So, let’s begin!
Requirements & Planning….
The requirements for this project are known to cause students to have to pull in the reins a bit as far as grand ideas go. The overall requirements are as follows:
- The application must be an HTML, CSS, and JavaScript frontend with a Rails API backend. All interactions between the client and the server must be handled asynchronously (AJAX) and use JSON as the communication format.
- The JavaScript application must use Object-Oriented JavaScript (classes) to encapsulate related data and behavior.
- The domain model served by the Rails backend must include a resource with at least one has-many relationship. For example, if you were building an Instagram clone, you might display a list of photos with associated comments.
- The backend and frontend must collaborate to demonstrate Client-Server Communication. Your application should have at least 3 AJAX calls, covering at least 2 of Create, Read, Update, and Delete (CRUD). Your client-side JavaScript code must use fetch with the appropriate HTTP verb, and your Rails API should use RESTful conventions.
Planning was up next and I had to figure out the overall project concept, what my models would look like, how my relationships would be formed, and the general idea of how my website would look and function.
Having a long history in the Food & Beverage Industry, I really wanted to pay homage to my time behind the bar. The application I would create would be a cocktail review portal, where enthusiasts could leave reviews on specific cocktails. I have named it “Cocktail CheckR”.
I decided, with MVP ringing in the back of my head, that all I really wanted was my users to land on the homepage and see a selection of cocktail pictures. A user will have the ability to click on a picture, when they do the DOM will clear and then show the individual cocktail’s ‘show page’ and the reviews that have been previously posted. A user will be able to leave a review for a cocktail from that page by filling out a form, and the review will render at the bottom of the page under the previous reviews.
Whilst this application is currently being designed to be super basic purely to satisfy project requirements, I really like the potential that it has to grow and go in many different directions. I plan to give it more functionality at a later time.
Repository configuration
This project is different from those I have done before in the sense that it is split into 2 separate GitHub repositories. The front-end and back-end are linked by containing each respective link in the README.md files.
Building the back-end
To get started building out the back end of my app I created it by typing “rails new cocktail-checkr-back-end — api”. Including the double dashes and “api” on the end of this command is something new to me as well. This is done because we are to create our own API’s using Rails for our applications.
Next up I built out my model classes and controllers using rails generators. There are a number of these generators that are available for use, and the documentation(link here) for finding out what’s available is one of my favorite resources out there. This project just has 2 models, cocktails, and reviews.
Deciding what my database would look like for this project was straightforward. My cocktail model would include a name and image_url. My review model has just a title, description, and a rating between 1–5.
As displayed in my schema, you’ll notice that the review model also has a cocktail_id attribute. This is because of the “belongs_to” relationship that the review model has with the cocktail model.
Reminding myself that this project is MVP for now, I decided I would only display 3 cocktails for my users to review, for now. I selected 3 of my favorite drinks, created some seed data, and ran the migrations to persist this data into my database.
Setting up routes again was very simple. I nested my reviews routes inside of the cocktail’s, and declared which 2 of the CRUD routes I would be using which can be seen below:
My controllers demonstrate that the RESTful conventions are being followed, and came freely filled out for me with the magic of rails generators. I only need 2 CRUD actions here, so cocktails will only need an index method. Because reviews are the only part of my app that users can create, I needed to declare the parameters that can be accepted in addition to the required create and index methods.
Front-End Construction
Once satisfied with my back-end code, and I was able to see my data by running “rails s” and going to “http://localhost:3000/cocktails/”. My API came out in pretty JSON hashes, and I was ready to get going building out the front-end.
The front-end of my application would be Javascript focused, but in order to function it also needs to contain HTML and CSS. The index.html file will be the face of the application, displaying all the data and call-in functionality built out in my Javascript using script tags. I started building out my Javascript functionality in an index.js file, but an important requirement to consider was that my Javascript code was required to be object-oriented to encapsulate related data and behavior. I broke out my classes into 2 files contained in an “src” directory and then moved my Javascript logic into their respective object-oriented classes. Doing this also demonstrates best practice when it comes to separation of concerns.
Another main requirement to focus on here is the 3 AJAX calls, also known as fetch requests. The 3 calls that I made in my project are fetching all of the cocktails on the index page, fetching an instance of a cocktail and its reviews through a show page, and updating the show page when a user creates a review and posts it.
Finishing Touches & Pain Points
Lastly, as with all projects I had to go back over my entire application with a fine tooth comb and refactor anywhere possible. Keeping your code DRY is important to remember at all times. I confirmed that my project now meets all the requirements, and I can focus on making it pretty, or not! (design is not a requirement here, but it’s fun!)
During this project build I experienced some issues with my form rendering from the very first landing page, when I wanted to keep it hidden until the user clicks on the cocktail. I realized during this process how many different ways there are to achieve the same goal in Javascript, and that this language really allows people to demonstrate their individuality with coding. After attempting to correct this by asking the internet for help, as well as my friends it ultimately came down to a very simple fix (go figure). All I had to do to fix this issue, was to include display instructions in style tags in my HTML. I was finally able to only have my form display when a user clicks on the “New Review” button. During this madness I also included a “Back” button to take users back to the main page.
Thanks for taking the time to read my Phase 4 blog, if you’d like to check out my repositories, you can do so here and here.
