There is little doubt that Docker has improved developer experience over the years but it's also easy to argue that continually rebuilding images to pull in changes takes away from developer experience. So let's look at how we can introduce hot reloading in our React and Express apps, using Docker.

Important: this is great for development but should not be used in production!

First, this will be our directory structure, where client is a React app, and server is an Express app:

|client
|--Dockerfile
|
|server
|--Dockerfile
|
|-docker-compose.yml

Next, let's install React, Express, and create our necessary docker files. Since our focus is on introducing hot reloading, we'll just use generators to create our apps:

npx create-react-app client
npx express-generator --no-view server // No need for views in this example
touch client/Dockerfile
touch server/Dockerfile
touch docker-compose.yml

We'll want to add nodemon as a dev dependency to our Express app, in order to introduce automatic reloading:

// Do this within the server directory
yarn add -D nodemon

And we'll need to update server/package.json to ensure nodemon is used to start our app:

"scripts": {
  "start": "nodemon ./bin/www" // Changed from node -> nodemon
},

As well as server/bin/www to use port 3001:

var port = normalizePort(process.env.PORT || 3001);

In order to proxy requests to the API, we'll need to add the proxy property in our client/package.json file:

{
  ...
  "proxy": "http://server:3001",
  ...
}

The value of server will resolve to the container's IP, thanks to Docker's bridge networking.

Great, now we can add content to our Dockerfile(s):

// client/Dockerfile
FROM node
WORKDIR /usr/src/client
COPY package.json .
RUN yarn install
COPY src ./src
COPY public ./public
EXPOSE 3000
CMD [ "yarn", "start" ]

// server/Dockerfile
FROM node
WORKDIR /usr/src/server
COPY package.json .
RUN yarn install
COPY . .
EXPOSE 3001
CMD [ "yarn", "start" ]

The above is a pretty standard setup for Dockerfiles; we're using a node image, setting our working directory, copying the necessary files, exposing the port, and setting the entry command.

To orchestrate building these images, we'll need to setup our docker-compose.yml file:

version: '3'
services:
  client:
    build: client
    ports:
      - "3000:3000"
    restart: always
    command: yarn start
    volumes: # This is where the magic happens!
      - ./client/src:/usr/src/client/src
      - ./client/public:/usr/src/client/public
  server:
    build: server
    ports:
      - "3001:3001"
    restart: always
    command: yarn start
    volumes: # This is where the magic happens!
      - ./server:/usr/src/server
      - /usr/src/server/node_modules/

The key part above is the volumes setting; this binds your local files into your docker container. So looking at the line ./client/src:/usr/src/client/src, we can see that all local files under src will be bound into your container's src directory. The power is that if you make a change locally, it's persisted to your container, which those files are being watched and thus it triggers the hot reload.

Alright, we should be all set! Let's give it a try by running:

docker-compose up

Once docker builds the images and kicks off the containers, you will be able to access the client application at http://localhost:3000. To confirm hot reloading is working, we can make a small change in client/src/App.js and watch the changes automatically take place in our browser. Similarly, we can add a route to our Express server and it'll be made available immediately thanks to nodemon.

It's important to note that changing files outside those bound via our volumes mount will not be reflected until the image is rebuilt. In other words, hot reloading will only care about the files defined in our volumes definition within docker-compose.yml.

That should be it! This approach makes working in docker much more streamlined and is a pattern which I often use.

The more I use TypeScript, the more I come to like it – similarly this is how I feel about React! So I started using the two of them together to get code suggestions and error highlighting before transpile, but also self-documenting components which is a huge benefit. Let's look at a small example on how to get up and running with React and TypeScript.

There are a few ways to do this – for brevity we'll use the CRA method with the optional TypeScript flag. But you can also add TypeScript to an existing React app by requiring the necessary libraries.

npx create-react-app todos-typescript --typescript

The first thing you'll notice is the .js extensions have been replaced with .tsx which is a TypeScript file type, with JSX in it (hence the "x").

In a new file src/interfaces/Todo.ts, let's create an interface to represent our todo object:

// Notice it's a .ts file!
interface Todo {
    id: number,
    title: String,
    completed: Boolean
}

export default Todo

This will make our interface reusable throughout our tiny project. Now in our App.tsx file, let's create interfaces for our Props and State:

import TodoInterface from './interfaces/Todo'

interface IProps {}

interface IState {
  todos: Array<TodoInterface> // This is the interface we created earlier!
}

Great! If you're new to TypeScript, this tells any component using the state object that the todos property is an array of objects, each containing an id, title, and completed property. How is that for self-documenting code?!

Next, we need to tell the App component that our state should adhere to this interface:

class App extends React.Component<IProps, IState> { // Small change here!
  state = {
    todos: [
      {
        id: 1,
        title: 'Walk the dog',
        completed: 'no' // Let's make this a String on purpose
      }
    ]
  }

  render() {
    return (
      <div className="App">
        ...
      </div>
    );
  }
}

Right away, we can see our IDE (if you have the correct extensions) telling us that our state doesn't adhere to our interface:

To mitigate this, just updatecompleted: 'no' to completed: false so it's a Boolean value as expected.

Next, we'll create a new Todos component to which we'll pass our state as props. But instead of just trusting we've typed it correctly, we'll create the props interface and have TypeScript watch our back!

import TodoInterface from './interfaces/Todo'

interface IProps {
    todos: Array<TodoInterface>
}

class Todos extends React.Component<IProps> { // Use the interface!
    render() {
        return this.props.todos.map(todo => {
            return (
                <div>
                    <h3>{todo.title}</h3>
                    <span>Completed: {todo.completed ? 'Yes' : 'No'}</span>
                </div>
            )
        })
    }
}

Lastly, we can start our development server to view our terribly-basic Todo app which doesn't offer any interaction options but does have self-documenting, reliable code!

And that's it! Very small example of integrating two great libraries together – hopefully you can see the benefit in using them to write applications at scale!

I love finding out about nice shortcuts which make repeatable tasks quicker which is why I'm so happy to have found this VS Code extension.

The VS Code ES7 React/Redux/React-Native/JS snippets extension is super powerful; it quickly and intuitively writes out snippets with just a taps on the keyboard. The list of options is exhaustive (in a good way!), so I'll just share the couple I'm finding most useful at the moment.

rce will create a React Component using the filename as the classname

import React, { Component } from 'react'

export class FileName extends Component {
  render() {
    return <div>$2</div>
  }
}

export default $1

rpce will create a Pure Component with PropTypes imported and scaffolded in the class.

import React, { PureComponent } from 'react'
import PropTypes from 'prop-types'

export class FileName extends PureComponent {
  static propTypes = {}

  render() {
    return <div>$2</div>
  }
}

export default FileName

And last, imd creates the destructuring import syntax of a module...something I reach for a lot.

import { destructuredModule } from 'module'

Like I said, they have a ton of methods available, but these three are usually the ones I reach for most often!

You've probably experienced it before: you want to return multiple elements in a render() method so you're forced to wrap them in a <span> or <div> element which will go unused. In comes the React.Fragment component to solve this issue – let's take a quick look at some examples!

Before

Using this syntax...

render() {
  return (
    <div>
      <h1>Todo Title</h1>
      <p>Feed the baby</p>
    </div>
  )
}

Will result in the div being added to our dom...

After

However, using the React Fragment syntax...

render() {
  return (
    <React.Fragment>
      <h1>Todo Title</h1>
      <p>Feed the baby</p>
    </React.Fragment>
  )
}

Means we have a valid component but without the unused element in the dom...

You can see how this would come in handy as your components grow with your application. And starting in v16.2.0, React took Fragments a step further with shorthand syntax:

render() {
  return (
    <> {/* So short, you might even miss it's there! */}
      <h1>Todo Title</h1>
      <p>Feed the baby</p>
    </>
  )
}

Cheers to less typing and more succinct code!

In efforts to reduce redundancy, I've been abstracting certain operations into Higher Order Functions (HOF). A HOF is a function which receives a function as an argument or returns a function. Let's look at a HOF which I often use to handle errors during Axios requests.

First, let's define an asynchronous function to get users from a URL:

let getUsers = async () => {
    let users = await axios.get('...')
    
    return users.data
}

"Wait! What about error handling?!", you say. This is where the HOF comes in. Let's define it:

const handleError = fn => {
    return (...params) => {
        return fn(...params).catch(err => console.log(`Error caught!`, err))
    }
}

As you can see, the HOF takes in a function as an argument, attaches a .catch onto it, then returns the function. Additionally, it unpacks the function's parameters using the spread syntax (...params) so you won't lose any original functionality.

Great! Now that we've set up everything, let's see it in action:

Promise.resolve(handleError(getUsers)())
    .then(result => console.log(result))

Notice the placement of the parenthesis! Make sure you don't call getUsers but instead pass it to handleError as an argument, then call handleError!

Boom! We've now got built in error handling which is super reusable and scales well. The possibilities for what you can do with err are endless - it's up to you! Big thanks to Wes Bos for helping me find the value in this approach.

Working with promises has become more comfortable since the introduction of async/await and in my opinion it makes code more readable.

By adding async to a function, it automatically wraps the function in a promise, regardless of its return value. This means async functions will always return a promise.

const greet = async (name) => {
  return `Hey, ${name}!`
}

greet('Ben').then(msg => console.log(msg)) // Hey, Ben!

Now greet above doesn't really need to run asynchronously but what if we needed to first fetch the user or perform some long-running task? Enter the await keyword!

const greet = async (id) => {
    let response = await fetch(`user-api/${id}`)
    let user = await response.json()
    
    return `Hey, ${user.name}!`
}

greet(7).then(msg => console.log(msg)) // Hey, Ben!

By introducing the await keyword, the code pauses until the promise settles and its value becomes available. No more nesting .then methods off the fetch which makes it arguably easier to follow! It should be noted that one cannot use the await keyword outside of an async function – it is a reserved keyword and will result in a syntax error.

Before and After

To help cement the concept that async/await is more readable than chaining .then methods, let's do a little comparison:

Before

const greet = (id) => {
    return fetch(`user-api/${id}`)
                .then(response => {
                    return response.json()
                })
                .then(user => {
                    return `Hey, ${user.name}!`
                })
}

console.log(greet(7)) // Hey, Ben!

After

const greet = async (id) => {
    let response = await fetch(`user-api/${id}`)
    let user = await response.json()
    
    return `Hey, ${user.name}!`
}

greet(7).then(msg => console.log(msg)) // Hey, Ben!

Not only does it reduce the code by 3 fewer lines, it also remove complexity – imagine the scenario when you need to make asynchronous calls within one of the .then callbacks! It just gets to be a nested-callback hell. I consider async/await to be a huge improvement to readability and its a practice that I use quite often.

The other day I reached for destructuring assignment when I wanted to grab just a single property from an HTTP response. This syntax makes it possible for one to unpack values/properties from arrays/objects and assign them to distinct variables. Let's look at why it's such a handy expression!

To keep it simple, we'll use the following object in all the examples:

const response = {
    status: 200,
    data: [
        {id: 1, name: 'Ben Comeau'},
        {id: 2, name: 'Jane Doe'}
    ],
    path: 'query-endpoint',
    total: 125,
    pages: {
        next: 4,
        previous: 2
    }
}

Single values

First, let's say you wanted to grab just the status off the response object. Typically one would approach it like this:

let status = response.status

Alternatively, using the destructuring assignment syntax, we can grab it like this:

let { status } = response

Multiple values

You may be wondering, "Why? Why not just use the first option?" And I think for this example you'd be right in questioning it. But what about when you'd like to grab data and total, too? We know it would usually look like this:

let status = response.status
let data = response.data
let total = response.total

Now let's see how we'd do this using destructuring assignment syntax:

let { status, data, total } = response

Awesome! Much cleaner and to me, more readable once you're familiar with the syntax. And this is just the tip of the iceberg, really. Let's check out two more cases which I often use.

Nested properties

Notice that the pages property is an object – let's use our new syntax to grab one of its values:

let { pages: { next } } = response // 4

This assigns the response.pages.next value to next – pretty handy! But what if you're trying to use this to assign the value to an existing variable? Or a class property?

Assignment without declaration

Let's grab that same response.pages.next value but instead assign it to an imaginary class' next property:

({
    pages: {
        next: this.next // Notice to where we're assigning the value!
    }
} = response )

Slightly different syntax as before, but the concept remains the same. Super helpful when dealing with existing objects or class instances.

I highly recommend reading the MDN docs for more examples of this great feature!

I love when new syntax comes along which improves readability and makes code more succinct. Now I know the spread syntax isn't new to JavaScript (released with ES6) but I do feel it is underutilized. Let's take a look at a few of my common uses for this syntax.

Better array literals

Quite often I reach for the spread syntax when dealing with arrays, especially when merging two existing arrays.

let garnishes = ['orange peel', 'Luxardo cherry']

let oldFashionedIngredients = [
    'rye', 'bitters', 'sugar cube', 'club soda', ...garnishes, 'ice'
]

This allows us to drop the concat method or slice as the above example would need.

Creating objects

I probably use the spread syntax the most when dealing with objects. Mostly when creating or cloning objects (ES2018+), but also merging objects.

let user = {
  firstName: 'Benjamin',
  lastName: 'Comeau'
}

let preferences = {
  firstName: 'Ben',
  email: true,
}

let userAndPreferences = { ...user, ...preferences }

The somewhat tricky part above is that the object on the right overrides any duplicate property values on the first object. So firstName will actually be Ben in this case.

Function parameters

Another place I use it often is when dealing with function parameters. It easily allows one to pass an unknown amount of parameters to a function without needing to reach for .apply, which cleans it up a bit.

let summation = (...values) => values.reduce((a, b) => a + b)

summation(1,2,3) // 6
summation(1,2,3,4,5) // 15

Hopefully you see how the spread syntax allows for more succinct code – it's syntax that I often use and enjoy seeing!

I use Babel, a JavaScript compiler, in order to write bleeding-edge JavaScript which runs well on a variety of targets. I have a go-to setup for Node which has a few neat features that makes code easier to read and maintain.

Core Setup

To start, I pull in the following under devDependencies in my package.json file:

"devDependencies": {
    "@babel/cli": "^7.2.3", // Make sure to pull the latest stable release
    "@babel/core": "^7.2.2", // which at the time of writing was v7.
    "@babel/node": "^7.2.2",
    "@babel/preset-env": "^7.3.1",
    ...
}

Plugins

Now that I've gotten the base setup going, I add a couple plugins which enable features with which I really like to work:

Class Properties

Adding the @babel/plugin-proposal-class-properties plugin allows me to use static class properties – syntax that I often reach for:

Adding this:

"devDependencies": {
    ...
    "@babel/plugin-proposal-class-properties": "^7.3.0",
}

Allows us to use:

export class Example {
  static getArray () {
    return [1, 2, 3]
  }
}

Module Resolver

Another plugin near-and-dear to my heart is the babel-plugin-module-resolver which allows me to alias directories for my modules – gets me out of the ../../../dot-hell mess!

Adding this:

"devDependencies": {
    ...
    "babel-plugin-module-resolver": "^3.1.3",
}

Allows us to use:

// We look at how to set up the "@" alias in the Configuration section below
import { Example } from '@/models/Example'

Configuration

Great! Now that we're all set up, we need to configure Babel. I chose to use a babel.config.js configuration file as opposed to .babelrc since it allows for comments, programmatic creation, and keeps it more succinct. For the above setup, I would use the following configuration:

module.exports = function (api) {
  api.cache(true)

  const presets = ['@babel/preset-env']
  
  const plugins = [
    [require.resolve('@babel/plugin-proposal-class-properties')],
    [require.resolve('babel-plugin-module-resolver'),
      {
        'root': ['./src'], // !! This is where we're setting the "@" alias!
        'alias': {
          '@': './src'
        }
      }
    ]
  ]

  return {
    presets,
    plugins
  }
}

As you can see, we're configuring the presets and the plugins here – both of which we export – and telling the system to cache the configuration. And notice that we've aliased @ to our src directory so just like that, we can avoid the trailing-dot hell.

Running Babel

Sweet, we're all set! Last thing I do is to create a few scripts which will actually run our code through Babel during development and before deploying.

Note: I'm using nodemon for development which is an amazing tool to monitor and reload the Node server automatically after file changes.

"scripts": {
    "start": "nodemon --exec babel-node src/index.js", // Point towards entry file
    "build": "node_modules/@babel/cli/bin/babel.js src --out-dir dist",
  }

That's a wrap! This Babel setup is pretty quick to get running and I find it very helpful when reaching for bleeding-edge JavaScript functionality.