Another student had a similar question, I wanted to share the same answer/response and see if it helps your understanding. It is basically related to how to keep your code dry, maintainable and the benefits of OOP.

Let me know if it helps.

---

If you wanted to make it more OO(object oriented) 

you could break up the project in to a few different classes.



event listeners

logical operations



you could include both of those in a ‘Utilities’ class, I use a utilities or a service class for things that are important, may need to be reused else where in my code base but are really just tools to help me accomplish a task.



generally you don’t want to nest more than 3 levels, I prefer not to go greater than 2 for if statements/loops and other control flow operations

you could also make the logical operations easier to read by abstracting them to a function and then passing the variable needed for the operation needs via an argument.

This is an example of “Tell Don’t Ask” (https://robots.thoughtbot.com/tell-dont-ask). Often “Ask” looks like an if statement if the logic goes one way or another the if statement will carry out whatever you want in your brackets, “Tell” calls a function in a class or module that has logic in it to do what was in the if statement. This structure is more maintainable, imagine if multiple things depend on the logic of that if statement or if that same if statement is reused throughout the code.

It is better to store it in one place instead of having that logic (if statement) spread throughout the code base.

Example #pseudocode:

//ASKING


if (person[‘don’] === ‘don’ && person[‘erin’] === ‘erin’) {

runPeopleFunction()

}




//OR




//Filename: Utilities.js

module.exports = {


function areThesePeople(person) {



if (person[‘don’] === ‘don’ && person[‘erin’] === ‘erin’) {

 runPeopleFunction()

 }



// a more succinct version of the if statement above a ternary operator

// return (person1[‘don’] === ‘don’ && person2[‘erin’] === ‘erin’) ? true : false
}



 function runPeopleFunction() {

console.log(‘these are people)

}




}









//Filename: index.js
//then you can use it with 


let Utilities = require(../classes/Utiities)

#TELLING
Utilities.areThesePeople(personObj)

this would not add a ton of value by itself (with this current example), imagine if you had a lot of logical operations (if statements) that you needed to use throughout your application.

This code pattern can be very helpful in cleaning up commonly used files. In the above situation the index.js is the commonly used files and the Utilities file would only be modified when you wanted to add new utilities. This abstraction will allow you to reuse logic/code and keep files (index.js) that are frequently used cleaner, less complex. 

if you find your self doing multiple if statements, one after another you may be in the position to combine if statements using ‘&&’ or ‘||’

 or you may want to abstract like in the pattern above.

you could break up your js in to different files



you could stop hiding and showing elements and delete them or add them as needed.



good comments



you could add spaces between the function and the arguments, see line 154



I can tell that you worked hard and you were thinking through the problems you faced



for drying up your code look for duplication, put the duplication in to a function and then call the function.

Do this enough times and see if any of the functions have enough in common to put them in to a class or object.

the css validator isn’t up to date enough to know space-evenly, disregard it.

I think the review button and the functionality after clicking it could use a little work.