Forem: Momentum

What to do if you accidentally committed your node_modules

Amy Gori — Thu, 06 Aug 2020 13:49:04 +0000

So here you are, npm installing stuff, happily committing code in your project. Things are going well! While looking up a tricky bit of syntax, you stumble across the following advice: Don't commit your node_modules!

Why don't you commit them?

You don't need to track automatically generated files like node_modules, which are the front end dependencies listed in your project's package.json. Running npm install will create (or update) node_modules. There's no reason for these packages to be in version control, since npm can manage them for you.

But I already committed them 😕

If you have already mistakenly committed these files, you need a way to tell git that you don't want to track them anymore. But you still want to keep them in your project, since they contain code that your project depends on.

With git, there is (almost) always a way! Just follow these steps to get your repo in order.

Tell git to ignore `node_modules`

Git will exclude any files or directories listed in the aptly named .gitignore file, so changes to files listed there will be treated as if they don't exist. Our first step is making sure node_modules is on the gitignore list.

If you don't have a gitignore file, now's a great time to make one! You can get ready-made, project-specific contents at gitignore.io, but you can make a new empty file now and add more to it later.

For all the following commands, you'll need to use the command line (don't type the $; that just indicates the command line prompt).

If you need to, create a gitignore file at the project root:

$ touch .gitignore

Open .gitignore in your code editor and add the name of the directory you don't want git to track, anywhere in that file:

# anywhere in .gitignore
node_modules

This is a pattern for git to match, not a path, so it will ignore any file or directory in your repo named 'node_modules'.

Go ahead and add the gitignore file to be committed. We definitely want other project contributors not to track node_modules.

$ git add .gitignore

If you had not already committed node_modules, this step would be all you need. You could go ahead and commit the changes and you'd be done.

Remove the files from git's index

If you committed node_modules before they were added to the gitignore file, git is going to notice changes each time you add and install a new package, when the node_modules directory changes. So we need one more step to seal the deal.

$ git rm -r --cached node_modules

What you will see now if you check git status is that any files in node_modules that were shown in red are now in green. This means that they are staged in git. They are also marked as deleted.

Details of what this command does

rm is a git command that tells git to stage the removal of the file from tracking.
-r is an option that tells git to perform the rm command recursively. A recursive operation is necessary because we have a directory that contains other files and other directories, so we have to dig into each of those to delete all of them.
--cached refers to git's cache, also called the index, where changes to files can be staged for committing. This option ensures that we are not deleting the files themselves, only removing the reference to their changes.

Now we need to commit our changes. This commit will include our .gitignore addition from the previous step.

git commit -m "Remove and ignore node_modules"

And now, huzzah! 🎉 Your project dependencies are still intact, but node_modules will no longer show up in your git index when they change. You can safely push this commit to GitHub, where you will no longer see a node_modules directory in your project. That's what we want!

This works with any other files you've accidentally committed

You can use these same steps for anything else that you accidentally commit. Add the file to your .gitignore, then use git rm --cached <filename> to stage the deletion of the file from the index. For example:

$ git rm -r --cached static/js/webpack_bundles
$ git rm --cached webpack-stats.json # if it's a file, you don't need the recursive option

Take extra steps to deal with sensitive information

It's important to note that git rm will remove files in current and future commits, but will not remove them from the history. This usually doesn't pose a problem, but if you've accidentally committed a file that should be erased from history because it contains sensitive information (like API keys or credentials for services like AWS), consult GitHub's comprehensive guide on what to do.

Why all the fuss, git?

Git's whole purpose is to track what has changed in your project. When a file gets created in a git repo, you have to explicitly tell git to start tracking that file in the first place. For a complete record of what has happened in the course of project development, we also want to record when those files are deleted or no longer tracked. That is what we use git rm to do and why a commit is made. It's just another bookmark in the history.

Get the value of a CSS variable in JavaScript

Clinton N. Dreisbach — Sun, 12 Jul 2020 18:19:18 +0000

I use CSS variables for color values all the time, and I often want to replicate them in JavaScript for charts and other graphics. Instead of copying the colors, I use this function:

function getCssVar (varName) {
  return getComputedStyle(document.body)
   .getPropertyValue(`--${varName}`)
}

How to build a front-end app before you have an API

Clinton N. Dreisbach — Tue, 30 Jun 2020 15:51:02 +0000

When developing an application that relies on an API that has not yet been created or finished, we run into a major chicken-and-egg problem. How can we make an application that talks to something that doesn't yet exist? If we're doing this in JavaScript, we can start by creating a facade for our API.

What's a facade? All this means is that we write our own objects or functions that we call instead of directly making API calls from our code. Instead of making those API calls directly, we use our objects or functions, which we'll use to decide how to talk to the API (or provide us with mock data.)

For the rest of this post, I'm going to assume we're using React and building our code with create-react-app. These ideas apply whether that's the case or not, but I'm going to rely on process.env.NODE_ENV existing, which is provided in create-react-app applications, since they are built with Babel and Node.

Option 0: hard-code our data

I choose this option whenever I start a new React application, but only use it for a short while, and I recommend we only use it at the very beginning to get something on the page. We can set a default state and display the results. Imagine we're building a simple application to create and display notes. We could write something like the following for a NoteList component:

function NoteList ({authToken}) {
  const [notes, setNotes] = useState([
    { id: 1, body: 'Note 1', color: 'blue' },
    { id: 2, body: 'Note 2', color: 'yellow' },
    { id: 3, body: 'Note 3', color: 'pink' }
  ])

  // render our notes
}

Option 1: use mock data

This option is great early on, especially if we don't even have a specification for the API. We might not know what the data we'll get back looks like, but we know what data we'll need, so we can start there. For our note application, we'll need to log in, get a list of notes, and create new notes.

We could create the following functions in a file called api.js.

const notes = [
  { id: 1, body: 'Note 1', color: 'blue' },
  { id: 2, body: 'Note 2', color: 'yellow' },
  { id: 3, body: 'Note 3', color: 'pink' }
]

let lastNoteId = 3

export function getAuthToken (username, password) {
  return 'testtoken'
}

export function getNotes (authToken) {
  return notes
}

export function storeNote (authToken, note) {
  lastNoteId += 1
  note.id = lastNoteId
  notes.push(note)
  return note
}

This won't quite work, though. Depending on our client for making AJAX calls, we might be dealing with callbacks or promises. Again, I'm going to make an assumption that you're using Axios, which uses promises. In order to return promises from our code, we'll need to change it a bit.

export function getAuthToken (username, password) {
  return new Promise((resolve, reject) => {
    resolve({
      token: 'testtoken'
    })
  })
}

export function getNotes (authToken) {
  return new Promise((resolve, reject) => {
    resolve({ notes: notes })
  })
}

export function storeNote (authToken, note) {
  lastNoteId += 1
  note.id = lastNoteId
  notes.push(note)
  return new Promise((resolve, reject) => {
    resolve(note)
  })
}

Now we have a promise-based interface, which will let us use these in the same way we'll eventually deal with real API calls. Here's an example of a NoteList React component we might write:

import { getNotes } from './api.js'

function NoteList ({authToken}) {
  const [notes, setNotes] = useState([])

  useEffect(() => {
    getNotes(authToken).then(data => setNotes(data.notes))
  })

  // render our notes
}

We can go further with this. Our API will error if we don't give it the correct data -- for example, if we try to log in with an incorrect username or password. We can make our getAuthToken function work the same way. This will let us test out failure states in our application.

export function getAuthToken (username, password) {
  return new Promise((resolve, reject) => {
    if (username === "testuser" && password === "password") {
      resolve({
        token: 'testtoken'
      })
    } else {
      reject({
        message: 'unauthorized'
      })
    }
  })
}

We will want to add failure states to each of our API functions to be able to test all states.

Option 2: use a mock API

A mock API is a set of API endpoints that return data that looks like our eventual real API, but isn't backed by a database and doesn't persist data. There are a lot of tools to make mock APIs out there, but most of them are hosted and cost money. A free tool that runs on your local machine is Mockoon. With this tool, you can create endpoints with failure and success states. I'm not going to go through how to set up Mockoon here, but let's look at how we might use it with our facade.

Axios has the ability to create an instance with defaults, which will help us out. Here's how we might use it:

const mockAPI = 'http://localhost:3000/api'
const productionAPI = 'https://example.org/api'

const request = axios.create({
  baseURL: process.env.NODE_ENV === 'production' ? productionAPI : mockAPI
})

export function getAuthToken (username, password) {
  return request.post('/auth/token/login/', {
    username: username, password: password
  }).then(res => res.data)
}

export function getNotes (authToken) {
  return request.get('/notes/', {
    headers: { Authorization: authToken }
  }).then(res => res.data)
}

This code will look at the value of process.env.NODE_ENV, which will be set to "development" when we run it via npm start and "production" when we run npm run build, and use that to decide whether requests should go to our mock API or our production API. As long as our mock API returns data in the same shape as our production API, this should let us develop our front-end application before the API is built.

What is "this" in JavaScript?

Clinton N. Dreisbach — Fri, 26 Jun 2020 19:14:13 +0000

Here's a question I often get in class:

May we spend a little bit more time going over the fundamentals of how this works and how to identify what it’s referring to? I’d love for someone who is a bit more familiar with the concept to explain it like I’m 5.

The simplest explanation of this is that it's defined when a function is called. If the function is an attribute of an object, and that object is used when calling it, like object.coolFunction(), then this is the object. If the function is not an attribute of an object, then this is null.

Check it out:

const person = {
  name: "Amiro",
  sayHello: function () {
    console.log("Hello from " + this.name)
  }
}
person.sayHello() // => prints "Hello from Amiro"
const sayHello = person.sayHello
sayHello() // what happens here? What is "this" when we call this function?

Here's where it gets super hard: callbacks. Here's an example. Assume there's a button element stored in the variable button.

button.addEventListener('click', person.sayHello)

When the button is clicked, the function stored in person.sayHello is called, but it's important to note that it's called like a function, not like an attribute of person. So this is null when you click the button.

There's two ways to set this permanently so that it's what you want it to be at all times: the method .bind() and using arrow functions.

`.bind()`

All functions have a method .bind() that takes one argument. .bind() returns a new function that does the same thing, but it will have the variable this bound to that argument. An example:

function sayHello() {
  console.log("hello from " + this.name)
}

const sayHelloFromAmiro = sayHello.bind({name: 'Amiro'})
sayHelloFromAmiro() // => prints "hello from Amiro"

{name: 'Amiro'} was bound to this when we called .bind({name: 'Amiro'}) on sayHello.

Arrow functions

When you make a function using the () => {} syntax, known as the arrow syntax, this is bound at the time you create the function. This is really useful if you have a function on an object you want to act as an event listener.

Think back to the example of a DOM button element called button. Here it is with arrow functions:

const person = {
  name: "Amiro",
  sayHello: () => {
    console.log("Hello from " + this.name)
  }
}
person.sayHello() // => prints "Hello from Amiro"
button.addEventListener('click', person.sayHello)

This time, we'll get what we expect when we click button.