Last week me and my fellow cohort mates at Flatiron School Seattle finished our module 3 projects; the assignment was to build a single-page application using vanilla Javascript and a Ruby on Rails backend. The rest was pretty much up to us, and I decided to make Jeoparody! This was the first website I built all by myself, and I learned a lot from it. So for my blog post I thought it would be helpful to write about the top things I learned.

CSS is weird

Going into this project, I felt fairly confident in my CSS skills. I’d worked on the Codecademy CSS Course and tinkered around in the console, so I thought it was pretty straightforward. When you don’t know what you don’t know…

My biggest struggle was figuring out how to vertically center text inside a div. ‘Why is this so hard?’ I asked myself after spending at least an hour adjusting the padding, margin, height and width. I finally discovered that simply wrapping the text in a p tag will do the trick! Unless...the text is longer and wraps to become multi-line. Still haven’t figured this one out.

Seed smart

While we’re on the topic of things I thought I had down pat: seeding my database. I found this awesome API, jService, that has every clue and category from every season of Jeopardy. That’s roughly 185,000 clues! I was pumped! I set up my Clue and Category models, figured out the best way to iterate through each page of the API, and the seeding began.

Fifteen minutes in, seeding failed! I quickly learned that one shouldn’t assume an API with 100,000+ entries is perfect. Tons of clues were duplicated, there were empty strings, missing values, you name it. After a lot of trial and error, the solution was to create two if statements that check each clue before it’s added to the database. The first one makes sure that the clue actually has the keys I want: question, answer, and category. The second if statement ensures that the values aren’t just empty strings.

clues.each do |clue|
  if clue.key?("question") && clue.key?("answer") && clue.key?("category")
    if !clue["question"].empty? && !clue["answer"].empty? && !clue["category"]["title"].empty?
      create_clue(clue)
    end
  end
end

Event listeners are picky

I haven’t had a lot of experience using event listeners, but they’re obviously an important thing to master. The first one that I implemented on my website was pretty straightforward. When a user first comes to the page, they put in their username and click the submit button. The event listener hears the ‘click’ and does its thing:

document.getElementById('submit').addEventListener("click", function(e){
  e.preventDefault();
  username = document.getElementById('username').value.toLowerCase();
  findUser(username);
})

There was no need to ‘remove’ this event listener because the div that it’s inside is hidden once the user logs in. Easy! The next event listener I used was for each of the clue divs. I had figured out how to remove the dollar amount from the div once a user had clicked it, but the event listener remained. I tried a few things and eventually asked for some help. My instructor gave me the very simple solution of simply adding a class of ‘clicked’ to a clue div that had been clicked. This allowed me to write the following inside the event listener:

if (clueDiv.classList.contains('clicked')) {
  return;
}

So once again, the event listener still exists on each clue div, but if a user clicks on one that they’ve already clicked on, it will simply return. Easy! My final event listener is the one that gave me the most trouble. Once a user has clicked on a clue, a div appears that asks if they got the question right or wrong.

I added an event listener that listens for a keydown of ‘Y’ or ‘N’ and went on my merry way. I soon realized that a user could continue to press ‘Y’ long after they’d finished the clue, and their score could increase forever! Thus, I finally had to tackle removing an event listener. After much trial and error, I discovered that removeEventListener is picky. Until now, I had been writing the whole function inside of the event listener, instead of referencing a separate function. This doesn’t fly when you try to remove the listener! In short, this was the only solution:

document.body.addEventListener("keydown", yesOrNo);
document.body.removeEventListener("keydown", yesOrNo);

Comments are necessary

I’ve always been pretty good about writing comments in my code, but it wasn’t until I started this project that I realized just how necessary they are. After I had my backend all set up, I wrote that first fetch request and it began...I was in the zone.

When I’m in the zone, coding my little heart away, it’s easy to forget to write a quick comment to help out my future self. But it’s so important! Because even if I think I know exactly what all my code is doing, I’ll eventually be going to sleep. And the next day, when I’m reading my code, I have no idea what’s going on. So don’t forget to leave yourself some notes to save future you from future headaches.

Conclusion

To conclude, I learned a lot from building my first website. If you’re new to coding, I would highly recommend building a single-page application. It’s great practice and helped solidify my knowledge of HTML, CSS and Javascript. Happy coding!