Forem: Clinton N. Dreisbach

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.

How to get your local Django DB on Heroku

Clinton N. Dreisbach — Mon, 25 Nov 2019 14:23:13 +0000

I was trying to push the data from a local Django app I was working on to Heroku without committing a DB dump to my Git repo, and kept running into problems. The command to make it work was so weird that I'm recording it for posterity:

./manage.py dumpdata | heroku run --no-tty "./manage.py loaddata --format=json -"

Make git friendlier with aliases

Clinton N. Dreisbach — Thu, 21 Nov 2019 16:32:46 +0000

Git drives me crazy with its obtuse command-line interface. Over time, I’ve added many aliases to my ~/.gitconfig in order to make its interface more clear.

Here are some of my favorites:

aliases = config --get-regexp ^alias\\.
discard = checkout --
generate-ignore = "!gi() { curl -L -s https://www.gitignore.io/api/$@ ;}; gi"
list-tracked = ls-tree -r HEAD --name-only
list-ignored = ls-files --others -i --exclude-standard
new-branch = checkout -b
push-branch = "!git push -u origin `git rev-parse --abbrev-ref HEAD`"
uncommit = reset --mixed HEAD~
unstage = reset -q HEAD --

aliases lists all my aliases. It could be formatted a bit better, but works well for me.

discard lets me discard changes to a file I'm working on. I never remember how to do this, especially as it uses the same command you use to switch branches.

generate-ignore can generate a .gitignore file for me. I use this at the start of each project.

new-branch and push-branch are huge for me. new-branch makes it explicit that I’m trying to create a new one, and push-branch pushes my local branch to a (generally new) branch of the same name on my origin repo.

uncommit and unstage are quick ways to reverse a mistake I’ve made without having to search for those arcane commands.