At this point you’ve already had a fair amount of practice using the various techniques we’ve shown you. But we’ve been throwing a lot of information your way, so before we move on we’re going to take a minute to slow down and work on one more great portfolio project.
Todo lists are a staple in beginning webdev tutorials because they can be very simple. There is, however, a lot of room for improvement and many features that can be added.
Before diving into the code, take a minute to think about how you are going to want to organize your project
By this point, you will have learned and had a chance to practice the most common object-creation and organization patterns in JavaScript. But that is just the tip of the iceberg. More important than learning the syntax for factory functions or modules is figuring out how to use them effectively.
This whole series of lessons has been about the "Object Oriented Programming" paradigm (OOP). The basics of creating objects and classes are relatively straightforward. But it is not straightforward to decide what to put in each object, or when to make a new object, or when to let an object ‘inherit’ from another one.
By the end of this lesson, you should be able to do the following:
Explain the "Single Responsibility Principle".
Briefly explain the additional SOLID principles.
Explain what "tightly coupled" objects are and why we want to avoid them.
Luckily there are several concepts and principles that can guide us into making good decisions when it comes to our objects. This lesson is an introduction to the most important of those concepts. Keep in mind that there is not usually a very clear answer to your application design questions. Some patterns and ideas are obviously better than others, but there is often some trade-off when deciding where to put a specific function. In other words.. these principles are not rules– they’re helpful guidelines.
As you read these resources, it might help to go back to some projects you’ve already done and think about how what you’ve written measures up to the examples you see. And of course, as you move on keep these things in mind when crafting new projects.
One of the most important things to remember as you craft your objects is the Single Responsibility Principle which states that a class (or object or module.. you get the point) should only have one responsibility. Here’s a really common example. Most of our code has functions to update and write things to the DOM in addition to our application logic. It’s a really good idea to separate out your DOM stuff from the application logic.
So instead of this:
function isGameOver() {
// game over logic goes here!
if (gameOver){
const gameOverDiv = document.createElement('div')
gameOverDiv.classList.add('game-over')
gameOverDiv.textContent = `${this.winner} won the game!`
document.body.appendChild(gameOverDiv)
}
}
You should extract all the DOM manipulation into it’s own module and use it like so:
function isGameOver() {
// game over logic goes here!
if (gameOver){
DOMStuff.gameOver(this.winner)
}
}
In fact – the function isGameOver shouldn’t be calling the DOM function anyway that should go elsewhere (directly in the game-loop)
The Single Responsibility Principle is the first of a commonly found set of 5 design principles called the SOLID principles. Both of the following articles mention the acronym SOLID before going on to talk about Single Responsibility. Single Responsibility is definitely the most relevant of the 5. Feel free to dig into the rest of the SOLID principles if you like.. but pay special attention to Single Responsibility.
Obviously, all of our objects are intended to work together to form our final application. You should take care, however, to make sure that your individual objects can stand alone as much as possible. Tightly coupled objects are objects that rely so heavily on each other that removing or changing one will mean that you have to completely change another one – a real bummer.
This one is related pretty strongly to ‘Single Responsibility’ but takes a different angle. As an example, if we were writing a game and wanted to completely change how the User Interface worked, we should be able to do that without completely reworking the game logic. So we should be able to start off writing our game using primarily console.logs() and then add in a bunch of DOM functions later without touching the game logic.
The best book we’ve ever read on this subject is Practical Object-Oriented Design In Ruby. Unfortunately, it is not free.. and not JavaScript. We feel confident in recommending it anyway. If you don’t know Ruby, it is a clear enough language that you don’t really need to learn it to follow the examples and the content of the book is sincerely fantastic.
Let’s use what we’ve learned and take a chance to continue practicing DOM manipulation by dynamically rendering a simple restaurant homepage! By the end, we are going to be using JavaScript alone to generate the entire contents of the website!
Start the project the same way you began the webpack tutorial project.
run npm init in your project directory to generate a package.json file.
run npm install webpack webpack-cli --save-dev to install webpack to the node_modules directory of your project.
Quick tip: the node_modules folder can get really big. It is customary to add a .gitignore file to your project so that you don’t have to sync the contents of node_modules to github. The dependencies that are stored there can be installed from your package.json by running npm install, so you don’t need to sync them.
Create a src and dist directory with the following contents:
an index.js file in src
an index.html file in dist. Go ahead and link the main.js file in a script tag. main.js is the file that will be generated by webpack.
create a webpack.config.js file that looks just like our file from the tutorial.
Set up an HTML skeleton inside of dist/index.html with single <div id="content">.
Inside of src/index.js write a simple console.log or alert statement and then run npx webpack. Load up dist/index.html in a browser to make sure everything is working correctly.
Quick tip #2: if you run npx webpack --watch you will not have to rerun webpack every time you make a change.
Create a bare-bones homepage for a restaurant. Include an image, headline, and some copy about how wonderful the restaurant is. It’s okay to hard-code these into the HTML for now just to see how they look on the page.
Now remove those elements from the HTML (so leave only the <html>, <body>, and <div id="content"> tags) and instead create them by using JavaScript only, e.g. by appending each new element to div#content once the page is first loaded. Since we’re all set up to write our code in multiple files, let’s write this initial page-load function inside of it’s own module and then import and call it inside of index.js.
Next, set up your restaurant site to use tabbed browsing to access the Contact and Menu pages. Look at #7 on this hongkiat post for visual inspiration.
Put the contents of each ‘tab’ inside of it’s own module. Each module will export a function that creates a div element, adds the appropriate content and styles to that element and then appends it to the DOM.
Write the tab-switching logic inside of index.js. You should have event listeners for each tab that wipes out the current contents and then runs the correct ‘tab module’ to populate it again.
If you are using GitHub pages to host your completed page you need to do a tiny bit more work to get it to show up. After running webpack the full bundled version of your site is available in the dist folder, but GH pages is looking for an index.html in the root directory of your project.
Simply follow the instructions on this gist. EZPZ!
Recall that the source branch for Github Pages is set in your repository’s settings.
Submit the GitHub repository with the Restaurant web page in the Quiz below.
Separate from the module pattern that we discussed in an earlier lesson, "modules" is a feature that arrived with ES6. Browser support for this feature is quite slim at this point, but is slowly improving and until all modern browsers support it, we can make it work using an external module bundler. ES6 modules are starting to appear in many code bases around the net and getting them up and running will give us a chance to explore some new parts of the JavaScript ecosystem, so it’s going to be a worthy excursion!
Don’t be fooled! We’re going to cover much more than just the new module syntax in this lesson! Before we can really use these modules, we’re going to have to learn about npm and webpack which are both topics that will be very useful to you even beyond this lesson. In the end, the modules themselves are simple to implement, so we’re going to take this chance to learn about a few other things.
Why do we even need or want this stuff? What do you gain from all of this added complexity? These are good questions.. with good answers.
Read this article for a bit of a history lesson. It’s long, but it puts what we’re doing here in great perspective. You don’t have to code along with the examples – the tutorials we cover later will go through basically the same process. But it’s good practice and going through the same process multiple times will help it stick faster.
Seriously.. spend some time with that article – it really clarifies the ‘WHY’ of the rest of this lesson. [Estimated reading time: 30~45 minutes]
The node package manager is a command line tool that gives you access to a gigantic repository of plugins, libraries and tools. If you have done our Fundamentals course, you will probably have encountered it when you installed the Jasmine testing framework to do our exercises.
Take a couple minutes to introduce yourself to what npm is through this article.
At some point, you will probably run into Yarn – a replacement for the default npm. For the most part, it does the same things though it does have a few more features. Recent versions of npm have incorporated some of the best features of Yarn, so using it won’t offer you any real advantages at this point in your career. It is a fine project, however, and may be worth your consideration in the future.
Webpack is simply a tool for bundling modules. There is a lot of talk across the net about how difficult and complex it is to set up and use, but at the moment our needs are few and the setup is simple enough. In fact, you can see an example of getting it up and running on the front page of their website.
Webpack is a very powerful tool, and with that power comes a decent amount of complexity – just look at the sample config file on this page 😱. Don’t let it scare you off! The basic configuration is not difficult and proficiency with webpack looks amazing on resumes.
To get us started we are going to refer to the official documentation.
Code along with the first four steps of this tutorial ("Basic Setup" through "Using a Configuration")
Let’s discuss what’s going on there. After installing webpack using npm we set up a simple project that required an external library (lodash – check it out here if it’s new to you) using a simple script tag. The site lists a few reasons why this is probably not ideal and then steps through using webpack to accomplish the same thing.
There are a couple of key concepts to understanding how webpack works – entry and output. In this example, we rearranged the files into a src and dist folder. Technically we could have called those folders anything, but those names are typical. src is our source directory. In other words, src is where we write all of the code that webpack is going to bundle up for us. When webpack runs, it goes through all of our files looking for any import statements and then compiles all of the code we need to run our site into a single file inside of the dist folder (short for distribution). Our entry file, then is the main application file that links (either directly or indirectly) to all of the other modules in our project. In this example, it is /src/index.js. The output file is the compiled version – dist/main.js.
browse this document for more details. We’ll talk plugins and loaders in another lesson.
Now that we (sorta) understand what webpack is doing it’s time to discuss the module syntax. There are only 2 components to it – import and export.
Take a moment to look at the docs for import and export.
Of course, the import statement is the same thing that you used during the webpack tutorial! These things are simple to use.
// a file called functionOne.js
const functionOne = () => console.log('FUNCTION ONE!')
export { functionOne }
// another JS file
import { functionOne } from './functionOne'
functionOne() //this should work as expected!
There are many benefits to writing your code in modules. One of the most compelling is code reuse. If, for instance, you have written some functions that manipulate the DOM in a specific way, putting all of those into their own file as a ‘module’ means that you can copy that file and re-use it very easily!
Other benefits include all of the benefits to wrapping your code in factory functions or using the module pattern (the module pattern and ES6 modules are not the same things.. this naming convention is frustrating). By using ES6 modules you can keep different parts of your code cleanly separated, which makes writing and maintaining your code much easier and less error-prone. Keep in mind that you can definitely export constructors, classes and factory functions from your modules.
To pull it all together, let’s write a simple module and then include it in our code. We are going to continue from where the webpack tutorial left off. Before beginning your file directory should look something like this:
and you should be able to bundle and run webpack by simply typing npx webpack in the terminal.
Add a new file to the src directory called myName.js with the following contents:
const myName = (name) => 'Hi! My name is ' + name;
export default myName
and then in src/index.js import and use your new function.
// import your function
import myName from './myName';
function component() {
var element = document.createElement('div');
// use your function!
element.innerHTML = myName('Cody');
return element;
}
document.body.appendChild(component());
Easy! Now, if you run npx webpack in your project directory your page should show our new function being used.
There are 2 different ways to use exports in your code: named exports and default exports. Which option you use depends on what you’re exporting. As a general rule if you want to export multiple functions use named exports with this pattern:
import {functionOne, functionTwo} from './myModule'
Using this pattern gives you the freedom to only import the functions you need in the various files of your program. So it’s perfectly fine to only import functionOne if that’s the only one you need.
The various import/export methods are best explained in the docs that we linked earlier – import and export.
JavaScript does not have classes in the same sense as other Object Oriented languages like Java or Ruby. ES6, however, did introduce a syntax for object creation that uses the class keyword. It is basically a new syntax that does the exact same thing as the object constructors and prototypes we learned about in the constructor lesson.
Since we’ve already gone fairly in-depth with Constructors, you don’t have too much left to learn here beyond the new syntax. If you choose to use classes in your code (that’s fine!) you can use them much the same way as object constructors.
This article provides some pros and cons for classes. There are many people who think that class syntax is misleading for Javascript, and thus Factory Functions (from the previous lesson) are inherently better. WE are not saying that classes are bad! We just want you to be informed on the opinions of both sides.
This article is probably just about all you need to start using class syntax confidently. "Getters and Setters" are a useful feature!
The MDN docs are, as usual, a great resource for going a little deeper. Look especially at the ‘extends’ and ‘Mixins’ sections. React (and other frameworks) uses classes in this way. You create your components and make them extend the core React component which gives you access to all their built-in functionality.
Go back to your "Library" example and refactor it to use class instead of plain constructors. Work on a new branch on the Exercises repository, create a new Pull Request and submit its URL to the Quiz below.
Set up your project with a HTML, CSS and Javascript files and get the Git repo all set up.
You’re going to store the gameboard as an array inside of a Gameboard object, so start there! Your players are also going to be stored in objects… and you’re probably going to want an object to control the flow of the game itself.
Your main goal here is to have as little global code as possible. Try tucking everything away inside of a module or factory. Rule of thumb: if you only ever need ONE of something (gameBoard, displayController), use a module. If you need multiples of something (players!), create them with factories.
Set up your HTML and write a JavaScript function that will render the contents of the gameboard array to the webpage (for now you can just manually fill in the array with "X"s and "O"s)
Build the functions that allow players to add marks to a specific spot on the board, and then tie it to the DOM, letting players click on the gameboard to place their marker. Don’t forget the logic that keeps players from playing in spots that are already taken!
Think carefully about where each bit of logic should reside. Each little piece of functionality should be able to fit in the game, player or gameboard objects.. but take care to put them in "logical" places. Spending a little time brainstorming here can make your life much easier later!
Build the logic that checks for when the game is over! Should check for 3-in-a-row and a tie.
Clean up the interface to allow players to put in their names, include a button to start/restart the game and add a display element that congratulates the winning player!
Optional – If you’re feeling ambitious create an AI so that a player can play against the computer!
Start by just getting the computer to make a random legal move.
Once you’ve gotten that, work on making the computer smart. It is possible to create an unbeatable AI using the minimax algorithm (read about it here, some googling will help you out with this one)
If you get this running definitely come show it off in the chatroom. It’s quite an accomplishment!
If you haven’t already, set up your project with skeleton HTML/CSS and JS files.
All of your book objects are going to be stored in a simple array, so add a function to the script (not the constructor) that can take user’s input and store the new book objects into an array. Your code should look something like this:
let myLibrary = [];
function Book() {
// the constructor...
}
function addBookToLibrary() {
// do stuff here
}
Hook the array up to your HTML with a render() function that loops through the array and displays each book on the page. You can display them in some sort of table, or each on their own "card". It might help for now to manually add a few books to your array so you can see the display.
Add a "NEW BOOK" button that brings up a form allowing users to input the details for the new book: author, title, number of pages, whether it’s been read and anything else you might want.
Add a button on each book’s display to remove the book from the library.
You will need to associate your DOM elements with the actual book objects in some way. One easy solution is giving them a data-attribute that corresponds to the index of the library array.
Add a button on each book’s display to change its read status.
To facilitate this you will want to create the function that toggles a book’s read status on your Book prototype instance.
Optional -we haven’t learned any techniques for actually storing our data anywhere, so when the user refreshes the page all of their books will disappear! If you want, you are capable of adding some persistence to this library app using one of the following techniques:
localStorage (docs here) allows you to save data on the user’s computer. The downside here is that the data is ONLY accessible on the computer that it was created on. Even so, it’s pretty handy! Set up a function that saves the whole library array to localStorage every time a new book is created, and another function that looks for that array in localStorage when your app is first loaded. (make sure your app doesn’t crash if the array isn’t there!)
Read the instructions in the Exercises GitHub repository, create a new branch for this exercise, create a Pull Request and submit its URL in the Quiz below.
LOOKING FOR HELP?
When looking for help, try doing so in the following order:
In our JavaScript fundamentals course, you should have learned the basics of using objects to store and retrieve data. Let’s start with a little refresher.
There are multiple ways to define objects but in most cases, it is best to use the object literal syntax as follows:
Which method you use will depend on context. Dot notation is cleaner and is usually preferred, but there are plenty of circumstances when it is not possible to use it. For example, myObject."obnoxious property" won’t work because that property is a string with a space in it. Likewise, you can not use variables in dot notation:
const variable = 'property'
myObject.variable // this gives us 'undefined' because it's looking for a property named 'variable' in our object
myObject[variable] // this is equivalent to myObject['property'] and returns 'Value!'
If you are feeling rusty on using objects, now might be a good time to go back and review the content in Fundamentals 5 from our JavaScript 101 course.
One of the simplest ways you can begin to organize your code is by simply grouping things into objects. Take these examples from a ‘tic tac toe’ game:
// example one
const playerOneName = "tim"
const playerTwoName = "jenn"
const playerOneMarker = "X"
const playerTwoMarker = "O"
// example two
const playerOne = {
name: "tim",
marker: "X"
}
const playerTwo = {
name: "jenn",
marker: "O"
}
At first glance, the first doesn’t seem so bad.. and it actually takes fewer lines to write than the example using objects, but the benefits are huge! Let me demonstrate:
function printName(player) {
console.log(player.name)
}
This is something that you just could NOT do with the example one setup. Instead, every time you wanted to print a specific player’s name you would have to remember the correct variable name and then manually console.log it:
Again, this isn’t that bad… but what if you don’t know which player’s name you want to print?
function gameOver(winningPlayer){
console.log("Congratulations!")
console.log(winningPlayer.name + " is the winner!")
}
Or, what if we aren’t making a 2 player game, but something more complicated such as an online shopping site with a large inventory? In that case, using objects to keep track of an item’s name, price, description and other things is the only way to go. Unfortunately, in that type of situation manually typing out the contents of our objects is not feasible either. We need a cleaner way to create our objects, which brings us to…
When you have a specific type of object that you need to duplicate like our player or inventory items a better way to create them is using an object constructor, which is a function that looks like this:
function Player(name, marker) {
this.name = name
this.marker = marker
}
and which you use by calling the function with the keyword new.
const player = new Player('steve', 'X')
console.log(player.name) // 'steve'
Just like with objects created using the Object Literal method you can add functions to the object:
function Player(name, marker) {
this.name = name
this.marker = marker
this.sayName = function() {
console.log(name)
}
}
const player1 = new Player('steve', 'X');
const player2 = new Player('also steve', 'O');
player1.sayName(); // logs 'steve'
player2.sayName(); // logs 'also steve'
Write a constructor for making "book" objects. We will revisit this in the project at the end of this lesson. Your book objects should have the book’s title, author, the number of pages, and whether or not you have read the book
Put a function into the constructor that can report the book info like so
book.info() // "The Hobbit by J.R.R. Tolkien, 295 pages, not read yet"
note: it is almost always best to return things rather than putting console.log() directly into the function. In this case, return the info string and log it after the function has been called:
console.log(theHobbit.info());
Use the Exercises GitHub repository for the exercises of this lesson. You will have to create a new branch named js-object-constructors, create a Pull Request and submit its URL in the Quiz at the bottom of this page.
Before we go much further, there’s something important you need to understand about JavaScript objects. All objects in JavaScript have a prototype. Stated simply, the prototype is another object that the original object inherits from, which is to say, the original object has access to all of its prototype’s methods and properties.
This concept is an important one, so you’ve got some reading to do. Make sure you really get this before moving on!
This article is a straightforward introduction and demonstration of the concept. It also covers constructors again.. good time for a review! The important bits here, once you’ve covered the basics are ‘Prototype-based inheritance’ and the ‘Prototype chain’
Watch this 8-minute quick introduction to the Prototype by Net Ninja:
To go a bit deeper into both the chain and inheritance spend some time with this great article. As usual, doing the exercises at the end will help cement this knowledge in your mind. Don’t skip them! Important note: this article makes heavy use of __proto__ which is not generally recommended. The concepts here are what we’re looking for at the moment. We will soon learn another method or two for setting the prototype.
If you’ve understood the concept of the prototype then this next bit about constructors will not be confusing at all!
function Student(name, grade) {
this.name = name
this.grade = grade
}
Student.prototype.sayName = function() {
console.log(this.name)
}
Student.prototype.goToProm = function() {
// eh.. go to prom?
}
If you’re using constructors to make your objects it is best to define functions on the prototype of that object. Doing so means that a single instance of each function will be shared between all of the Student objects. If we declare the function directly in the constructor like we did when they were first introduced that function would be duplicated every time a new Student is created. In this example, that wouldn’t really matter much, but in a project that is creating thousands of objects, it really can make a difference.
Recommended Method for Prototypal Inheritance
So far you have seen several ways of making an object inherit the prototype from another object. At this point in history, the recommended way of setting the prototype of an object is Object.create ( here is the documentation for that method.) Object.create very simply returns a new object with the specified prototype and any additional properties you want to add. For our purposes you use it like so:
function Student() {
}
Student.prototype.sayName = function() {
console.log(this.name)
}
function EighthGrader(name) {
this.name = name
this.grade = 8
}
EighthGrader.prototype = Object.create(Student.prototype)
const carl = new EighthGrader("carl")
carl.sayName() // console.logs "carl"
carl.grade // 8
You can probably figure out what’s going on here. After creating the constructor for EighthGrader we set it’s prototype to a new object that has a copy of Student.prototype.
A warning… this doesn’t work:
EighthGrader.prototype = Student.prototype
because it will literally set EighthGrader’s prototype to Student.prototype (i.e. not a copy), which could cause problems if you want to edit something in the future. Consider one more example:
function Student() {
}
Student.prototype.sayName = function() {
console.log(this.name)
}
function EighthGrader(name) {
this.name = name
this.grade = 8
}
// don't do this!!!
EighthGrader.prototype = Student.prototype
function NinthGrader(name) {
this.name = name
this.grade = 9
}
// noooo! not again!
NinthGrader.prototype = Student.prototype
NinthGrader.prototype.sayName = function() {console.log("HAHAHAHAHAHA")}
const carl = new EighthGrader("carl")
carl.sayName() //uh oh! this logs "HAHAHAHAHAHA" because we edited the sayName function!
If we had used Object.create in this example then we could safely edit the NinthGrader.prototype.sayName function without changing the function for EighthGrader as well.
Use the Exercises GitHub repository for the exercises of this lesson. You will have to create a new branch named js-object-constructors, create a Pull Request and submit its URL in the Quiz below.
LOOKING FOR HELP?
When looking for help, try doing so in the following order:
One of the most daunting parts of JavaScript is learning how to organize your code. The reason this subject can be so overwhelming is not because JavaScript is so much more complex than other languages, but because it is incredibly forgiving! Many languages force you into using specific patterns and data structures in your code but that is not true in JavaScript.
In the beginning, this is a great thing! For example, if you just want to make a simple button on your webpage do something you can set that up in a couple lines of code. However, as your program becomes more complex, it can become hard to maintain unless you take care to organize your code and because JavaScript is such a flexible language how you do that is entirely up to you. For many coders making decisions about design patterns is crippling so we’re here to help.
This lesson series is going to cover a few of the most common design patterns that occur in modern JavaScript code, we will discuss some pros and cons of each pattern and will give you a chance to practice using each pattern in a project.
The patterns we’ll be covering in this series are:
Plain Old JavaScript Objects and Object Constructors
Factory Functions and the Module Pattern
Classes
ES6 Modules
Going through these will give us a chance to learn about a few other important concepts in JavaScript such as "closure", "prototypes", "IIFEs" and more! This series covers the most important parts of JavaScript after simply learning the basics of the language… are you ready?
Probably the best companion to JavaScript is the books series You Don’t Know JS by Kyle Simpson. You can find the books online at this GitHub repository. If you are looking to become a good JavaScript developer, you must -at least- read the Up & Going, Types & Grammar and this & Object Prototypes books of the series, which are highly recommended.
LOOKING FOR HELP?
When looking for help, try doing so in the following order:
By now you should have already learned a fair amount of techniques and had lot of practice using those techniques. However we have throwing you a lot of information and thus we will take a minute to slow down and work on a project, before we move on learning new stuff.
In this project you will build a todo list. Todo lists are simple enough and that’s why they have been a staple in beginning webdev tutorials. Having said that there are a lot of room for improvement and many features that can be added.