1. It gives structure to MongoDB Collections
2. It gives you helpful methods to use

In this article, we'll go through:

1. The basics of using Mongoose
2. Mongoose subdocuments
3. Mongoose population

By the end of the article, you should be able to use Mongoose without problems.

Prerequisites

I assume you have done the following:

1. You have installed MongoDB on your computer
2. You know how to set up a local MongoDB connection
3. You know how to see the data you have in your database
4. You know what "collections" are in MongoDB

If you don't know any of these, please read "How to set up a local MongoDB connection" before you continue.

I also assume you know how to use MongoDB to create a simple CRUD app. If you don't know how to do this, please read "How to build a CRUD app with Node, Express, and MongoDB" before you continue.

Mongoose Basics

Here, you'll learn how to:

1. Connect to the database
2. Create a Model
3. Create a Document
4. Find a Document
5. Update a Document
6. Delete a Document

Connecting to a database

First, you need to download Mongoose.

npm install mongoose --save

You can connect to a database with the connect method. Let's say we want to connect to a database called street-fighters. Here's the code you need:

const mongoose = require('mongoose')
const url = 'mongodb://127.0.0.1:27017/street-fighters'

mongoose.connect(url, { useNewUrlParser: true })

We want to know whether our connection has succeeded or failed. This helps us with debugging.

To check whether the connection has succeeded, we can use the open event. To check whether the connection failed, we use the error event.

const db = mongoose.connection
db.once('open', _ => {
  console.log('Database connected:', url)
})

db.on('error', err => {
  console.error('connection error:', err)
})

Try connecting to the database. You should see a log like this:

Creating a Model

In Mongoose, you need to use models to create, read, update, or delete items from a MongoDB collection.

To create a Model, you need to create a Schema. A Schema lets you define the structure of an entry in the collection. This entry is also called a document.

Here's how you create a schema:

const mongoose = require('mongoose')
const Schema = mongoose.Schema

const schema = new Schema({
  // ...
})

You can use 10 different kinds of values in a Schema. Most of the time, you'll use these six:

• String
• Number
• Boolean
• Array
• Date
• ObjectId

Let's put this into practice.

Say we want to create characters for our Street Fighter database.

In Mongoose, it's a normal practice to put each model in its own file. So we will create a Character.js file first. This Character.js file will be placed in the models folder.

project/
    |- models/
        |- Character.js

In Character.js, we create a characterSchema.

const mongoose = require('mongoose')
const Schema = mongoose.Schema

const characterSchema = new Schema({
  // ...
})

Let's say we want to save two things into the database:

1. Name of the character
2. Name of their ultimate move

Both can be represented with Strings.

const mongoose = require('mongoose')
const Schema = mongoose.Schema

const characterSchema = new Schema({
  name: String,
  ultimate: String
})

Once we've created characterSchema, we can use mongoose's model method to create the model.

module.exports = mongoose.model('Character', characterSchema)

Creating a document

Let's say you have a file called index.js. This is where we'll perform Mongoose operations for this tutorial.

project/
    |- index.js
    |- models/
        |- Character.js

First, you need to load the Character model. You can do this with require.

const Character = require('./models/Character')

Let's say you want to create a character called Ryu. Ryu has an ultimate move called "Shinku Hadoken".

To create Ryu, you use the new, followed by your model. In this case, it's new Character.

const ryu = new Character ({
  name: 'Ryu',
  ultimate: 'Shinku Hadoken'
})

new Character creates the character in memory. It has not been saved to the database yet. To save to the database, you can run the save method.

ryu.save(function (error, document) {
  if (error) console.error(error)
  console.log(document)
})

If you run the code above, you should see this in the console.

Promises and Async/await

Mongoose supports promises. It lets you write nicer code like this:

// This does the same thing as above
function saveCharacter (character) {
  const c = new Character(character)
  return c.save()
}

saveCharacter({
  name: 'Ryu',
  ultimate: 'Shinku Hadoken'
})
  .then(doc => { console.log(doc) })
  .catch(error => { console.error(error) })

You can also use the await keyword if you have an asynchronous function.

If the Promise or Async/Await code looks foreign to you, I recommend reading "JavaScript async and await" before continuing with this tutorial.

async function runCode() {
  const ryu = new Character({
    name: 'Ryu',
    ultimate: 'Shinku Hadoken'
  })

  const doc = await ryu.save()
  console.log(doc)
}

runCode()
  .catch(error => { console.error(error) })

Note: I'll use the async/await format for the rest of the tutorial.

Uniqueness

Mongoose adds a new character to the database each time you use new Character and save. If you run the code(s) above three times, you'd expect to see three Ryus in the database.

We don't want to have three Ryus in the database. We want to have ONE Ryu only. To do this, we can use the unique option.

const characterSchema = new Schema({
  name: { type: String, unique: true },
  ultimate: String
})

The unique option creates a unique index. It ensures that we cannot have two documents with the same value (for name in this case).

For unique to work properly, you need to clear the Characters collection. To clear the Characters collection, you can use this:

await Character.deleteMany({})

Try to add two Ryus into the database now. You'll get an E11000 duplicate key error. You won't be able to save the second Ryu.

Let's add another character into the database before we continue the rest of the tutorial.

const ken = new Character({
  name: 'Ken',
  ultimate: 'Guren Enjinkyaku'
})

await ken.save()

Finding a document

Mongoose gives you two methods to find stuff from MongoDB.

1. findOne: Gets one document.
2. find: Gets an array of documents

findOne

findOne returns the first document it finds. You can specify any property to search for. Let's search for Ryu:

const ryu = await Character.findOne({ name: 'Ryu' })
console.log(ryu)

find

find returns an array of documents. If you specify a property to search for, it'll return documents that match your query.

const chars = await Character.find({ name: 'Ryu' })
console.log(chars)

If you did not specify any properties to search for, it'll return an array that contains all documents in the collection.

const chars = await Character.find()
console.log(chars)

Updating a document

Let's say Ryu has three special moves:

1. Hadoken
2. Shoryuken
3. Tatsumaki Senpukyaku

We want to add these special moves into the database. First, we need to update our CharacterSchema.

const characterSchema = new Schema({
  name: { type: String, unique: true },
  specials: Array,
  ultimate: String
})

Then, we use one of these two ways to update a character:

1. Use findOne, then use save
2. Use findOneAndUpdate

findOne and save

First, we use findOne to get Ryu.

const ryu = await Character.findOne({ name: 'Ryu' })
console.log(ryu)

Then, we update Ryu to include his special moves.

const ryu = await Character.findOne({ name: 'Ryu' })
ryu.specials = [
  'Hadoken',
  'Shoryuken',
  'Tatsumaki Senpukyaku'
]

After we modified ryu, we run save.

const ryu = await Character.findOne({ name: 'Ryu' })
ryu.specials = [
  'Hadoken',
  'Shoryuken',
  'Tatsumaki Senpukyaku'
]

const doc = await ryu.save()
console.log(doc)

findOneAndUpdate

findOneAndUpdate is the same as MongoDB's findOneAndModify method.

Here, you search for Ryu and pass the fields you want to update at the same time.

// Syntax
await findOneAndUpdate(filter, update)

// Usage
const doc = await Character.findOneAndUpdate(
  { name: 'Ryu' },
  {
    specials: [
      'Hadoken',
      'Shoryuken',
      'Tatsumaki Senpukyaku'
    ]
  })

console.log(doc)

Difference between findOne + save vs findOneAndUpdate

Two major differences.

First, the syntax for findOne` + `save is easier to read than findOneAndUpdate.

Second, findOneAndUpdate does not trigger the save middleware.

I'll choose findOne + save over findOneAndUpdate anytime because of these two differences.

Deleting a document

There are two ways to delete a character:

1. findOne + remove
2. findOneAndDelete

Using findOne + remove

const ryu = await Character.findOne({ name: 'Ryu' })
const deleted = await ryu.remove()

Using findOneAndDelete

const deleted = await Character.findOneAndDelete({ name: 'Ken' })

Subdocuments

In Mongoose, subdocuments are documents that are nested in other documents. You can spot a subdocument when a schema is nested in another schema.

Note: MongoDB calls subdocuments embedded documents.

const childSchema = new Schema({
  name: String
});

const parentSchema = new Schema({
  // Single subdocument
  child: childSchema,

  // Array of subdocuments
  children: [ childSchema ]
});

In practice, you don't have to create a separate childSchema like the example above. Mongoose helps you create nested schemas when you nest an object in another object.

// This code is the same as above
const parentSchema = new Schema({
  // Single subdocument
  child: { name: String },

  // Array of subdocuments
  children: [{name: String }]
});

In this section, you will learn to:

1. Create a schema that includes a subdocument
2. Create documents that contain subdocuments
3. Update subdocuments that are arrays
4. Update a single subdocument

Updating characterSchema

Let's say we want to create a character called Ryu. Ryu has three special moves.

1. Hadoken
2. Shinryuken
3. Tatsumaki Senpukyaku

Ryu also has one ultimate move called:

1. Shinku Hadoken

We want to save the names of each move. We also want to save the keys required to execute that move.

Here, each move is a subdocument.

const characterSchema = new Schema({
  name: { type: String, unique: true },
  // Array of subdocuments
  specials: [{
    name: String,
    keys: String
  }]
  // Single subdocument
  ultimate: {
    name: String,
    keys: String
  }
})

You can also use the childSchema syntax if you wish to. It makes the Character schema easier to understand.

const moveSchema = new Schema({
  name: String,
  keys: String
})

const characterSchema = new Schema({
  name: { type: String, unique: true },
  // Array of subdocuments
  specials: [moveSchema],
  // Single subdocument
  ultimate: moveSchema
})

Creating documents that contain subdocuments

There are two ways to create documents that contain subdocuments:

1. Pass a nested object into new Model
2. Add properties into the created document.

Method 1: Passing the entire object

For this method, we construct a nested object that contains both Ryu's name and his moves.

const ryu = {
  name: 'Ryu',
  specials: [{
    name: 'Hadoken',
    keys: '↓ ↘ → P'
  }, {
    name: 'Shoryuken',
    keys: '→ ↓ ↘ → P'
  }, {
    name: 'Tatsumaki Senpukyaku',
    keys: '↓ ↙ ← K'
  }],
  ultimate: {
    name: 'Shinku Hadoken',
    keys: '↓ ↘ → ↓ ↘ → P'
  }
}

Then, we pass this object into new Character.

const char = new Character(ryu)
const doc = await char.save()
console.log(doc)

Method 2: Adding subdocuments later

For this method, we create a character with new Character first.

const ryu = new Character({ name: 'Ryu' })

Then, we edit the character to add special moves:

const ryu = new Character({ name: 'Ryu' })
const ryu.specials = [{
  name: 'Hadoken',
  keys: '↓ ↘ → P'
}, {
  name: 'Shoryuken',
  keys: '→ ↓ ↘ → P'
}, {
  name: 'Tatsumaki Senpukyaku',
  keys: '↓ ↙ ← K'
}]

Then, we edit the character to add the ultimate move:

const ryu = new Character({ name: 'Ryu' })

// Adds specials
const ryu.specials = [{
  name: 'Hadoken',
  keys: '↓ ↘ → P'
}, {
  name: 'Shoryuken',
  keys: '→ ↓ ↘ → P'
}, {
  name: 'Tatsumaki Senpukyaku',
  keys: '↓ ↙ ← K'
}]

// Adds ultimate
ryu.ultimate = {
  name: 'Shinku Hadoken',
  keys: '↓ ↘ → ↓ ↘ → P'
}

Once we're satisfied with ryu, we run save.

const ryu = new Character({ name: 'Ryu' })

// Adds specials
const ryu.specials = [{
  name: 'Hadoken',
  keys: '↓ ↘ → P'
}, {
  name: 'Shoryuken',
  keys: '→ ↓ ↘ → P'
}, {
  name: 'Tatsumaki Senpukyaku',
  keys: '↓ ↙ ← K'
}]

// Adds ultimate
ryu.ultimate = {
  name: 'Shinku Hadoken',
  keys: '↓ ↘ → ↓ ↘ → P'
}

const doc = await ryu.save()
console.log(doc)

Updating array subdocuments

The easiest way to update subdocuments is:

1. Use findOne to find the document
2. Get the array
3. Change the array
4. Run save

For example, let's say we want to add Jodan Sokutou Geri to Ryu's special moves. The keys for Jodan Sokutou Geri are ↓ ↘ → K.

First, we find Ryu with findOne.

const ryu = await Characters.findOne({ name: 'Ryu' })

Mongoose documents behave like regular JavaScript objects. We can get the specials array by writing ryu.specials.

const ryu = await Characters.findOne({ name: 'Ryu' })
const specials = ryu.specials
console.log(specials)

This specials array is a normal JavaScript array.

const ryu = await Characters.findOne({ name: 'Ryu' })
const specials = ryu.specials
console.log(Array.isArray(specials)) // true

We can use the push method to add a new item into specials,

const ryu = await Characters.findOne({ name: 'Ryu' })
ryu.specials.push({
  name: 'Jodan Sokutou Geri',
  keys: '↓ ↘ → K'
})

After updating specials, we run save to save Ryu to the database.

const ryu = await Characters.findOne({ name: 'Ryu' })
ryu.specials.push({
  name: 'Jodan Sokutou Geri',
  keys: '↓ ↘ → K'
})

const updated = await ryu.save()
console.log(updated)

Updating a single subdocument

It's even easier to update single subdocuments. You can edit the document directly like a normal object.

Let's say we want to change Ryu's ultimate name from Shinku Hadoken to Dejin Hadoken. What we do is:

1. Use findOne to get Ryu.
2. Change the name in ultimate
3. Run save

const ryu = await Characters.findOne({ name: 'Ryu' })
ryu.ultimate.name = 'Dejin Hadoken'

const updated = await ryu.save()
console.log(updated)

Population

MongoDB documents have a size limit of 16MB. This means you can use subdocuments (or embedded documents) if they are small in number.

For example, Street Fighter characters have a limited number of moves. Ryu only has 4 special moves. In this case, it's okay to use embed moves directly into Ryu's character document.

But if you have data that can contain an unlimited number of subdocuments, you need to design your database differently.

One way is to create two separate models and combine them with populate.

Creating the models

Let's say you want to create a blog. And you want to store the blog content with MongoDB. Each blog has a title, content, and comments.

Your first schema might look like this:

const blogPostSchema = new Schema({
  title: String,
  content: String,
  comments: [{
    comment: String
  }]
})

module.exports = mongoose.model('BlogPost', blogPostSchema)

There's a problem with this schema.

A blog post can have an unlimited number of comments. If a blog post explodes in popularity and comments swell up, the document might exceed the 16MB limit imposed by MongoDB.

This means we should not embed comments in blog posts. We should create a separate collection for comments.

const comments = new Schema({
  comment: String
})

module.exports = mongoose.model('Comment', commentSchema)

In Mongoose, we can link up the two models with Population.

To use Population, we need to:

1. Set type of a property to Schema.Types.ObjectId
2. Set ref to the model we want to link too.

Here, we want comments in blogPostSchema to link to the Comment collection. This is the schema we'll use:

const blogPostSchema = new Schema({
  title: String,
  content: String,
  comments: [{ type: Schema.Types.ObjectId, ref: 'Comment' }]
})

module.exports = mongoose.model('BlogPost', blogPostSchema)

Creating a blog post

Let's say you want to create a blog post. To create the blog post, you use new BlogPost.

const blogPost = new BlogPost({
  title: 'Weather',
  content: `How's the weather today?`
})

A blog post can have zero comments. We can save this blog post with save.

const doc = await blogPost.save()
console.log(doc)

Creating comments

Now let's say we want to create a comment for the blog post. To do this, we create and save the comment.

const comment = new Comment({
  comment: `It's damn hot today`
})

const savedComment = await comment.save()
console.log(savedComment)

Notice the saved comment has an _id attribute. We need to add this _id attribute into the blog post's comments array. This creates the link.

// Saves comment to Database
const savedComment = await comment.save()

// Adds comment to blog post
// Then saves blog post to database
const blogPost = await BlogPost.findOne({ title: 'Weather' })
blogPost.comments.push(savedComment._id)
const savedPost = await blogPost.save()
console.log(savedPost)

Searching blog posts and their comments

If you tried to search for the blog post, you'll see the blog post has an array of comment IDs.

const blogPost = await BlogPost.findOne({ title: 'Weather' })
console.log(blogPost)

There are four ways to get comments.

1. Mongoose population
2. Manual way #1
3. Manual way #2
4. Manual way #3

Mongoose Population

Mongoose allows you to fetch linked documents with the populate method. What you need to do is call .populate when you execute with findOne.

When you call populate, you need to pass in the key of the property you want to populate. In this case, the key is comments. (Note: Mongoose calls this key a "path").

const blogPost = await BlogPost.findOne({ title: 'Weather' })
  .populate('comments')
console.log(blogPost)

Manual way (method 1)

Without Mongoose Populate, you need to find the comments manually. First, you need to get the array of comments.

const blogPost = await BlogPost.findOne({ title: 'Weather' })
  .populate('comments')
const commentIDs = blogPost.comments

Then, you loop through commentIDs to find each comment. If you go with this method, it's slightly faster to use Promise.all.

const commentPromises = commentIDs.map(_id => {
  return Comment.findOne({ _id })
})
const comments = await Promise.all(commentPromises)
console.log(comments)

Manual way (method 2)

Mongoose gives you an $in operator. You can use this $in operator to find all comments within an array. This syntax takes a little effort to get used to.

If I had to do the manual way, I'd prefer Manual #1 over this.

const commentIDs = blogPost.comments
const comments = await Comment.find({
    '_id': { $in: commentIDs }
})

console.log(comments)

Manual way (method 3)

For the third method, we need to change the schema. When we save a comment, we link the comment to the blog post.

// Linking comments to blog post
const commentSchema = new Schema({
  comment: String
  blogPost: [{ type: Schema.Types.ObjectId, ref: 'BlogPost' }]
})

module.exports = mongoose.model('Comment', commentSchema)

You need to save the comment into the blog post, and the blog post id into the comment.

const blogPost = await BlogPost.findOne({ title: 'Weather' })

// Saves comment
const comment = new Comment({
  comment: `It's damn hot today`,
  blogPost: blogPost._id
})
const savedComment = comment.save()

// Links blog post to comment
blogPost.comments.push(savedComment._id)
await blogPost.save()

Once you do this, you can search the Comments collection for comments that match your blog post's id.

// Searches for comments
const blogPost = await BlogPost.findOne({ title: 'Weather' })
const comments = await Comment.find({ _id: blogPost._id })
console.log(comments)

I'd prefer Manual #3 over Manual #1 and Manual #2.

And Population beats all three manual methods.

Quick Summary

You learned to use Mongoose on three different levels in this article:

1. Basic Mongoose
2. Mongoose subdocuments
3. Mongoose population

That's it!

Thanks for reading. This article was originally posted on my blog. Sign up for my newsletter if you want more articles to help you become a better frontend developer.

Setting up the test was the hard part. People who write about tests don't actually teach you how they set it up. I could not find any useful information about this, and I had to try and figure it out.

So today, I want to share the setup I created for myself. Hopefully, this can help you when you create your own tests.

Table of Contents

1. Setting up Jest and Supertest
2. Connecting Jest and Mongoose
3. Seeding a database

Setting up Jest and Supertest

First, let's talk about the stack.

The Stack

• I created my app with Express.
• I used Mongoose to connect to MongoDB
• I used Jest as my test framework.

You might have expected Express and Mongoose because everyone else seems to use those two frameworks. I used them too.

But why Jest and not other test frameworks?

Why Jest

I don't like Facebook, so I didn't want to try anything that was created by Facebook's team. I know it sounds silly, but that was the truth.

Before Jest, I tried out all sorts of test frameworks. I tried Tap, Tape, Mocha, Jasmine, and AVA. Each test framework has its own pros and cons. I almost ended up with AVA, but I didn't go with AVA because I found it hard to set up. Eventually, I tried Jest out because Kent C. Dodds recommended it.

I fell in love with Jest after trying it out. I love it because:

1. It's easy to setup
2. The watch-mode is amazing
3. When you console.log something, it actually shows up without any difficulty (this was a bitch with AVA).

Setting up Jest

First, you need to install Jest.

npm install jest --save-dev

Next, you want to add tests scripts to your package.json file. It helps to add the test and test:watch scripts (for one-off testing and watch-mode respectively).

"scripts": {
  "test": "jest",
  "test:watch": "jest --watch"
},

You can choose to write your test files in one of the following formats. Jest picks them up for you automatically.

1. js files in the __tests__ folder
2. files named with test.js (like user.test.js)
3. files named with spec.js (like user.spec.js)

You can place your files however you like. When I tested endpoints, I put the test files together with my endpoints. I found this easier to manage.

- routes
  |- users/
    |- index.js
    |- users.test.js

Writing your first test

Jest includes describe, it and expect for you in every test file. You don't have to require them.

• describe lets you wrap many tests together under one umbrella. (It is used for organizing your tests).
• it lets you run a test.
• expect lets you perform assertions. The test passes if all assertions passes.

Here's an example of a test that fails. In this example, I expect that 1 should be strictly equal to 2. Since 1 !== 2, the test fails.

// This test fails because 1 !== 2
it("Testing to see if Jest works", () => {
  expect(1).toBe(2);
});

You'll see a failing message from Jest if you run Jest.

npm run test:watch

You can make the test pass by expecting 1 === 1.

// This passes because 1 === 1
it("Testing to see if Jest works", () => {
  expect(1).toBe(1);
});

This is the most basic of tests. It's not useful at all because we haven't testing anything real yet.

Asynchronous tests

You need to send a request to test an endpoint. Requests are asynchronous, which means you must be able to conduct asynchronous tests.

This is easy with Jest. There are two steps:

1. Add the async keyword
2. Call done when you're done with your tests

Here's what it can look like:

it("Async test", async done => {
  // Do your async tests here

  done();
});

Note: Here's an article on Async/await in JavaScript if you don't know how to use it.

Testing Endpoints

You can use Supertest to test endpoints. First, you need to install Supertest.

npm install supertest --save-dev

Before you can test endpoints, you need to setup the server so Supertest can use it in your tests.

Most tutorials teach you to listen to the Express app in the server file, like this:

const express = require("express");
const app = express();

// Middlewares...
// Routes...

app.listen(3000);

This doesn't work because it starts listening to one port. If you try to write many test files, you'll get an error that says "port in use".

You want to allow each test file to start a server on their own. To do this, you need to export app without listening to it.

// server.js
const express = require("express");
const app = express();

// Middlewares...
// Routes...

module.exports = app;

For development or production purposes, you can listen to your app like normal in a different file like start.js.

// start.js
const app = require("./server.js");
app.listen(3000);

Using Supertest

To use Supertest, you require your app and supertest in the test file.

const app = require("./server"); // Link to your server file
const supertest = require("supertest");
const request = supertest(app);

Once you do this, you get the ability to send GET, POST, PUT, PATCH and DELETE requests. Before we send a request, we need to have an endpoint. Let's say we have a /test endpoint.

app.get("/test", async (req, res) => {
  res.json({ message: "pass!" });
});

To send a GET request to /test, you use the .get method from Supertest.

it("Gets the test endpoint", async done => {
  // Sends GET Request to /test endpoint
  const res = await request.get("/test");

  // ...
  done();
});

Supertest gives you a response from the endpoint. You can test both HTTP status and the body (whatever you send through res.json) like this:

it("gets the test endpoint", async done => {
  const response = await request.get("/test");

  expect(response.status).toBe(200);
  expect(response.body.message).toBe("pass!");
  done();
});

Connecting Jest and Mongoose

The hard part about testing a backend application is setting up a test database. It can be complicated.

Today, I want to share how I setup Jest and Mongoose.

Setting up Mongoose with Jest

Jest gives you a warning if you try to use Mongoose with Jest.

If you don't want to see this error, you need to set testEnvironment to node in your package.json file.

"jest": {
  "testEnvironment": "node"
}

Setting up Mongoose in a test file

You want to connect to a database before you begin any tests. You can use the beforeAll hook to do so.

beforeAll(async () => {
  // Connect to a Mongo DB
});

To connect to a MongoDB, you can use Mongoose's connect command.

const mongoose = require("mongoose");
const databaseName = "test";

beforeAll(async () => {
  const url = `mongodb://127.0.0.1/${databaseName}`;
  await mongoose.connect(url, { useNewUrlParser: true });
});

This creates a connection to the database named test. You can name your database anything. You'll learn how to clean them up later.

Note: Make sure you have an active local MongoDB Connection before you test. Your tests will fail if you don't have an active local MongoDB Connection. Read this to learn how to create a local MongoDB connection.

Creating databases for each test file

When you test, you want to connect to a different database for each test file, because:

1. Jest runs each test file asynchronously. You won't know which file comes first.
2. You don't want tests to share the same database. You don't want data from one test file to spill over to the next test file.

To connect to a different database, you change the name of the database.

// Connects to database called avengers
beforeAll(async () => {
  const url = `mongodb://127.0.0.1/avengers`;
  await mongoose.connect(url, { useNewUrlParser: true });
});

// Connects to database power-rangers
beforeAll(async () => {
  const url = `mongodb://127.0.0.1/power-rangers`;
  await mongoose.connect(url, { useNewUrlParser: true });
});

Sending a POST request

Let's say you want to create a user for your app. The user has a name and an email address. Your Mongoose Schema might look like this:

const mongoose = require("mongoose");
const Schema = mongoose.Schema;

const userSchema = new Schema({
  name: String,
  email: {
    type: String,
    require: true,
    unique: true
  }
});

module.exports = mongoose.model("User", userSchema);

To create a user, you need to save the name and email into MongoDB. Your route and controller might look like this:

const User = require("../model/User"); // Link to your user model

app.post("/signup", async (req, res) => {
  const { name, email } = req.body;
  const user = new User({ name, email });
  const ret = await user.save();
  res.json(ret);
});

To save the user into the database, you can send a POST request to signup. To send a post request, you use the post method. To send data along with the POST request, you use the send method. In your tests, it'll look like this.

it("Should save user to database", async done => {
  const res = await request.post("/signup").send({
    name: "Zell",
    email: "testing@gmail.com"
  });
  done();
});

Note: If you run this code two times, you'll get an E1100 duplicate key error. This error occurred because:

1. We said the email should be unique in the Schema above.
2. We tried to create another user with testing@gmail.com. even though one already exists in the database. (The first one was created when you sent the first request).

Cleaning up the database between tests

You want to remove entries from the database between each test. This ensures you always start with an empty database.

You can do this with the afterEach hook.

// Cleans up database between each test
afterEach(async () => {
  await User.deleteMany();
});

In this code above, we only cleared the User collection in the database. In a real scenario, you want to clear all collections. You can use the following code to do so:

async function removeAllCollections() {
  const collections = Object.keys(mongoose.connection.collections);
  for (const collectionName of collections) {
    const collection = mongoose.connection.collections[collectionName];
    await collection.deleteMany();
  }
}

afterEach(async () => {
  await removeAllCollections();
});

Testing the Endpoint

Let's begin our tests. In this test, we will send a POST request to the /signup endpoint. We want to make sure:

1. The user gets saved to the database
2. The returned object contains information about the user

Checking if the user was saved to the database

To check whether the user gets saved into the database, you search the database for the user.

const User = require("../model/User"); // Link to your user model

it("Should save user to database", async done => {
  const res = await request.post("/signup").send({
    name: "Zell",
    email: "testing@gmail.com"
  });

  // Searches the user in the database
  const user = await User.findOne({ email: "testing@gmail.com" });

  done();
});

If you console.log user, you should see something like this:

This means our user got saved to the database. If we want to confirm the user has a name and an email, we can do expect them to be true.

it("Should save user to database", async done => {
  // Sends request...

  // Searches the user in the database
  const user = await User.findOne({ email: "testing@gmail.com" });
  expect(user.name).toBeTruthy();
  expect(user.email).toBeTruthy();

  done();
});

Checking if the returned object contains the information about the user

We want to make sure the returned object contains the user's name and email address. To do this, we check the response from the post request.

it("Should save user to database", async done => {
  // Sends request...

  // Searches the user in the database...

  // Ensures response contains name and email
  expect(res.body.name).toBeTruthy();
  expect(res.body.email).toBeTruthy();
  done();
});

We're done with our tests now. We want to delete the database from MongoDB.

Deleting the database

To delete the database, you need to ensure there are 0 collections in the database. We can do this by dropping each collection we used.

We'll do after all our tests have run, in the afterAll hook.

afterAll(async () => {
  // Removes the User collection
  await User.drop();
});

To drop all your collections you can use this:

async function dropAllCollections() {
  const collections = Object.keys(mongoose.connection.collections);
  for (const collectionName of collections) {
    const collection = mongoose.connection.collections[collectionName];
    try {
      await collection.drop();
    } catch (error) {
      // This error happens when you try to drop a collection that's already dropped. Happens infrequently.
      // Safe to ignore.
      if (error.message === "ns not found") return;

      // This error happens when you use it.todo.
      // Safe to ignore.
      if (error.message.includes("a background operation is currently running"))
        return;

      console.log(error.message);
    }
  }
}

// Disconnect Mongoose
afterAll(async () => {
  await dropAllCollections();
});

Finally, you want to close the Mongoose connection to end the test. Here's how you can do it:

afterAll(async () => {
  await dropAllCollections();
  // Closes the Mongoose connection
  await mongoose.connection.close();
});

That's everything you need to do to setup Mongoose with Jest!

Refactoring

There's a lot of code that goes into beforeEach, afterEach, and afterAll hooks. We will be using them for every test file. It makes sense to create a setup file for these hooks.

// test-setup.js
const mongoose = require("mongoose");
mongoose.set("useCreateIndex", true);
mongoose.promise = global.Promise;

async function removeAllCollections() {
  const collections = Object.keys(mongoose.connection.collections);
  for (const collectionName of collections) {
    const collection = mongoose.connection.collections[collectionName];
    await collection.deleteMany();
  }
}

async function dropAllCollections() {
  const collections = Object.keys(mongoose.connection.collections);
  for (const collectionName of collections) {
    const collection = mongoose.connection.collections[collectionName];
    try {
      await collection.drop();
    } catch (error) {
      // Sometimes this error happens, but you can safely ignore it
      if (error.message === "ns not found") return;
      // This error occurs when you use it.todo. You can
      // safely ignore this error too
      if (error.message.includes("a background operation is currently running"))
        return;
      console.log(error.message);
    }
  }
}

module.exports = {
  setupDB(databaseName) {
    // Connect to Mongoose
    beforeAll(async () => {
      const url = `mongodb://127.0.0.1/${databaseName}`;
      await mongoose.connect(url, { useNewUrlParser: true });
    });

    // Cleans up database between each test
    afterEach(async () => {
      await removeAllCollections();
    });

    // Disconnect Mongoose
    afterAll(async () => {
      await dropAllCollections();
      await mongoose.connection.close();
    });
  }
};

You can import the setup file for each test like this:

const { setupDB } = require("../test-setup");

// Setup a Test Database
setupDB("endpoint-testing");

// Continue with your tests...

There's one more thing I want to show you.

When you create tests, you want to seed the database with fake data.

Seeding a database

When you write tests for the backend, you need to test for four different kinds of operations:

1. Create (for adding things to the database)
2. Read (for getting things from the database)
3. Update (for changing the database)
4. Delete (for deleting things from the database)

The easiest type to test for is create operations. You put something into the database and test whether it's there.

For the other three types of operations, you need to put something into the database before you write the test.

Putting things into the database

The process where you add things to a database is called seeding a database.

Let's say you want to add three users to the database. These users contain a name and an email address.

const users = [
  {
    name: "Zell",
    email: "testing1@gmail.com"
  },
  {
    name: "Vincy",
    email: "testing2@gmail.com"
  },
  {
    name: "Shion",
    email: "testing3@gmail.com"
  }
];

You can use your models to seed the database at the start of the test.

const User = require("../model/User"); // Link to User model

it("does something", async done => {
  // Add users to the database
  for (const u of users) {
    const user = new User(u);
    await user.save();
  }

  // Create the rest of your test here
});

If you need these users for every test, the best way is to add them through the beforeEach hook. The beforeEach hook runs before every it declaration.

// Seed the database with users
beforeEach(async () => {
  for (u of users) {
    const user = new User(u);
    await user.save();
  }
});

You can also use Mongoose's create function to do the same thing. It runs new Model() and save(), so the code below and the one above does the same thing.

// Seed the database with users
beforeEach(async () => {
  await User.create(users);
});

create vs insertMany

Mongoose has a second method to help you seed the database. This method is called insertMany. insertMany is faster than create, because:

• insertMany sends one operation to the server
• create sends one operation for each document

However, insertMany does not run the save middleware.

Is triggering the save middleware important?

This depends on your seed data. If your seed data needs to go through the save middleware, you need to use create. For example, let's say you want to save a user's password into the database. You have this data:

const users = [
  {
    name: "Zell",
    email: "testing1@gmail.com",
    password: "12345678"
  },
  {
    name: "Vincy",
    email: "testing2@gmail.com",
    password: "12345678"
  },
  {
    name: "Shion",
    email: "testing3@gmail.com",
    password: "12345678"
  }
];

When we save a user's password into the database, we want to hash the password for security reasons. We usually hash the password through the save middleware.

// Hashes password automatically
userSchema.pre("save", async function(next) {
  if (!this.isModified("password")) return next();
  const salt = bcrypt.genSaltSync(10);
  const hashedPassword = bcrypt.hashSync(password, salt);
  this.password = hashedPassword;
});

If you use create, you'll get users with hashed passwords:

If you use insertMany, you'll get users without hashed passwords:

When to use create, when to use insertMany

Since insertMany is faster than create, you want to use insertMany whenever you can.

Here's how I do it:

1. If seed data does not require the save middleware, use insertMany.
2. If seed data requires save middleware, use create. Then, overwrite seed data so it no longer requires the save middleware.

For the password example above, I would run create first. Then, I copy-paste the hashed password seed data. Then, I'll run insertMany from this point onwards.

If you want to overwrite complicated seed data, you might want to get JSON straight from MongoDB. To do this, you can use mongoexport:

mongoexport --db <databaseName> --collection <collectionName> --jsonArray --pretty --out output.json

This says:

1. Export <collection> from <databaseName>
2. Creates output as a JSON Array, prettified, in a file called output.json. This file will be placed in the folder where you run the command.

Seeding multiple test files and collections

You want a place to store your seed data so you can use them across all your tests and collections. Here's a system I use:

1. I name my seed files according to their models. I seed a User model with the user.seed.js file.
2. I put my seed files in the seeds folder
3. I loop through each seed file to seed the database.

To loop through each seed file, you need to use the fs module. fs stands for filesystem.

The easiest way to loop through the files is to create an index.js file in the same seeds folder. Once you have the index.js file, you can use the following code to look for all files with *.seed.js

const fs = require("fs");
const util = require("util");

// fs.readdir is written with callbacks.
// This line converts fs.readdir into a promise
const readDir = util.promisify(fs.readdir);

async function seedDatabase() {
  // Gets list of files in the directory
  // `__dirname` points to the `seeds/` folder
  const dir = await readDir(__dirname);

  // Gets a list of files that matches *.seed.js
  const seedFiles = dir.filter(f => f.endsWith(".seed.js"));
}

Once you have a list of seed files, you can loop through each seed file to seed the database. Here, I use a for...of loop to keep things simple.

async function seedDatabase() {
  for (const file of seedFiles) {
    // Seed the database
  }
}

To seed the database, we need to find the correct Mongoose model from the name of the seed file. A file called user.seed.js should seed the User model. This means:

1. We must find user from user.seed.js
2. We must capitalize user into User

Here's a crude version that does what's required. (If you want to, you can make the code more robust with regex instead of split).

for (const file of seedFiles) {
  const fileName = file.split(".seed.js")[0];
  const modelName = toTitleCase(fileName);
  const model = mongoose.models[modelName];
}

Next, we want to make sure each file has a Model that corresponds to it. If the model cannot be found, we want to throw an error.

for (const file of seedFiles) {
  //...
  if (!model) throw new Error(`Cannot find Model '${modelName}'`);
}

If there's a corresponding model, we want to seed the database with the contents in the seed file. To do this, we need to read the seed file first. Here, since I used the .js extension, I can simply require the file.

for (const file of seedFiles) {
  //...
  const fileContents = require(path.join(__dirname, file));
}

For this to work, my seed files must export an array of data.

module.exports = [
  {
    name: "Zell",
    email: "testing1@gmail.com",
    password: "12345678"
  },
  {
    name: "Vincy",
    email: "testing2@gmail.com",
    password: "12345678"
  },
  {
    name: "Shion",
    email: "testing3@gmail.com",
    password: "12345678"
  }
];

Once I have the contents of the seed file, I can run create or insertMany.

async function seedDatabase(runSaveMiddleware = false) {
  // ...
  for (const file of seedFiles) {
    // ...

    runSaveMiddleware
      ? model.create(fileContents)
      : model.insertMany(fileContents);
  }
}

Here's the whole seedDatabase code:

const fs = require("fs");
const util = require("util");
const readDir = util.promisify(fs.readdir).bind(fs);
const path = require("path");
const mongoose = require("mongoose");

function toTitleCase(str) {
  return str.replace(/\w\S*/g, txt => {
    return txt.charAt(0).toUpperCase() + txt.substr(1).toLowerCase();
  });
}

async function seedDatabase(runSaveMiddleware = false) {
  const dir = await readDir(__dirname);
  const seedFiles = dir.filter(f => f.endsWith(".seed.js"));

  for (const file of seedFiles) {
    const fileName = file.split(".seed.js")[0];
    const modelName = toTitleCase(fileName);
    const model = mongoose.models[modelName];

    if (!model) throw new Error(`Cannot find Model '${modelName}'`);
    const fileContents = require(path.join(__dirname, file));

    runSaveMiddleware
      ? await model.create(fileContents)
      : await model.insertMany(fileContents);
  }
}

Why JS, not JSON?

It's the industry norm to use JSON to store data. In this case, I find it easier to use JavaScript objects because:

1. I don't have to write opening and closing double-quotes for each property.
2. I don't have to use double-quotes at all! (It's easier to write single-quotes because there's no need to press the shift key).

// Which is easier to write. JavaScript objects or JSON?

// JavaScript objects
module.exports = [
  {
    objectName: "property"
  }
][
  // JSON
  {
    objectName: "property"
  }
];

If you want to use JSON, make sure you change seedDatabase to work with JSON. (I'll let you work through the code yourself).

Adjusting the setupDB function

Earlier, I created a setupDB function to help set up databases for my tests. seedDatabase goes into the setupDB function since seeding is part of the setting up process.

async function seedDatabase(runSaveMiddleware = false) {
  // ...
}

module.exports = {
  setupDB(databaseName, runSaveMiddleware = false) {
    // Connect to Mongoose
    beforeAll(/*...*/);

    // Seed Data
    beforeEach(async () => {
      await seedDatabase(runSaveMiddleware);
    });

    // Cleans up database between each test
    afterEach(/*...*/);

    // Disconnect Mongoose
    afterAll(/*...*/);
  }
};

A Github Repository

I created a Github repository to go with this article. I hope this demo code helps you start testing your applications.

Thanks for reading. This article was originally posted on my blog. Sign up for my newsletter if you want more articles to help you become a better frontend developer.

How to provide support

Generally, there are three ways to provide support when it comes to CSS.

First method: Write fallback code. Overwrite fallback code.

.selector {
  property: fallback-value;
  property: actual-value;
}

Second method: Write fallback code. Overwrite fallback code in CSS Feature Queries (@supports). Reset properties inside @supports if you need.

.selector {
  property: fallback-value;
}

@supports (display: grid) {
  property: actual-value;
}

Third method: Write everything in @supports.

@supports not (display: grid) {
  .selector {
    property: fallback-value;
  }
}

@supports (display: grid) {
  .selector {
    property: actual-value;
  }
}

These three methods are listed in order of decreasing-complexity. (If you need to overwrite code, it's more complicated). This means writing everything in @supports is the simplest of the three.

How you choose to support your project depends on browser support for:

1. The feature
2. The fallback feature
3. Support for Feature Queries

Checking for support

The best place to check for support is caniuse. Here, I see that support for CSS Grid is decent. Browsers I have to worry about are:

1. Opera Mini: 1.42% global usage
2. Android Browsers 2.1 to 4.4.4: 0.67% global usage
3. Blackberry browser: 0.02% global usage (Not gonna worry about this one).

Support for the fallback (Flexbox) is also good.

But we have a problem: Flexbox fallback wouldn't work for Android 2.1 to 4.3 (it doesn't support wrapping). Global usage for Android 2.1 to 4.3 is 0.37%.

Here, I have to decide:

1. Is providing Flexbox fallback for Opera Mini (1.42%), Android 4.4.4 (0.3%), and Blackberry (0.02%) worth the effort?
2. Should I change fallback from Flexbox to an older feature to support Android 2.1 to 4.3 (another 0.37%)?

Let's assume, for this project, I decide that Flexbox fallback is sufficient. I'm not going to worry about Android 2.1 to 4.3.

Next, I want to check whether browsers support CSS Feature Queries.

Here, I see:

1. Opera Mini supports Feature Queries
2. Android 4.4.4 supports Feature Queries
3. Blackberry browser doesn't support Feature Queries
4. IE 11 does't support Feature Queries

Deciding how to write fallback code

Earlier, I mentioned there are three ways to write fallback code for CSS:

1. Write fallback code. Overwrite fallback code.
2. Write fallback code. Overwrite fallback code in @supports.
3. Write everything in @supports.

If I write everything inside @supports, I can provide support for:

1. Opera Mini (1.43%)
2. Android 4.4.4 (0.3%)

But I lose support for:

1. IE 11 (2.3%)
2. Blackberry (0.02%)

I do not want to forsake the 2.3% of IE users, which means Method 3 (write everything in @supports) is out.

If I use Method 2 (Write fallback code. Overwrite fallback code in @supports), I can provide support for:

1. IE 11 (2.3%)
2. Opera Mini (1.43%)
3. Android 4.4.4 (0.3%)
4. Blackberry browser (0.02%)

That's everything I need. That's why I'm gonna go with Method 2.

Note: If you want to code along, you can use demo from my previous article as the starting point.

Disabling Grid code

First, we park the CSS Grid code under @supports (like we discussed above).

@supports (display: grid) {
  .day-of-week,
  .date-grid {
    display: grid;
    grid-template-columns: repeat(7, 1fr);
  }

  .date-grid button:first-child {
    grid-column: 6;
  }
}

We can disable the CSS Grid code by setting display to an invalid value (not grid). This disables the entire block of code.

(Thank Rachel Andrew for this neat trick. I believe I learned it from her ?).

@supports (display: gridx) {
  /*...*/
}

Writing Flexbox code

We need to build the same seven-column grid with Flexbox. The first thing we need to do is acknowledge that Flexbox and Grid work differently. We won't be able to get a perfect replica, but we can get close.

The first thing is set display to flex.

.day-of-week,
.date-grid {
  display: flex;
}

We need the buttons in .date-grid to wrap, so we set flex-wrap to wrap.

.date-grid {
  flex-wrap: wrap;
}

We need to replicate the seven-column grid. An easy way to do this is calculate the width of the grid according to the width of each button. Here, I have already set each button to 4.5ch. This means the width of the grid should be 7 x 4.5ch.

(We can use CSS Calc to do the math for us).

.day-of-week,
.date-grid {
  max-width: calc(4.5ch * 7);
}

We need the elements in .day-of-week to spread out across the available width. One simple way is to set justify-content to space-between.

.day-of-week {
  justify-content: space-between;
}

Here, we can see that elements in .day-of-week extend past the grid. This extension happens because we let Flexbox calculate flex-basis for us. If we want every element in .day-of-week to be have the same width, we need to set flex-basis ourselves.

In this case, the easiest way is to set flex-basis to the width of one grid item (or 4.5ch). Note: I adjusted font-size of each item in .day-of-week to 0.7em (for visual aesthetics). We have to account for this change.

.day-of-week > * {
  flex-basis: calc(4.5ch / 0.7);
}

Finally, we need to push the 1 February to Friday. (Five columns). Since column is 4.5ch, we simply push it by 4.5ch x 5.

(Again, we can use CSS Calc to help us with this).

.date-grid button:first-child {
  margin-left: calc(4.5ch * 5);
}

Fixing the CSS Grid version

We can reactivate the CSS Grid code and make any necessary changes now.

@supports (display: grid) {
  /* ... */
}

Here, we see some values fly far out to the right. This happens because we added margin-left to the first grid item. We need to reset the added margin.

@supports (display: grid) {
  /* ... */
  .date-grid button:first-child {
    grid-column: 6;
    margin-left: 0;
  }
}

Another thing: We can remove max-width because we don't need it in the CSS Code. (Even though this doesn't affect the CSS Code, we still want to remove it. Always better to have less properties).

@supports (display: grid) {
  .day-of-week,
  .date-grid {
    display: grid;
    grid-template-columns: repeat(7, 1fr);
    max-width: initial;
  }

  /* ... */
}

Here's the visual difference between the Flexbox and CSS Grid versions. Not too bad!

One fun thing

CSS Grid is cool because it follows writing direction. We can easily change the flow from left-to-right to right-to-left.

Note: I don't know if calendars are read from right to left in rtl languages. I just thought it'll fun to mention this ?).

Our code for CSS Grid supports this behaviour naturally. If you want to support the same behaviour with Flexbox, you need to use CSS Logical Properties.

Since support for CSS Logical Properties is not-so-great, we need to provide fallback for it. (Best way is to through Method 1: Write fallback; overwrite fallback).

.date-grid button:first-child {
  margin-left: calc(4.5ch * 5);
  margin-inline-start: calc(4.5ch * 5);
}

@supports (display: grid) {
  /* ... */
  .date-grid button:first-child {
    grid-column: 6;
    margin-left: 0;
    margin-inline-start: 0;
  }
}

That's it! Here's a Codepen for the final code:

See the Pen Building a Calendar with CSS Grid (and fallback with Flexbox) by Zell Liew (@zellwk) on CodePen.

Thanks for reading. This article was originally posted on my blog. Sign up for my newsletter if you want more articles to help you become a better frontend developer.

Here's what you'll create by the end of this article:

Creating the HTML

You can tell from the image that the calendar contains three parts:

1. The month indicator
2. The weekday/weekend indicator
3. The dates themselves

The best way to structure the HTML is to go with what feels right. We'll create the HTML according to these three sections:

<div class="calendar">
  <div class="month-indicator">...</div>
  <div class="day-of-week">...</div>
  <div class="date-grid">...</div>
</div>

You should also be able to see we need seven columns for the grid.

We'll focus the conversation on .day-of-week and .date-grid since we're only talking about grid.

Structuring the grid

There are two ways to create the CSS Grid.

The first way is to merge elements within .day-of-week and .date-grid into one selector. If we do this, we can set the selector in display: grid. Here's what the HTML would have looked like if we did this:

<div class="grid">
  <!-- Day of week -->
  <div>Su</div>
  <div>Mo</div>
  <div>Tu</div>
  <div>We</div>
  <div>Th</div>
  <div>Fr</div>
  <div>Sa</div>

  <!-- Dates -->
  <button><time datetime="2019-02-01">1</time></button>
  <button><time datetime="2019-02-02">2</time></button>
  <button><time datetime="2019-02-03">3</time></button>
  <!-- ... -->
  <button><time datetime="2019-02-28">28</time></button>
</div>

I discourage this method because the HTML loses its structural meaning. I prefer keeping .day-of-week and date-grid as separate elements if possible. This makes it easy for me to read/understand the code I've written.

Here's the HTML structure i chose to go with:

<div class="day-of-week">
  <div>Su</div>
  <div>Mo</div>
  <div>Tu</div>
  <div>We</div>
  <div>Th</div>
  <div>Fr</div>
  <div>Sa</div>
</div>

<div class="date-grid">
  <button><time datetime="2019-02-01">1</time></button>
  <button><time datetime="2019-02-02">2</time></button>
  <button><time datetime="2019-02-03">3</time></button>
  <!-- ... -->
  <button><time datetime="2019-02-28">28</time></button>
</div>

The best way to create a CSS Grid with the structure I proposed is to use subgrid. Unfortunately, most browsers don't support subgrid yet. In the meantime, the best way is to create two separate grids—one for .day-of-week and one for .date-grid.

Both .day-of-week and .date-grid can use the same seven-column grid.

/* The grid */
.day-of-week,
.date-grid {
  display: grid;
  grid-template-columns: repeat(7, 1fr);
}

Pushing the dates

February 2019 begins on a Friday. If we want the calendar to be correct, we need to make sure:

1. 1 Feb 2019 falls on Friday
2. 2 Feb 2019 falls on Saturday
3. 3 Feb 2019 falls on Sunday
4. And so on...

With CSS Grid, this part is easy.

CSS Grid has placement algorithm that kinda follows the following rules (if you didn't set grid-auto-flow to dense):

1. Place items that has explicit grid-column or grid-row first
2. Fill in the rest according to the last-placed item

What this means is:

1. If the first item falls on column 6
2. The second item will be placed in column 7.
3. The third item will be placed on the next row, in column 1 (because there are only seven columns).
4. The fourth item will be placed in column 2,
5. And so on...

So, if we position 1 February on the sixth column (friday), the rest of the dates will be placed correctly.

Simple as that!

/* Positioning the first day on a Friday */
.date-grid button:first-child {
  grid-column: 6;
}

Here's a codepen for you to play with:

See the Pen Building a Calendar with CSS Grid by Zell Liew (@zellwk) on CodePen.

Want to learn more?

This article contains one fraction of a component (a datepicker) from Learn JavaScript. There's so much more I want to show you. (But they're mostly JavaScript related topics).

For example, in Learn JavaScript, I show you how to:

1. Build a calendar for any month (and any year)
2. Add a previous/next button to switch between months
3. Click on each date to display a date

Here's what it looks like:

Thanks for reading. This article was originally posted on my blog. Sign up for my newsletter if you want more articles to help you become a better frontend developer.

1. Awareness
2. Panic
3. Avoidance
4. Acceptance
5. Learning

Awareness

• "Oh! This is possible?!"
• "Ah, so that's how you solve this".
• "This is good. I need to learn this".

In the awareness stage, you learn about a problem. And you realize you need to find a solution.

Panic

Panic might come to some people. This depends on how much pressure you put on yourself. If you pressure yourself hard, you'll get into panic mode.

If you set a deadline for learning, you're giving yourself pressure. Most people don't realize this. They set an ambitious deadline for themselves and they fail hard.

If you set a deadline to learn something, that deadline you set is probably ambitious. It's ambitious because learning usually takes more time and effort than you account for.

If you put too much pressure on yourself, you may get overwhelmed. You may look for shortcuts instead of actually learning what you're supposed to learn.

Avoidance

When panic/overwhelm sets in, we tend to avoid what we're doing.

• "I can't do this right now"
• "I'm not smart enough"
• "I need a break"
• "Life happens"

We give ourselves excuses permission to drop the thing we're learning.

It's okay to pause for a breather if you can't catch your breath. We all need a breather sometimes. But it's not okay to give up. (Unless you decide it's something you never wanted to do for the rest of your life. In which case, giving up is a good choice).

The unfortunate thing is: Some people never realize they're avoiding. They search the internet, hoping to find "good tutorials" that'll teach them everything they need to know. And they use "I can't find any good tutorials" as an excuse not to learn.

Acceptance

This is where you accept you bit off more than you can chew, and decide to chew it anyway. You accept the tough challenge ahead. And you prepare to face it head-on.

For most people, it's when they say "I'm going to fucking learn this no matter what".

This is when we dedicate the necessary resources, time, and energy to learn the thing we need to learn.

If you get into this mode, anything you learn stays with you for a long time. Before this stage, you don't actually learn. You may remember something for a short while, but you'll forget about it quickly.

Learning

And so learning begins.

We read everything we need to read.

We do everything we need to do.

We code if we have to.

We think if we have to.

We get our hands dirty if we have to.

Learning is like a marathon. There's no best pace. All we have is the pace we're comfortable with. And the pace changes according to our states.

• If we go too slow, we get bored.
• If we go too fast, we get into an overwhelmed or panic state.

So what's important is to pace yourself. Take it step by step. Go slow if you're running out of breath, and run faster if you're getting bored.

At a certain point, we may decide we learned enough.

And learning stops.

Mastery

Mastery is a continuous process where you learn more and more things about the same subject. You get deeper into the subject and you're able to sieve out the nuances.

Mastery comes with repeated learning. It comes with going through the five stages over and over again.

1. Awareness
2. Panic
3. Avoidance
4. Acceptance
5. Learning

With enough time, you'll become a master one thing.

This article was originally posted on my blog. Sign up for my newsletter if you want more articles to help you become a better frontend developer.

In 2019, I decided to stop making videos. I want to share why I decided to stop making videos.

Why I started making videos

I started making videos because of three reasons:

1. I thought it would be fun.
2. It would be good practice if I want to release video-based courses in the future.
3. I heard good things about video helping to bring more subscribers

I finally got a chance to try making videos at the start of 2018. I committed for one year (and made 44 videos in total). That's approximately 1 video per week.

Why I'm shutting down Fridays with Zell.

Two reasons:

1. Videos don't bring me additional subscribers
2. Video-making is not fun for me

I should probably say more about each statement, so here we go.

Videos don't bring me additional subscribers

Here's a chart of subscribers in 2018 and in 2019. Green bars indicate the number of new subscribers.

The number of new subscribers hovered around 250 per week from 1st January 2018 to 22 May 2019. I stopped posting videos in January 2019, but the number of subscribers remained at 250 per week.

This tells me the videos didn't bring in new subscribers. My videos were mostly watched by people who are already following me.

Video-making is not fun

A lot of work goes into creating videos.

1. I had to put myself in front of the camera
2. Speak in a manner that doesn't feel too fake
3. Edit the hell out of what I spoke (the hard part)
4. Write an article that goes along with the video

Points 3 and 4 are killers.

I loathe the editing process. I hate scrubbing and trimming the audio. This process is not fun at all. I would rather do ANYTHING else than edit a video.

Plus, converting a video into an article takes a hell lot of work too. I have to write a transcript of what transpired in the video, create images, and write an article that flows.

It's not fun.

It's too much work.

I got burned out.

So I decided to stop.

Will I ever make videos again?

I can't say for sure. Maybe I will make videos again when the dread fades away. But if I ever start making videos again, I'll do it in a different way.

Final words

You won't know whether you should (or shouldn't) do something until you've done it.

Give it a try.

You can always walk away if it's not for you.

If you walk away, you'll know why it's not for you. You'll have a better idea about what you want/don't want to do. And you can focus better on the next thing.

Sometimes, what's right for you now doesn't mean it's always going to be right for you.

Keep experimenting, and continue to challenge your assumptions.

Thanks for reading. This article was originally posted on my blog. Sign up for my newsletter if you want more articles to help you become a better frontend developer.

There's an easy way to integrate Standard in VS Code—with the vscode-standardjs plugin. I made a video for this some time ago if you're interested in setting it up.

But, if you follow the instructions in the video (or on vscode-standardjs's readme file), you'll come to notice there's one small detail that needs to be ironed out.

Try writing a function the old way, and save it repeatedly. VS code will toggle between having and not having a space before the left-parenthesis of the function.

You get the same problem when you write methods with the ES6 method shorthands:

There's a quick way to fix this issue. What you need to do is set javascript.format.enable to false. This disables VS Code's default Javascript formatter (and lets vscode-standandjs does the formatting work).

So the minimum configuration you need to get Standard and VS Code to work together is:

{
  // Prevents VS Code from formatting JavaScript with the default linter
  "javascript.format.enable": false,

  // Prevents VS Code linting JavaScript with the default linter
  "javascript.validate.enable": false,

  // Lints with Standard JS
  "standard.enable": true,

  // Format files with Standard whenever you save the file
  "standard.autoFixOnSave": true,

  // Files to validate with Standard JS
  "standard.validate": [
    "javascript",
    "javascriptreact"
  ]
}

This article was originally posted on my blog.
Sign up for my newsletter if you want more articles to help you become a better frontend developer.

"Do you have any advice on finding a job as a developer?"

Many people have asked me that question, but I can’t give a proper answer because I have never been hired as a developer before. What I did was:

1. Wriggled my way into a Wordpress dev role in an admin-based internship
2. Freelanced
3. Run my own company

So I'm horribly inadequate at answering a question about finding a job.

But Chris Lienert is an expert at it. Chris has experience hiring and building teams of excellent developers. (A fun aside: He used to co-run CSS Singapore, which is a monthly CSS Meetup in Singapore).

I managed to grab Chris (before he left Singapore for good) and asked him to talk about the job application process. You'll hear golden advice in this interview from Chris, like:

1. Chris' opinions about the hiring process.
2. How to improve your chances of getting an interview
3. What to do if you don't get a job
4. How you should write your CV
5. What to do during the actual interview
6. What questions to ask during the interview
7. How to answer any tricky questions you get

Note: We jumped around a lot in this 1.5 chat because Chris has so much to say about this topic. I highly recommend you listen to the audio version if you can.

To make it easier for you to digest, I also summarized what we talked about into three stages:

1. Preparing your CV/Resume
2. Before you apply for a job
3. The interview process

Your CV / Resume

It's hard to write a CV. On one hand, you want to pad it with enough information to make you attractive. On the other hand, you want to keep it short enough for recruiters to not hate you.

(Note: I use the word "recruiter" to describe anyone who participates in the hiring process).

We'll first talk about three keys to writing a CV before we talk about the structure of the CV. The three keys are:

1. The Crayon Test
2. Keywords
3. Differentiate yourself

The Crayon Test

Recruiters are busy. They have to go through hundreds of applications for each job opening.

This means recruiters will scan through your CV quickly. They'll put away your CV immediately if there are any spelling errors. They will also put away your CV if you miss out any important information (like your email or phone number).

Chris calls this The Crayon Test. (Because it tests whether the candidate is able to fulfil basic requirements like spelling their name correctly).

What you should do is make sure your CV is clear and understandable. It should not have any spelling mistakes. It should contain the necessary information a recruiter needs to contact you.

Keywords

Make sure you have the right keywords for the position you want to apply for. For example, if the job ad is for a "React Developer", make sure you have "React" somewhere on your Resume.

You need to do this because people (and machines) scan your CVs for keywords. If you don't have the necessary keyword(s) in your CV, you'll get passed over for someone else EVEN before you get an interview.

Back to the "React Developer" example. If you don't have enough confidence in React, you still need to find a way to put React in your CV. Good ways to include keywords (if you don't have the skill) is to put them under Job Experience or Community. More on this in the CV structure below.

Differentiate yourself

What makes you different from thousands of other applicants out there?

If you're a fresh graduate, the answer is nothing.

You need to make it SOMETHING.

There are a variety of ways to talk about your passion and experience in this industry (even if you haven't got a job yet). Some ways include:

1. Notable Codepen projects
2. Your projects on Github
3. Things you built before (on your own, not by following tutorials!).
4. Articles you've written
5. Contributing to open source

Most of these can go into the "Community" section of your CV. More on this later.

Length of your CV

Your CV should be short. Keep it to 1-2 pages if you're starting out.

As you gain more experience and want to switch to more senior roles, your CV can go beyond 2 pages. (Chris' CV is four pages longs. It needs to be that long to show he has the qualifications for a job at his level).

The structure of your CV

The structure we're proposing here is drawn from Chris' experience. You may find conflicting information elsewhere on the internet. Take what you need.

Your CV should contain the following things:

1. Contact Details
2. Summary
3. Skills
4. Experience
5. Education
6. Community
7. References

Contact Details: This section should contain information about yourself. You need to have these three items to pass the Crayon Test:

1. Your name
2. Your email address
3. Your phone number

Summary: Summary is a one-liner of what you're looking for. You want to be clear here. For example, "I'm looking to be a frontend developer in a great team" is a good one-liner.

Skills: This is where you showcase 5-10 skills you're good at. No need to put version numbers because they're irrelevant. Example:

1. HTML
2. CSS
3. JavaScript
4. Node
5. Making simple web animations

There's no need to list your years of experience on a skill. It doesn't matter. If you work hard, you can become great in 12 months.

Don't lie about your skills. Only put the ones you're confident in because you may get questions on each of them.

Experience: This is where you write about your job experience. For each job experience, you should have:

1. The company name
2. A one-liner explaining what they do
3. When and the duration you worked on this job
4. 3 bullet points of what you learned from this job that's relevant for the position you're applying for.

It's a good pattern to have at least 18 months to 2 years per job experience.

If you have a time-gap between jobs, you want to state what you did during the gap. Freelancing, backpacking, etc. Stating this gives insight into how you developed yourself since school.

If your experience is not relevant to the job (like if you're a waiter/waitress), then simply say that and move on.

Please DO NOT LIST the things you DON'T want to do. It might get you the job, but you'll be miserable in it.

Education: This is where you list your education experience. Create some bullet points if you have experience that's relevant to the position you apply for. Otherwise, just list your certification and move on.

Community: This is where you can stand out if you don't have prior job experience. Here, you want to talk about what you do for/in the web community. You can include things like:

1. Attending conferences
2. Attending meetups
3. Talks you gave
4. Articles you wrote (that's not on your own blog)
5. Videos you made

One way to game the keywords (if you need to) is to include the keyword in the title of your talk/article/video.

References: References are people who vouch for you. They can be hard to get in the early days of your career. Omit if you don't have any.

Your cover letter

Some companies require a cover letter. Keep it short if you need to write one. You don't need an essay for our industry.

Your cover letter should contain these three paragraphs (in your own words):

• Paragraph 1: "Hi, I'm X. I saw your job. It looks good and I want to apply".
• Paragraph 2: Why you fit the role
• Paragraph 3: You can reach me at [this number].

Before you apply

Most job requirements seem daunting. Everyone is looking for some JavaScript experience. Everyone want React Developers. Some even want Full Stack developers.

What can you do?

We'll talk about four important things you need to understand. Some may create a paradigm shift for you. They are:

1. Why some job ads suck
2. Imposter Syndrome and minorities
3. The "Full Stack" developer
4. Keep applying

Why some job ads suck

The person who hires for the person and the person who crafts the job ad may be different people. This is especially true in large companies.

If the person who crafts the job ad knows nothing about the industry, they may require "10 years of React experience" even though React has been out only for 6. This is why you see jokes about bad job requirements all over the place.

To put your bias aside, people do try to improve their job ads. Chris, for example, does this.

In the interview, Chris shared about an experience where he rewrote a job ad. And he gave the HR strict instructions to post the job as it is. But when Chris looked at the actual advertisement, he didn't recognize the ad. It was butchered badly.

The key takeaway here is: Don't be too concerned about what's written on the job ad. It might have been inflated with unreasonable demands.

Imposter Syndrome and minorities

If you feel like a minority, you've labeled yourself as a minority. It doesn't matter if you're a white male, or a black woman, or an Asian, or anything else. Chris, for example, is a white male that feels like a minority because he doesn’t feel like he easily fits with anyone else.

The thing about minorities is minorities have high rates of Imposter Syndrome.

• They wonder if they're qualified for the job.
• They wonder why people should pick them over so many qualified candidates out there.

As a result, most minorities only apply to when they feel they're qualified for the job. This means apply to jobs if they can meet 80% of the job requirement. (On the other hand, majority candidates apply for a job if they meet 30% of the job requirements).

This is insane.

Minorities are usually better candidates because they have to fight through lots of barriers. They have better skills, better attitude, they work harder, and they know more about they're doing.

What this means is: If you're a minority candidate, please apply to more jobs. Apply to jobs even if you don't meet 80% (or 100%!) of the requirements.

Don't worry about meeting the requirements. Apply if you are confident you'll be able to do the job (and you're able to learn on the job).

Job ads are often inflated. Remember that.

The Full-stack developer

Many jobs require a "Full Stack" developer experience. This puts pressure on developers to learn the "Full" stack (and it makes them feel inadequate in the process).

But how full is a "Full Stack"? Do you need to know databases? Do you need to know how to write server code? Design? Draw? UX? There's no concrete definition for a Full-stack developer.

Most companies don't actually want to look for a full-stack developer. They think they want to look for a full-stack developer based on what they know.

They'll only interview you if your CV matches what they think is "Full Stack". They might be wrong. And they might not even know what they need.

What this means is: Don't worry about getting a full-stack experience. Read the job description, apply, and ask questions during the interview (more on this later).

Keep applying

It can be dispiriting to apply for jobs. You'll get rejected (many times without even knowing). It sucks.

It doesn't matter where you are in your career. If you're looking for jobs, the same thing will happen. You'll still get rejected.

Chris is a top qualified candidate in what he does. He shared with me that during his recent job search process, he applied for 16 jobs, but only heard back from 3.

Even Chris can't get interviews at places. (I thought Chris wouldn't have a problem with finding jobs). But this just shows how messy the hiring process can be.

It's hard to get over a rejection. You're emotionally invested in the process, so it becomes especially hard.

But you got to keep applying for jobs. You have to continue to review your CV and Cover letter.

Don't give up. You'll get a job eventually if you keep it up.

During the interview

Interviews are nerve-racking. We'll talk about five things in this section:

1. Feeling nervous
2. Whiteboard interviews
3. Answering tricky questions
4. Questions to ask
5. Be honest

Feeling nervous

You are going to be nervous. You're going to be frightened out of your mind. It's normal because you're getting tested.

You will stumble as you answer questions. You will get something wrong during the interview (only to remember the actual answer later on).

It's okay to be nervous and mess because everyone will be nervous and mess.

Hopefully, this makes you feel better. The more relaxed you can be, the better. But don't stress yourself to be relaxed.

Whiteboard interviews

Whiteboard interviews suck because people test you on the wrong things. You won't be writing code on the whiteboard in your job, so it makes no sense to create a whiteboard interview.

Chris argues that interviewers should mirror the person's job as much as possible during the interview. If you're hiring a developer, you'd want to put a laptop in front of them.

If you want to observe what they do, you can mirror the laptop onto a screen so you can observe from afar. This way, the developer can focus on coding.

We didn't answer how to tackle a whiteboard interview during the chat, but you might want to take what Chris said in mind. Maybe you can request for the interviewer to put you in a comfortable space to perform? It's not always possible, but it might make you stand out in the right way :).

Answering tricky questions

You will face at least three tricky questions during most interviews. They are:

1. What's your strengths and weaknesses?
2. Where do you see yourself in 3-5 years?
3. Why did you leave your previous job?

You'd want to prepare answers for these questions (and any others you can find). Chris has some thoughts on how you should answer.

What's your strengths and weaknesses?

There are no good answers for this question. What you want to do is avoid any bad answers that can skew what the interviewer thinks of you.

The key is to be honest while being tactful. You can't be boastful because they'll take note.

When you answer the question about your weakness, you want to say what you're doing about it and explain why you're good for the job.

Here's an example Chris gave:

I was a team leader for 10 years. In the first five years, I didn't understand what being a team leader was about. I focused on myself. It took me a while to realize that the benefit I provide as a leader is what we produce as a team and not what I produce as an individual.

My weakness then was I was too focused on the individual and not very a good leader. And I did something about it.

My weakness now is: I'm not technically as strong as I used to be, because I spend more time making sure everyone is doing their job properly and happily than focusing on my technical side.

(This weakness makes a great manager).

Where do you see yourself in 3-5 years time?

This question gives an insight into what you're looking for. If you say something along the lines of moving up the career ladder, it hints that you're not interested in the job itself.

If you're looking to be a frontend developer, a good example is to say you see yourself coding for the company. Keep it direct and straightforward.

Example from Chris: "My focus then is a job where I can code. My focus now is to make the company I'm working for succeed. I'm going to code really well and lead the team really well.

Why did you leave your previous job?

If you left your job because it's a toxic environment, you want to be specific about what made it toxic.

We didn't tackle this question any further in the chat I had with Chris, so I don't have concrete answers for you if you got bored and simply wanted to switch.

Standing out

You need to sell yourself during an interview so you stand out. You can do this by answering questions the interviewer has not asked.

Tell them the things you listed on your CV. Tell them about contributing to open source, attending meetups, conferences, blogging, and anything you can think of that helps you stand out.

It is the nature of our industry to think creatively. If you managed to solve a problem in a useful way before, talk about it. It'll put you in a good light. The more you've done this, the more you're of a right employee.

Questions to ask

As much as the interview is interviewing you, you're also interviewing the interviewer. Remember this.

Chris says he'd ask two questions:

1. What will I be doing if you sit me down at my desk and put a computer in front of me?
2. What are the skeletons in your closest?

What will I be doing if you sit me down at my desk and put a computer in front of me?

This question tells about the work you'll do day-to-day with the company. If they say something concrete about the work that you align with, good!

But be aware that expectations don't always line up to reality. If this happens, Start applying for another job.

What are the skeletons in your closest?

This question means: What are the dirty things I should know about your company? To me, this question flips the "What's your weakness" question back to the company.

You'd want to hear what they want to hide. You want to test their honesty as well. If they say everything is perfect, they're lying.

Everyone will try to sell you the job if they're interested in you. They'll tell you about shiny frameworks and greenfield projects. But when you show up, they might ask you to work on legacy systems.

Be honest

Always be honest. It's not going to work if you bluff.

The worst part about lying is you might get the job. And then you're screwed because you're expected to perform.

Final words from Chris

So much about finding a job is not cutting yourself out of the process.

They're only looking for one person for the job. The odds are, you're not going to get the job. So how do you NOT get eliminated? How do you move on to the next stage and meet the next boss?

You'll feel awful if you get rejected, and you're going to get rejected a lot. You'll also get interviewers who are awful and you come out of it feeling awful. But if you don't apply, you'll never get anywhere.

You nothing much to distinguish yourself from other candidates at the start. It boils down to your luck. You have to play your odds. If possible, get someone in the industry to check your CV for you. It helps.

Good luck.

Please thank Chris Lienert for spending his time with us if this helped you. You can reach him through Twitter.

People affectionately call this pattern the callback hell.

It kinda looks like this:

firstFunction(args, function() {
  secondFunction(args, function() {
    thirdFunction(args, function() {
      // And so on…
    });
  });
});

This is JavaScript for you. It’s mind-boggling to see nested callbacks, but I don’t think it’s a “hell”. The “hell” can be manageable if you know what to do with it.

On callbacks

I assume you know what callbacks are if you’re reading this article. If you don’t, please read this article for an introduction to callbacks before continuing. There, we talk about what callbacks are and why you use them in JavaScript.

Solutions to callback hell

There are four solutions to callback hell:

1. Write comments
2. Split functions into smaller functions
3. Using Promises
4. Using Async/await

Before we dive into the solutions, let’s construct a callback hell together. Why? Because it’s too abstract to see firstFunction, secondFunction, and thirdFunction. We want to make it concrete.

Constructing a callback hell

Let’s imagine we’re trying to make a burger. To make a burger, we need to go through the following steps:

1. Get ingredients (we’re gonna assume it’s a beef burger)
2. Cook the beef
3. Get burger buns
4. Put the cooked beef between the buns
5. Serve the burger

If these steps are synchronous, you’ll be looking at a function that resembles this:

const makeBurger = () => {
  const beef = getBeef();
  const patty = cookBeef(beef);
  const buns = getBuns();
  const burger = putBeefBetweenBuns(buns, beef);
  return burger;
};

const burger = makeBurger();
serve(burger);

However, in our scenario, let’s say we can’t make the burger ourselves. We have to instruct a helper on the steps to make the burger. After we instruct the helper, we have to WAIT for the helper to finish before we begin the next step.

If we want to wait for something in JavaScript, we need to use a callback. To make the burger, we have to get the beef first. We can only cook the beef after we get the beef.

const makeBurger = () => {
  getBeef(function(beef) {
    // We can only cook beef after we get it.
  });
};

To cook the beef, we need to pass beef into the cookBeef function. Otherwise, there’s nothing to cook! Then, we have to wait for the beef to get cooked.

Once the beef gets cooked, we get buns.

const makeBurger = () => {
  getBeef(function(beef) {
    cookBeef(beef, function(cookedBeef) {
      getBuns(function(buns) {
        // Put patty in bun
      });
    });
  });
};

After we get the buns, we need to put the patty between the buns. This is where a burger gets formed.

const makeBurger = () => {
  getBeef(function(beef) {
    cookBeef(beef, function(cookedBeef) {
      getBuns(function(buns) {
        putBeefBetweenBuns(buns, beef, function(burger) {
            // Serve the burger
        });
      });
    });
  });
};

Finally, we can serve the burger! But we can’t return burger from makeBurger because it’s asynchronous. We need to accept a callback to serve the burger.

const makeBurger = nextStep => {
  getBeef(function (beef) {
    cookBeef(beef, function (cookedBeef) {
      getBuns(function (buns) {
        putBeefBetweenBuns(buns, beef, function(burger) {
          nextStep(burger)
        })
      })
    })
  })
}

// Make and serve the burger
makeBurger(function (burger) => {
  serve(burger)
})

(I had fun making this callback hell example ?).

First solution to callback hell: Write comments

The makeBurger callback hell is simple to understand. We can read it. It just… doesn’t look nice.

If you’re reading makeBurger for the first time, you may think “Why the hell do we need so many callbacks to make a burger? It doesn’t make sense!”.

In such a case, you’d want to leave comments to explain your code.

// Makes a burger
// makeBurger contains four steps:
//   1. Get beef
//   2. Cook the beef
//   3. Get buns for the burger
//   4. Put the cooked beef between the buns
//   5. Serve the burger (from the callback)
// We use callbacks here because each step is asynchronous.
//   We have to wait for the helper to complete the one step
//   before we can start the next step

const makeBurger = nextStep => {
  getBeef(function(beef) {
    cookBeef(beef, function(cookedBeef) {
      getBuns(function(buns) {
        putBeefBetweenBuns(buns, beef, function(burger) {
          nextStep(burger);
        });
      });
    });
  });
};

Now, instead of thinking “wtf?!” when you see the callback hell, you get an understanding of why it has to be written this way.

Second solution to callback hell: Split the callbacks into different functions

Our callback hell example is already an example of this. Let me show you the step-by-step imperative code and you’ll see why.

For getBeef, our first callback, we have to go to the fridge to get the beef. There are two fridges in the kitchen. We need to go to the right fridge.

const getBeef = nextStep => {
  const fridge = leftFright;
  const beef = getBeefFromFridge(fridge);
  nextStep(beef);
};

To cook beef, we need to put the beef into an oven; turn the oven to 200 degrees, and wait for twenty minutes.

const cookBeef = (beef, nextStep) => {
  const workInProgress = putBeefinOven(beef);
  setTimeout(function() {
    nextStep(workInProgress);
  }, 1000 * 60 * 20);
};

Now imagine if you have to write each of these steps in makeBurger… you’ll probably faint from the sheer amount of code!

For a concrete example on splitting callbacks into smaller functions, you can read this small section in my callback article.

Third solution to callback hell: Use promises

I’m going to assume you know what promises are. If you don’t, please read this article.

Promises can make callback hell much easier to manage. Instead of the nested code you see above, you’ll have this:

const makeBurger = () => {
  return getBeef()
    .then(beef => cookBeef(beef))
    .then(cookedBeef => getBuns(beef))
    .then(bunsAndBeef => putBeefBetweenBuns(bunsAndBeef));
};

// Make and serve burger
makeBurger().then(burger => serve(burger));

If you take advantage of the single-argument style with promises, you can tweak the above to this:

const makeBurger = () => {
  return getBeef()
    .then(cookBeef)
    .then(getBuns)
    .then(putBeefBetweenBuns);
};

// Make and serve burger
makeBurger().then(serve);

Much easier to read and manage.

But the question is how do you convert callback-based code into promise-based code.

Converting callbacks to promises

To convert callbacks into promises, we need to create a new promise for each callback. We can resolve the promise when the callback is successful. Or we can reject the promise if the callback fails.

const getBeefPromise = _ => {
  const fridge = leftFright;
  const beef = getBeefFromFridge(fridge);

  return new Promise((resolve, reject) => {
    if (beef) {
      resolve(beef);
    } else {
      reject(new Error(“No more beef!”));
    }
  });
};

const cookBeefPromise = beef => {
  const workInProgress = putBeefinOven(beef);

  return new Promise((resolve, reject) => {
    setTimeout(function() {
      resolve(workInProgress);
    }, 1000 * 60 * 20);
  });
};

In practice, callbacks would probably be written for you already. If you use Node, each function that contains a callback will have the same syntax:

1. The callback would be the last argument
2. The callback will always have two arguments. And these arguments are in the same order. (Error first, followed by whatever you’re interested in).

// The function that’s defined for you
const functionName = (arg1, arg2, callback) => {
  // Do stuff here
  callback(err, stuff);
};

// How you use the function
functionName(arg1, arg2, (err, stuff) => {
  if (err) {
  console.error(err);
  }
  // Do stuff
});

If your callback has the same syntax, you can use libraries like ES6 Promisify or Denodeify (de-node-ify) that callback into a promise. If you use Node v8.0 and above, you can use util.promisify.

All three of them work. You can choose any library to work with. There are slight nuances between each method, though. I’ll leave you to check their documentation for how-tos.

Fourth solution to callback hell: Use asynchronous functions

To use asynchronous functions, you need to know two things first:

1. How to convert callbacks into promises (read above)
2. How to use asynchronous functions (read this if you need help).

With asynchronous functions, you can write makeBurger as if it’s synchronous again!

const makeBurger = async () => {
  const beef = await getBeef();
  const cookedBeef = await cookBeef(beef);
  const buns = await getBuns();
  const burger = await putBeefBetweenBuns(cookedBeef, buns);
  return burger;
};

// Make and serve burger
makeBurger().then(serve);

There’s one improvement we can make to the makeBurger here. You can probably get two helpers to getBuns and getBeef at the same time. This means you can await them both with Promise.all.

const makeBurger = async () => {
  const [beef, buns] = await Promise.all(getBeef, getBuns);
  const cookedBeef = await cookBeef(beef);
  const burger = await putBeefBetweenBuns(cookedBeef, buns);
  return burger;
};

// Make and serve burger
makeBurger().then(serve);

(Note: You can do the same with Promises… but the syntax isn’t as nice and as clear as async/await functions).

Wrapping up

Callback hell isn’t as hellish as you think. There are four easy ways to manage callback hell:

1. Write comments
2. Split functions into smaller functions
3. Using Promises
4. Using Async/await

This article was originally posted on my blog.
Sign up for my newsletter if you want more articles to help you become a better frontend developer.

In this article, I want to share some gotchas to watch out for if you intend to use await in loops.

Before you begin

I'm going to assume you know how to use async and await. If you don't, read the previous article to familiarize yourself before continuing.

Preparing an example

For this article, let's say you want to get the number of fruits from a fruit basket.

const fruitBasket = {
 apple: 27,
 grape: 0,
 pear: 14
};

You want to get the number of each fruit from the fruitBasket. To get the number of a fruit, you can use a getNumFruit function.

const getNumFruit = fruit => {
 return fruitBasket[fruit];
};

const numApples = getNumFruit(“apple”);
console.log(numApples); // 27

Now, let's say fruitBasket lives on a remote server. Accessing it takes one second. We can mock this one-second delay with a timeout. (Please refer to the previous article if you have problems understanding the timeout code).

const sleep = ms => {
 return new Promise(resolve => setTimeout(resolve, ms));
};

const getNumFruit = fruit => {
 return sleep(1000).then(v => fruitBasket[fruit]);
};

getNumFruit(“apple”).then(num => console.log(num)); // 27

Finally, let's say you want to use await and getNumFruit to get the number of each fruit in asynchronous function.

const control = async _ => {
 console.log(“Start”);

const numApples = await getNumFruit(“apple”);
 console.log(numApples);

const numGrapes = await getNumFruit(“grape”);
 console.log(numGrapes);

const numPears = await getNumFruit(“pear”);
 console.log(numPears);

console.log(“End”);
};

Console shows ‘Start’. One second later, it logs 27. Another second later, it logs 0. One more second later, it logs 14, and ‘End’

With this, we can begin looking at await in loops.

Await in a for loop

Let's say we have an array of fruits we want to get from the fruit basket.

const fruitsToGet = [“apple”, “grape”, “pear”];

We are going to loop through this array.

const forLoop = async _ => {
 console.log(“Start”);

for (let index = 0; index < fruitsToGet.length; index++) {
 // Get num of each fruit
 }

console.log(“End”);
};

In the for-loop, we will use getNumFruit to get the number of each fruit. We'll also log the number into the console.

Since getNumFruit returns a promise, we can await the resolved value before logging it.

const forLoop = async _ => {
 console.log(“Start”);

for (let index = 0; index < fruitsToGet.length; index++) {
 const fruit = fruitsToGet[index];
 const numFruit = await getNumFruit(fruit);
 console.log(numFruit);
 }

console.log(“End”);
};

When you use await, you expect JavaScript to pause execution until the awaited promise gets resolved. This means awaits in a for-loop should get executed in series.

The result is what you'd expect.

“Start”;
“Apple: 27”;
“Grape: 0”;
“Pear: 14”;
“End”;

Console shows ‘Start’. One second later, it logs 27. Another second later, it logs 0. One more second later, it logs 14, and ‘End’

This behavior works with most loops (like while and for-of loops)...

But it won't work with loops that require a callback. Examples of such loops that require a fallback include forEach, map, filter, and reduce. We'll look at how await affects forEach, map, and filter in the next few sections.

Await in a forEach loop

We'll do the same thing as we did in the for-loop example. First, let's loop through the array of fruits.

const forEachLoop = _ => {
 console.log(“Start”);

fruitsToGet.forEach(fruit => {
 // Send a promise for each fruit
 });

console.log(“End”);
};

Next, we'll try to get the number of fruits with getNumFruit. (Notice the async keyword in the callback function. We need this async keyword because await is in the callback function).

const forEachLoop = _ => {
 console.log(“Start”);

fruitsToGet.forEach(async fruit => {
 const numFruit = await getNumFruit(fruit);
 console.log(numFruit);
 });

console.log(“End”);
};

You might expect the console to look like this:

“Start”;
“27”;
“0”;
“14”;
“End”;

But the actual result is different. JavaScript proceeds to call console.log('End') before the promises in the forEach loop gets resolved.

The console logs in this order:

‘Start’
‘End’
‘27’
‘0’
‘14’

Console logs ‘Start’ and ‘End’ immediately. One second later, it logs 27, 0, and 14.

JavaScript does this because forEach is not promise-aware. It cannot support async and await. You cannot use await in forEach.

Await with map

If you use await in a map, map will always return an array of promise. This is because asynchronous functions always return promises.

const mapLoop = async _ => {
 console.log(“Start”);

const numFruits = await fruitsToGet.map(async fruit => {
 const numFruit = await getNumFruit(fruit);
 return numFruit;
 });

console.log(numFruits);

console.log(“End”);
};

“Start”;
“[Promise, Promise, Promise]”;
“End”;

Console logs ‘Start’, ‘[Promise, Promise, Promise]’, and ‘End’ immediately

Since map always return promises (if you use await), you have to wait for the array of promises to get resolved. You can do this with await Promise.all(arrayOfPromises).

const mapLoop = async _ => {
 console.log(“Start”);

const promises = fruitsToGet.map(async fruit => {
 const numFruit = await getNumFruit(fruit);
 return numFruit;
 });

const numFruits = await Promise.all(promises);
 console.log(numFruits);

console.log(“End”);
};

Here's what you get:

“Start”;
“[27, 0, 14]”;
“End”;

Console logs ‘Start’. One second later, it logs ‘[27, 0, 14] and ‘End’

You can manipulate the value you return in your promises if you wish to. The resolved values will be the values you return.

const mapLoop = async _ => {
 // …
 const promises = fruitsToGet.map(async fruit => {
 const numFruit = await getNumFruit(fruit);
 // Adds onn fruits before returning
 return numFruit + 100;
 });
 // …
};

“Start”;
“[127, 100, 114]”;
“End”;

Await with filter

When you use filter, you want to filter an array with a specific result. Let's say you want to create an array with more than 20 fruits.

If you use filter normally (without await), you'll use it like this:

// Filter if there’s no await
const filterLoop = _ => {
 console.log(‘Start’)

const moreThan20 = await fruitsToGet.filter(fruit => {
 const numFruit = fruitBasket[fruit]
 return numFruit > 20
 })

console.log(moreThan20)
 console.log(‘End’)
}

You would expect moreThan20 to contain only apples because there are 27 apples, but there are 0 grapes and 14 pears.

“Start”[“apple”];
(“End”);

await in filter doesn't work the same way. In fact, it doesn't work at all. You get the unfiltered array back...

const filterLoop = _ => {
 console.log(‘Start’)

const moreThan20 = await fruitsToGet.filter(async fruit => {
 const numFruit = getNumFruit(fruit)
 return numFruit > 20
 })

console.log(moreThan20)
 console.log(‘End’)
}

“Start”[(“apple”, “grape”, “pear”)];
(“End”);

Console loggs ‘Start’, ‘[‘apple’, ‘grape’, ‘pear’]’, and ‘End’ immediately

Here's why it happens.

When you use await in a filter callback, the callback always a promise. Since promises are always truthy, everything item in the array passes the filter. Writing await in a filter is like writing this code:

// Everything passes the filter…
const filtered = array.filter(true);

There are three steps to use await and filter properly:

1. Use map to return an array promises

2. await the array of promises

3. filter the resolved values

const filterLoop = async _ => {
 console.log(“Start”);

const promises = await fruitsToGet.map(fruit => getNumFruit(fruit));
 const numFruits = await Promise.all(promises);

const moreThan20 = fruitsToGet.filter((fruit, index) => {
 const numFruit = numFruits[index];
 return numFruit > 20;
 });

console.log(moreThan20);
 console.log(“End”);
};

Start[“apple”];
End;

Console shows ‘Start’. One second later, console logs ‘[‘apple’]’ and ‘End’

Await with reduce

For this case, let's say you want to find out the total number of fruits in the fruitBastet. Normally, you can use reduce to loop through an array and sum the number up.

// Reduce if there’s no await
const reduceLoop = _ => {
 console.log(“Start”);

const sum = fruitsToGet.reduce((sum, fruit) => {
 const numFruit = fruitBasket[fruit];
 return sum + numFruit;
 }, 0);

console.log(sum);
 console.log(“End”);
};

You'll get a total of 41 fruits. (27 + 0 + 14 = 41).

“Start”;
“41”;
“End”;

Console logs ‘Start’, ‘41’, and ‘End’ immediately

When you use await with reduce, the results get extremely messy.

// Reduce if we await getNumFruit
const reduceLoop = async _ => {
 console.log(“Start”);

const sum = await fruitsToGet.reduce(async (sum, fruit) => {
 const numFruit = await getNumFruit(fruit);
 return sum + numFruit;
 }, 0);

console.log(sum);
 console.log(“End”);
};

“Start”;
“[object Promise]14”;
“End”;

Console logs ‘Start’. One second later, it logs ‘[object Promise]14’ and ‘End’

What?! [object Promise]14?!

Dissecting this is interesting.

• In the first iteration, sum is 0. numFruit is 27 (the resolved value from getNumFruit(‘apple’)). 0 + 27 is 27.
• In the second iteration, sum is a promise. (Why? Because asynchronous functions always return promises!) numFruit is 0. A promise cannot be added to an object normally, so the JavaScript converts it to [object Promise] string. [object Promise] + 0 is [object Promise]0
• In the third iteration, sum is also a promise. numFruit is 14. [object Promise] + 14 is [object Promise]14.

Mystery solved!

This means, you can use await in a reduce callback, but you have to remember to await the accumulator first!

const reduceLoop = async _ => {
 console.log(“Start”);

const sum = await fruitsToGet.reduce(async (promisedSum, fruit) => {
 const sum = await promisedSum;
 const numFruit = await getNumFruit(fruit);
 return sum + numFruit;
 }, 0);

console.log(sum);
 console.log(“End”);
};

“Start”;
“41”;
“End”;

Console logs ‘Start’. Three seconds later, it logs ‘41’ and ‘End’

But... as you can see from the gif, it takes pretty long to await everything. This happens because reduceLoop needs to wait for the promisedSum to be completed for each iteration.

There's a way to speed up the reduce loop. (I found out about this thanks to Tim Oxley. If you await getNumFruits() first before await promisedSum, the reduceLoop takes only one second to complete:

const reduceLoop = async _ => {
 console.log(“Start”);

const sum = await fruitsToGet.reduce(async (promisedSum, fruit) => {
 // Heavy-lifting comes first.
 // This triggers all three getNumFruit promises before waiting for the next iteration of the loop.
 const numFruit = await getNumFruit(fruit);
 const sum = await promisedSum;
 return sum + numFruit;
 }, 0);

console.log(sum);
 console.log(“End”);
};

Console logs ‘Start’. One second later, it logs ‘41’ and ‘End’

This works because reduce can fire all three getNumFruit promises before waiting for the next iteration of the loop. However, this method is slightly confusing since you have to be careful of the order you await things.

The simplest (and most efficient way) to use await in reduce is to:

1. Use map to return an array promises

2. await the array of promises

3. reduce the resolved values

const reduceLoop = async _ => {
 console.log(“Start”);

const promises = fruitsToGet.map(getNumFruit);
 const numFruits = await Promise.all(promises);
 const sum = numFruits.reduce((sum, fruit) => sum + fruit);

console.log(sum);
 console.log(“End”);
};

This version is simple to read and understand, and takes one second to calculate the total number of fruits.

Console logs ‘Start’. One second later, it logs ‘41’ and ‘End’

Key Takeaways

1. If you want to execute await calls in series, use a for-loop (or any loop without a callback).

2. Don't ever use await with forEach. Use a for-loop (or any loop without a callback) instead.

3. Don't await inside filter and reduce. Always await an array of promises with map, then filter or reduce accordingly.

This article was originally posted on my blog.
Sign up for my newsletter if you want more articles to help you become a better frontend developer.

If you want to create a package that’s usable in both browsers and Node, this article is here to help.

You’ll learn:

1. How to write packages for use in browsers

2. How to write packages for use in Node

3. How to publish your packages for use in both browsers and Node

Writing a package for use in browsers

If you want to include a library in frontend JavaScript, you have to link the library first with a script tag. You can use the library anytime after you link it.

<!-- This is html -->

<script src="link-to-jquery.js"></script>

<script>  // You can use jQuery anytime after you link to it  console.log(jQuery)</script>

This works because JavaScript in browsers shares one global scope. It doesn’t matter how many JavaScript files you link to. They behave as if they’re one big JavaScript file.

With this information, we can begin writing a library for use in the frontend world.

Let’s say you want to create a library called peachBlossom. peachBlossom has a bloom function. You write this bloom function in a separate JavaScript file, peach-blossom.js.

// This is js

// peach-blossom.jsfunction bloom () {  console.log('Bloom!')}

You can include peachBlossom in your frontend JavaScript by linking to the peach-blossom.js file. Once you do this, you can use bloom anywhere.

<!-- This is html -->

<script src="peach-blossom.js"></script><script src="main.js"></script>

// This is js

// main.jsbloom() // Bloom!

Libraries usually have more than one piece of code. We don’t want to pollute the global scope with little variables. What we can do is wrap the functions we want to expose in an immediately-invoked function expression (IIFE).

This means:

1. We create a function and run it immediately
2. We return the library from within the function so we can use the library later.

In code, it looks somewhat like this:

// This is js

// peach-blossom.js const peachBlossom = (function () {  // Write as much code as you want here

// Return what others can use  return {    bloom: function () {      console.log('Bloom!')    }  }})()

You can then use bloom anywhere by writing peachBlossom.bloom.

// This is js

// main.jspeachBlossom.bloom() // Bloom!

This is the basics of writing a frontend library.

Now, let’s talk about writing a library for Node.

Writing a package for Node

Adding a library to Node is different from adding a library to browsers. This is because Node doesn’t have HTML files and <script> tags.

Let’s make sure you know how to run Node before we begin writing a library for Node.

Running Node

First, you need to make sure you have Node installed on your computer. You can install Node from Node’s website if you don’t have it installed already.

Once you have Node installed, you’ll want to create a folder to store your Node project. In this case, let’s call it “node-project”.

The command to create a folder is this:

# This is bash

mkdir node-project

Then, you need to navigate to the node-project directory. You can do it with cd:

# This is bashcd node-project

If you’re having problems with the command line, you can use this guide to help you out.

Next, we want to create a file. This will be a JavaScript file. (We will run Node on this file). Let’s call it index.js.

# This is bash

touch index.js

In index.js, we’re going to write a console.log statement. This is for us to know if we run the file.

// This is js

// index.jsconsole.log('Running index.js!')

Finally, you can use node to run index.js. Here’s the command:

# This is bash

node index.js

Once you run index.js, you should see the console.log in the terminal. That’s how we know the file has run.

Adding libraries to Node

To add libraries to Node, you have to use the require statement. Once you add a library, you can use the library anywhere in the same JavaScript file.

Here’s an example:

// This is js

const fs = require('fs')console.log(fs)

When you use require, Node looks for the library you specified in three places:

First, it checks whether the library is built into Node. In this example, fs is built directly into Node. You can use fs anytime if you use Node.

Second, it checks whether the library exists in the node_modules folder. These are user-installed libraries. You can add a library to the node_modules folder by running npm install.

Here’s an example where we install express, then require express in Node:

# This is bash

# Run this in the command linenpm install express

// This is js

// Index.js const express = require('express')console.log(express)

Third, if you add ./ to require, Node will look for a file located in the current directory. This is where we can begin writing the peach-blossom library.

Writing your first library for Node

Let’s start by creating a peach-blossom.js file. This file should be in the same directory as index.js.

// This is js

touch peach-blossom.js

We can add peach-blossom.js to index.js by using require. Here’s what it looks like:

// This is js

const peachBlossom = require('./peach-blossom')

In Node, there’s no concept of a shared global scope. Each file has its own scope. So, if you write peach-blossom.js as if it’s used for frontend JavaScript, you won’t be able to use it. You’ll get an error.

// This is js

// peach-blossom.js const peachBlossom = (function () { // Write as much code as you want here

// Return what others can use return { bloom: function () { console.log(‘Bloom!’) } }})()

// This is js

// index.js const peachBlossom = require(‘./peach-blossom’)

To pass variables from one file to another in Node, you have to write module.exports. Variables passed to module.exports can be retrieved from another file.

This means we must write module.exports in peach-blossom.js.

// This is js

// Write as much code as you want here const peachBlossom = { bloom () { console.log(‘Bloom!’) }}

// Exports peachBlossom for use in other filesmodule.exports = peachBlossom

Once we have exported peachBlossom, we can use it in other files:

// This is js

// index.js const peachBlossom = require('./peach-blossom')peachBlossom.bloom() // Bloom!

This format of passing variables around in Node with `require` and `module.exports` is called **CommonJS**.

#### Publishing your library as an npm package

In short, to make your module work in Node, you have to export a variable with `module.exports`. Other people can then `require` this module in their code.

At this point, you can move `peach-blossom` into a separate project folder and publish it as an npm package. You can use [this guide](https://zellwk.com/blog/publish-to-npm/) to find out more about publishing the process.

### Writing modules that are usable in both frontend and backend JavaScript

Let’s take a moment to reconcile what we know.

To write a library for the frontend, we need to declare it as a variable. As much as possible, we want to expose one variable only.

// This is js

const peachBlossom = (function () { // Write as much code as you want here

// Return what others can use return { bloom: function () { console.log('Bloom!') } }})()

To write a library for the Node, we need to export the variable with `module.exports`. Here, we only expose one variable.

// This is js// Write as much code as you want here const peachBlossom = { bloom () { console.log('Bloom!') }}

// Exports peachBlossom for use in other filesmodule.exports = peachBlossom

But these are two completely different formats! How can we write a library once and use it in both contexts?

Enter UMD.

#### UMD

[UMD (Universal Module Definition](https://github.com/umdjs/umd)) is a block of code we can use to wrap around our library. This block of code makes it possible to use a library both on the frontend and in Node.

It kinda looks like this:

// This is js

(function (root, factory) { if (typeof define === 'function' && define.amd) { // AMD. Register as an anonymous module. define(['b'], factory); } else if (typeof module === 'object' && module.exports) { // Node. module.exports = factory(require('b')); } else { // Browser globals (root is window) root.returnExports = factory(root.b); }}(typeof self !== 'undefined' ? self : this, function (b) { // Use b in some fashion.

// Just return a value to define the module export. // This example returns an object, but the module // can return a function as the exported value. return {};})); ```

Whoa! This is confusing! Hold up!

In practice, we don’t have to know how to UMD-ify our code by ourselves. Many tools, like Webpack and Parcel, gives us the ability to UMD-ify our code through them.

Here are some examples (and their relevant setup instructions):

1. Gulp-umd
2. Webpack
3. Parcel
4. Rollup

This, means you have to set up these tools if you want to write packages that can be used for both Frontend JavaScript and in Node. Yes, it complicates the authoring process, but there’s nothing much we can do about it at this point.

Wrapping up

If you want your library to work both on Frontend JavaScript and in Node, you need to wrap your module with UMD (Universal Module Definition).

If you want to UMD-ify your code, you need to use a build tool when you author your package. This makes the authoring process more complicated. But the tradeoff can be worth it for providing users with an option to use your library anywhere.

This article was originally posted on my blog.
Sign up for my newsletter if you want more articles to help you become a better frontend developer.

1. With the .gitignore file
2. With the .npmignore file
3. With the files property

We’ll look at each method and discuss which methods you should (or shouldn’t) be using.

Excluding files with gitignore

First, npm will check your repository for a .gitignore file. If there is a .gitignore file, npm will ignore files according to what’s listed in the .gitignore file.

This is the most common way package authors prevent people from downloading extra files.

Let’s go through a simple example. Say you have the following directory structure.

- project-name/   |- index.js   |- package.json   |- node_modules/

Let’s say you don’t want people to download the node_modules folder. You also don’t want to save the node_modules in the Git repository.

What you’ll do is create a .gitignore file.

# .gitignore node_modules

In this case, both Git and npm ignore the node_modules folder.

Blacklisting files with npmignore

A second way is to blacklist files with a .npmignore file. The .npmignore file works the same way as a .gitignore file. If a file is listed in the .npmignore file, the file will be excluded from the package.

Important note: If you have a .npmignore file, npm will use the .npmignore file. npm will ignore the .gitignore file altogether. (Many developers mistakenly believe npm will use both .npmignore and .gitignore files. Don’t make the same mistake!)

You can use this method if you want to exclude files from the package but still keep them in the Git repository.

Let’s walk through another example. Let’s say you’ve written tests for your package and you put them all in a tests folder. This is your directory structure:

- project-name/  |- index.js |- package.json |- node_modules/ |- tests/

You want to exclude node_modules from both your Git repository and your package.

You want to include tests in your Git repository, but exclude it from the package.

If you opt for the npmignore file method, you can write these in your .gitignore and .npmignore files:

# .gitignore node_modules

# .npmignore node_modules tests

Whitelisting files with the files property

A third method is to whitelist files you want to be included in the package.json file, under the files property.

Note: npm will prioritize this method over other methods mentioned above. This is the easiest method to limit what files others download.

This approach is pretty simple. What you need is to create a files property in the package.json file. Then, provide a list of files you’d like to include.

Here’s an example:

{   "files": [      "index.js"   ] }

Note: Some files, like package.json, are always included in a package. You don’t have to write these files in the files property.

Which method to use?

All three methods work. Pick the one you’re most comfortable with. For simple projects, the .gitignore file method should suffice.

If your project is more advanced, you might want to blacklist files with .npmignore or whitelist files with the files property. Pick one. There’s no need for both.

A quick tip

You can use npm pack to generate a package. This package includes files other people will get.

npm pack

Try it!

Thanks for reading. Did this article help you out? If it did, I hope you consider sharing it. You might help someone else out. Thanks so much!

This article was originally posted on my blog.
Sign up for my newsletter if you want more articles to help you become a better front-end developer.

1. Create your package.
2. Publish the package.

But publishing packages the way the industry does it? Not so simple. There are more steps. We’ll go through what steps are required, and I’ll show you an easy way to publish and update your package.

Creating your first package

This section is for you if you haven’t published a package to npm before. Feel free to skip to the next section if you published one before.

To publish your first package to npm, you need to go through these steps:

First, you need to have an npm account. Create one here if you don’t have one yet.

Second, you need to login to your npm account through the command line. (You need to have Node and npm installed on your system before you perform this step. Install them here).

To sign in, you use npm login.

npm login

You’ll be prompted to enter your username, password, and email address.

Third, you need to create a package. To do so, create a folder somewhere on your computer and navigate to it. The command line version is:

# Creating a folder named how-to-publish-to-npm mkdir how-to-publish-to-npm # Navigating into the folder cd how-to-publish-to-npm

Next, you want to begin the project with the npm init command.

npm init

This command runs you through a few questions and creates a package.json file for you at the end. This package.json file contains the bare necessities you need to publish your project. (Feel free to skip questions that don’t make sense).

The final step is to publish your package with the npm publish command.

npm publish

If the package already exists on npm (because your package has the same name as another package on npm), you won’t be able to publish it. You’ll get an error.

You’ll need to change your package name.

To change your package name, you change the name property in the package.json file. Here, I changed it to publishing-to-npm.

(You can check for naming collisions by doing a search on npm, or through the npm search command).

It’s also a good idea to update the folder name as well for consistency. Here’s the command line equivalent.

# Command to change folder names by moving everything mv how-to-publish-to-npm publishing-to-npm

Try the publish command again. You should get a success message now.

What to do if every name you came up with is taken already

This is a common problem since many people create packages on npm. It’s difficult to get the package name you desire sometimes. (It’s like how I can never find a good .com domain).

To combat this problem, npm lets you publish to a scope. This means you can publish the package under your own username (or npm organization), so you’re free from naming problems.

To publish to a scope, you can either:

1. Change the name to @username/package-name manually in package.json
2. Run npm init --scope=username instead of npm init

If your repository has a scope, you need to adjust the publish command slightly:

npm publish --access public

That’s all you need to do to publish a package to npm.

Now, let’s move on to how the industry publishes packages.

Consider a popular framework like React. If you dig around React, you’ll notice a few things:

First, React has a Github repository.

Second, React is published on npm.

Third, React follows Semantic versioning (Semver for short).

Fourth, each update to React has a git tag associated with it. This git tag follows Semver as well.

Fifth, there are release notes for every React update.

This means publishing a package involves many steps. At the very least, you need to:

1. Run tests (if there are any)
2. Update version in package.json according to Semver
3. Create a git tag according to Semver
4. Push the package to Github
5. Push the package to npm
6. Create release notes for every update

It’s common to forget one of these things when we’re ready to push. Sometimes we npm publish and we enjoy a break. When we’re back, we screw ourselves for forgetting.

There’s an easier way. It’s with a tool called np.

np

np (created by Sindre Sorhus) makes it easier for us to publish packages without missing any of the steps I detailed above.

Installing np

To install np, you can run the following command:

npm install np

This works. But I prefer installing np globally on my computer so I can run the np command anywhere.

sudo npm install --global np

Before using np

Before you use np you need to make sure:

1. Your project is a Git repository
2. It needs to have a remote
3. You must have pushed to the remote at least once.
4. You also need to make sure your working directory is clean.

# Initialize Git git init # Adds a remote repository git remote add origin some-url # Commit changes git add . git commit -m "Initial Commit"

If your project is not a Git repository, you’ll get this error:

If your project doesn’t have remote, you’ll get this error (at a later part of the checks).

If your working directory is dirty, you’ll get this error:

If you haven’t pushed to the Git remote at least once, np will just hang and do nothing.

Using npm

To use np, you run the np command.

np

np will prompt you to enter a Semver number.

Choose a number and np will ask you to confirm your choice.

np then does the rest of the publishing stuff for you.

Error with running tests

np runs the npm test command as part of its checks.

If you followed the tutorial up to this point, you would get an error that looks like this:

This happens because our npm test command results in an error. You can try it yourself:

npm test

To fix this error, we need to change the test script in package.json file.

Right now it looks like this:

"scripts": {     "test": "echo \"Error: no test specified\" && exit 1"},

Change it to this:

"scripts": {     "test": "echo \"No test specified\""},

This change works because exit 1 creates an error.

With this change, np should complete the publishing process. (Remember to commit the change before running np).

At the end of the process, np launches a browser window for you to write your release notes.

In short, np makes publishing packages much simpler!

Thanks for reading. Did this article help you out? If it did, I hope you consider sharing it. You might help someone else out. Thanks so much!

This article was originally posted at my blog.
Sign up for my newsletter if you want more articles to help you become a better frontend developer.

The most newbie-friendly way to add a library to a project is to:

1. Search for the library
2. Look for the source file
3. Copy the source file
4. Paste what you copied into the project.

This works, but it’s a painful process. It’s easier if you use CDNs like JSDelivr.

What is a CDN?

CDN stands for content delivery network. Its main purpose is to let users download files faster. Read this article by Fastly if you’re wondering whether you should use a CDN.

CDNS let users download files faster by placing datacenters all over the world. When the browser sees a CDN link, they’ll serve up the library from the datacenter closest to the user. This is how CDNs work.

What is JSDelivr?

JSDelivr is a special kind of CDN. It’s built to let users download JavaScript libraries that are hosted on npm and Github. (You can also load Wordpress plugins if they’re hosted on Wordpress.org).

If you use JSDelivr (or any other CDN that serves JavaScript libraries), you don’t need to copy-paste the source files into your project. You can use a link like this:

<script src="https://cdn.jsdelivr.net/npm/package-name"><;/script>

JSDelivr lets you specify the version of a library you want to download. If you want to specify a version, you add the version number after an @, like this:

<script src="https://cdn.jsdelivr.net/npm/[email protected]"><;/script>

How I use JSDelivr

I use JSDelivr more like a package manager since JSDelivr lets you specify the version of a library. I can upgrade or downgrade the library by changing a number. There’s no need to copy-paste the original source into my project.

However, I rarely use JSDelivr nowadays because I already have a build process that uses Webpack. Webpack lets you require libraries into frontend JavaScript. It lets you use npm as a package manager.

I only use JSDelivr for projects that:

1. Require a library
2. The library exists on JSDelivr (or other CDNs)
3. The project doesn’t have Webpack (or similar tools installed)

One example of such a project is the 20 components in Learn JavaScript.

Here’s why.

Students who’re enrolled in Learn JavaScript are trying to learn JavaScript. I don’t want to distract them by making them learn Webpack.

Instead, I want to help them focus on what they’re here for — learning JavaScript. I do this by removing complexity from projects we build together. I strip everything down to plain old HTML, CSS, and JavaScript.

We’ve talked about what is JSDelivr, why use it, and when to use it. Let’s dive into the details of using it now.

For the rest of the article, we’ll use a library called zl-fetch as an example.

Installing a library

To install a library, you need to add a <script> tag that points to the library on JSDelivr. You can load the library from npm or Github, depending on your preferences.

I tend to load libraries from npm.

<script src="https://cdn.jsdelivr.net/npm/package-name"><;/script>

You need to change package-name to the name of the library you’re installing. In this case, it’s zl-fetch.

<script src="https://cdn.jsdelivr.net/npm/zl-fetch"><;/script>

If you’re unsure of the name of the library, you can search on npm, or directly on JSDelivr.

Specifying a version

By default, JSDelivr downloads the latest version of a library.

I don’t recommend you use the latest version because authors may update their library. If they update their library, your code may break.

You always want to specify a version number. You can add a version number by adding @, followed by the version number after the package name, like this:

<script src="https://cdn.jsdelivr.net/npm/[email protected]"><;/script>

Version numbers follow a Semver format. You can tell what versions are available by checking the available tags on Github.

In our case, the current version of zl-fetch is 2.1.9:

<script src="https://cdn.jsdelivr.net/npm/[email protected]"><;/script>

Loading a specific file

JSDelivr relies on authors to specify a default file for the above format to work. If the default file is not specified, you need to point to the correct file.

<script src="https://cdn.jsdelivr.net/npm/[email protected]/path-to-file"><;/script>

There are two ways to know what files are available.

First, you can search for the package on JSDelivr. You’ll see a list of files and folders you can point to:

Second, if you know about npm, you can use npm to install the package somewhere on your computer. Then use your Finder (or Explorer) to browse through the files.

In this case, let’s say the default file is not specified, and we want the dist/index.js file. Here’s what you’ll write:

<script src="https://cdn.jsdelivr.net/npm/[email protected]/dist/index.js"><;/script>

Loading a minified version

Minified files are usually smaller in size. Users will be able to download the minified files faster than an unminified file.

JSDelivr minifies files automatically if you use the .min.js extension.

<script src="https://cdn.jsdelivr.net/npm/[email protected]/dist/index.min.js"><;/script>

Wrapping up

I hope this article gives you a good overview of what JSDelivr can do.

Thanks for reading. Did this article help you out? If it did, I hope you consider sharing it. You might help someone else out. Thanks so much!

This article was originally posted at my blog.
Sign up for my newsletter if you want more articles to help you become a better frontend developer.

In this article, I want to share these preferences with you, my personal CSS reset (that I use in addition to Normalize.css).

I categorize the resets into 8 categories:

1. Box sizing

2. Removing margins and paddings

3. Lists

4. Forms and buttons

5. Images and embeds

6. Tables

7. The hidden attribute

8. Noscript

Box Sizing

The box-sizing property changes how the CSS Box model works. It changes how width, height, padding, border, and margin properties are calculated.

The default setting for box-sizing is content-box. I prefer changing this to border-box because it’s easier for me to style padding and width.

For more info on Box Sizing, you might be interested in “Understanding Box sizing”.

html {
  box-sizing: border-box;
}
*,
*::before,
*::after {
  box-sizing: inherit;
}

Removing margins and paddings

Browsers set different margins and paddings for different elements. These default settings throw me off when I’m not aware. When I code, I prefer to set all margins and paddings myself.

/* Reset margins and paddings on most elements */
body,
h1,
h2,
h3,
h4,
h5,
h6,
ul,
ol,
li,
p,
pre,
blockquote,
figure,
hr {
  margin: 0;
  padding: 0;
}

Lists

I use unordered lists in many situations, and I don’t need a disc style in most of them. Here, I set list-style to none. When I need the discstyle, I set it back manually on the specific <ul>.

/* Removes discs from ul */
ul {
  list-style: none;
}

Forms and buttons

Browsers don’t inherit typography for forms and buttons. They set font to 400 11px system-ui. I find this mind-boggling and weird. I always have to make them inherit from ancestor elements manually.

input,
textarea,
select,
button {
  color: inherit; 
  font: inherit; 
  letter-spacing: inherit; 
}

Different browsers have styled the borders for forms elements and buttons differently. I dislike these default styles, and would prefer to set them to 1px solid gray.

button {
  border-radius: 0; 
  padding: 0.75em 1em;
  background-color: transparent;
}

I made a few more adjustments to buttons:

1. Set button padding to 0.75em and 1em because they seem like sensible defaults from my experience.
2. Removed the default border-radius that’s applied to buttons.
3. Forced background color to be transparentbutton { border-radius: 0; padding: 0.75em 1em; background-color: transparent; }

Finally, I set pointer-events: none to elements within a button. This is mainly used for JavaScript interaction.

(When users click on something in a button, event.target is the thing they clicked on, not the button. This style makes it easier to work with click events if there are HTML elements inside a button).

css button * {   pointer-events: none; }

Media elements include images, videos, objects, iframes, and embed. I tend to let these elements conform to the width of their containers.

I also set these elements to display: block because inline-blockcreates unwanted whitespace at the bottom of the element.

embed,
iframe,
img,
object,
video {
  display: block;
  max-width: 100%;
}

Tables

I rarely use tables, but they may be useful sometimes. Here’s the default styles I’ll begin with:

table {
  table-layout: fixed;
  width: 100%;
}

When an element has a hidden attribute, they should be hidden from view. Normalize.css does this for us already.

[hidden] {
  display: none;
}

The problem with this style is its low specificity.

I often add hidden to other elements I style with a class. A class’s specificity is high than an attribute, and the display: none property doesn’t work.

This is why I opt to bump up [hidden]'s specificity with !important.

[hidden] {
  display: none !important;
}

Noscript

If a component requires JavaScript to work, I’ll add a <noscript> tag to let users know (if they’ve disabled JavaScript).

This creates default styles for the <noscript> tag.

/* noscript styles */
noscript {
  display: block;
  margin-bottom: 1em;
  margin-top: 1em;
}

Wrapping up

Everyone begins their projects differently. Please feel free to use any of these styles I mentioned. Here’s a Github repo of my personal CSS Resets.

Do you have any recommendations that would help improve this CSS Reset file? If you do, feel free to reach out and let me know!

Thanks for reading. Did this article help you out? If it did, I hope you consider sharing it. You might help someone else out. Thanks so much!

This article was originally posted at my blog. Sign up for my newsletter if you want more articles to help you become a better frontend developer.