
Writing asynchronous code in JavaScript has traditionally been a pretty messy endeavor. It usually meant writing callbacks on top of callbacks, handling errors multiple levels deep, resulting in the infamous [pyramid of doom](https://en.wikipedia.org/wiki/Pyramid_of_doom_(programming)).

```js
fs.readdir(source, function (err, files) {
  if (err) {
    console.log('Error finding files: ' + err)
  } else {
    files.forEach(function (filename, fileIndex) {
      console.log(filename)
      gm(source + filename).size(function (err, values) {
        if (err) {
          console.log('Error identifying file size: ' + err)
        } else {
          console.log(filename + ' : ' + values)
          aspect = (values.width / values.height)
          widths.forEach(function (width, widthIndex) ]
            height = Math.round(width / aspect)
            console.log('resizing ' + filename + 'to ' + height + 'x' + height)
            this.resize(width, height).write(dest + 'w' + width + '_' + filename, function(err) {
              if (err) console.log('Error writing file: ' + err)
            })
          }.bind(this))
        }
      })
    })
  }
})
```

Ew, right? This is a sample from [callbackhell.com](http://callbackhell.com) that I think is a pretty excellent example of exactly what async functions aim to save us from.

### Overview

Async functions, a major feature in the ES2017 spec, are effectively a combination of two big ES6 features: Promises and generator functions. 

When an async function is called, it returns a Promise. If you're not familiar with Promises, Axel Rauschmayer has an excellent primer on [2ality](http://2ality.com/2014/09/es6-promises-foundations.html). In short, though, a Promise is an object that represents the eventual success or failure value of an asynchronous operation.

On the other hand, we have generator functions. Generators are functions that can be exited and later re-entered, with context stored across re-entrances. In the context of async functions, generators give us the ability to pause a function, wait for an asynchronous operation to finish, then jump back in and continue execution.

In broad terms, you can think of async functions a lot like regular Promises. When you resolve a Promise, you use the `.then()` callback to continue execution. With async functions, `await` behaves a lot like `.then()`, in that it will pause the execution of your function until that Promise has been resolved.

### Cool, so how can I use async functions?

Let's start with a basic example that may look a little familiar:
```js
async function fetchJson(url) {
    try {
        const request = await fetch(url);
        const text = await request.text();
        return JSON.parse(text);
    }
    catch (error) {
        console.log(`ERROR: ${error.stack}`);
    }
}

// Can be called with:
fetchJson('https://example.com/file.json')
.then(obj => console.log(obj));
```
Here we're using an async function to fetch some JSON from a file, parse that file, and return the contents. We use await to pause while fetch goes and gets the file, then again on the next line while the `request.text()` Promise is resolved.

In async functions, errors are handled with `try...catch` blocks. In the sample above, if our Promise is rejected we just log the error to the console.

It's important to note that if your async function does not declare a `catch`, errors will be swallowed, meaning they will be silently disposed of unless explicitly handled.

`youtube:https://www.youtube.com/embed/WvJ9fK1dqlI`

### Stuff worth noting

Async functions are started synchronously, but settled asynchronously. Meaning, they're fired off in execution order, but the Promise is resolved and returned asynchronously. 

As you can see in the example above, an async function is not limited to a single `await`; you can `await` the resolution of multiple asynchronous operations within the same function. Each `await` declaration will wait for the previous value to resolve before performing its own operation.

One big *gotcha* with async functions is that you cannot to use `await` within a [nested function](http://calculist.org/blog/2011/12/14/why-coroutines-wont-work-on-the-web/). For example, if you have a callback within your async function that includes `await`, that `await` will not be respected. 

Another interesting thing to note is that in async functions, the returned Promises are not wrapped; meaning if you return a non-Promise value then that value fulfills the Promise `p`, and if you do return a Promise, then that `p` now mirrors the state of the Promise.

```js
async function asyncFunc() {
    return Promise.resolve('abc');
}
asyncFunc()
.then(x => console.log(x)) // abc
```

If your returned Promise is rejected, then your async function will also be rejected.

```js
async function asyncFunc() {
    return Promise.reject(new Error('Oh no!'));
}
asyncFunc()
.catch(err => console.error(err)); // Error: Oh no!
```

### Start writing better async code today!

Pretty cool, right? Ready for the good news? Most browsers already have native [support](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function#Browser_compatibility) for async functions... for those that don't, Babel has a [polyfill](https://babeljs.io/docs/plugins/transform-async-to-generator/).

### Further Reading

I came across a lot of helpful resources on async functions while researching this article. Here are a few of my favorites:
* [Async/await proposal](https://tc39.github.io/ecmascript-asyncawait/)
* [ExploringJS](http://exploringjs.com/es2016-es2017/ch_async-functions.html)
* [Understand Promises before you start using async/await](https://medium.com/@bluepnume/learn-about-promises-before-you-start-using-async-await-eb148164a9c8)
* [Simplifying Asynchronous Coding with Async Functions](https://www.sitepoint.com/simplifying-asynchronous-coding-async-functions/)


A Look at Async/Await in ES2017


React 16 has entered the [beta](https://github.com/facebook/react/issues/10294) phase and with it comes with two of my favorite additions in a long time: returning arrays with the `render()` method and official support for error boundaries.

If you've worked with React in the past, you've probably encountered cryptic error messages that had nothing to do with your code.

There are a few scenarios that can cause React to throw cryptic errors: your application code is swallowing errors (say, through unhandled Promise rejections or faulty `try...catch`), your component returns an error instead of an actual React component, etc.

> Error boundaries are React components that catch JavaScript errors anywhere in their child component tree, log those errors, and display a fallback UI instead of the component tree that crashed.
> <cite>[React Docs](https://facebook.github.io/react/blog/2017/07/26/error-handling-in-react-16.html)</cite>

We first got a glimpse of error boundaries with React in version 15, with the `unstable_handleError()` method. It was an undocumented and, as the method name implies, unstable API; meaning there was no real guarantee that it would work.

After lots of [work and discussion](https://github.com/facebook/react/issues/2461), the React team has officially introduced the `componentDidCatch()` method, which works like a `catch {}` block, except that it's built for React components. 

`youtube:https://www.youtube.com/embed/5olfAXkDVnU`

### Using error boundaries

A class component becomes an error boundary when it defines the `componentDidCatch` lifecycle method. 

Creating a standard `ErrorBoundary` component looks like this:

```js
import React, { Component } from 'react';

class ErrorBoundary extends Component {
  constructor(props) {
    super(props);
    this.state = {
      hasError: false
    };
  }

  componentDidCatch(error, info) {
    this.setState({ hasError: true });
    // You can also log the error to an error reporting service
    logErrorToMyService(error, info);
  }

  render() {
    if (this.state.hasError) {
      return <h1>Uh oh! Something went wrong.</h1>;
    }
    return this.props.children;
  }
}
```

There are a couple of things worth pointing out in the above sample. 

First, in `componentDidCatch`, you'll notice the pseudo-method `logErrorToMyService()`. If you're using a third-party error tracking service, like Rollbar or Raygun, this is an excellent place to log those errors.

Second, our `render()` method is a pretty straightforward passthrough. If the `hasError` state is false, we return `this.props.children`, which would be everything between our `<ErrorBoundary></ErrorBoundary>` wrapper.

If the `hasError` state is true, we just return an error message.

To implement an error boundary, all you need to do is wrap your component with the newly created `ErrorBoundary` component like so:

```js
<ErrorBoundary>
  <MyComponent />
</ErrorBoundary>
```

### Placing error boundaries

As mentioned before, error boundaries will catch errors anywhere in it's child component tree (but not within itself). As such, you don't have to use the `ErrorBoundary` component just at the root of your application.

It's a good idea to *have* an error boundary at the root of your application, but by placing error boundaries in strategic locations throughout your application, you can more easily isolate the problematic child component trees.

For example, each major feature can have an error boundary to itself. Dan Abramov mentioned in the [official React blog](https://facebook.github.io/react/blog/2017/07/26/error-handling-in-react-16.html) post that Facebook Messenger uses four different error boundaries, one for each of it's major components. 

One important thing to note is that after upgrading to React 16, **errors not caught within any error boundaries will result in unmounting the entire React component tree**; so it's important to at least have, if nothing else, an error boundary at the root as a catch-all.

All in all, I think this is a super exciting new feature and one that I've been hoping for for a long time. 

Improved Error Handling in React 16 with Error Boundaries


Automated testing is something that I've always found particularly interesting. In fact, it's a topic that I've even done a few [talks](https://jonbellah.com/speaking/) and written a few [articles](https://css-tricks.com/visual-regression-testing-with-phantomcss/) on in the past.

React testing (and JS testing, in general) is an incredibly broad topic with a lot of nuance. So, in this post, I'd primarily like to focus on exploring some of the basic "what's" and "why's" of testing React applications with Jest, then finish off with a few best practices.

While this post is an introduction, it does assume that you have some familiarity with React and general testing procedures.

### Why Jest?

If you happen to have tried Jest in the past, particularly prior to version 15, you may have been turned off by the fact that it auto-mocked modules by default (meaning Jest automatically stubbed out functionality with mock data); or that it was rather slow once a test suite reached a decent size.

Fortunately, thanks to a ton of hard work from hundreds of contributors, that's no longer the case.

There are a few reasons that I think Jest is an excellent choice for your test framework:
- **Simple configuration** - it works out-of-the-box for React projects
- **It's fast** - Jest parallelizes tests across workers, spinning up workers asynchronously to read the filesystem and executing them synchronously
- **Snapshots** - even though we don't cover them in this post, I'm a big fan of snapshots. I think snapshots solve a lot of the problems that were virtually unsolveable with visual regression testing (such as false positives from things like sub-pixel differences between machines, OS's, and browsers)

### Jest with Enzyme

[Enzyme](http://airbnb.io/enzyme/) is a JavaScript testing utility built by the team at Airbnb. It's specifically built for React, relying on React TestUtils under-the-hood, but is not specific to Jest; in fact, it also works with other test frameworks like Mocha, Tape, and Karma.

Enzyme isn't a requirement for working with Jest, but without it we would be using the built-in React TestUtils, which include super memorable methods like `scryRenderDOMComponentsWithClass()` and `findRenderedDOMComponentWithClass()`.

Enzyme allows us to test our components in a few different ways, using `mount()`, `shallow()`, and `render()`.

The two most important, in my opinion, are the `mount()` method, which renders our React components in memory using [jsdom](https://github.com/tmpvar/jsdom), or the `shallow()` method, which allows you to render components "one level deep".

Enzyme and Jest allow us to do things like simulate clicks or other DOM interactions, test Redux actions, inspect the props that our React components receive, and a host of other useful things.

### Shallow Rendering

At present, the React core team [recommends using shallow rendering](https://discuss.reactjs.org/t/whats-the-prefered-way-to-test-react-js-components/26/2) to test components. Shallow rendering is a pretty inexpensive process and allows you to isolate components and their immediate children, in order to test each component on its own.

> Tests are executable documentation. What we've started doing is moving tests and the results to the documentation, so you can verify the examples you show in documentation are exactly the code that runs.
> <cite>[Max Stoiber](https://www.youtube.com/watch?v=59Ndb3YkLKA)</cite>

So let's take a look at a basic example of shallow rendering:

```js
import { shallow } from 'enzyme';

describe('<SampleComponent />', () => {
  it('should render three <Foo /> components', () => {
    const wrapper = shallow(<SampleComponent />);
    expect(wrapper.find(Foo)).to.have.length(3);
  });

  it('should render a `#nav-toggle`', () => {
    const wrapper = shallow(<SampleComponent />);
    expect(wrapper.find('#nav-toggle')).to.have.length(1);
  });
});
```

One thing worth noting is that since shallow rendering is such an inexpensive process, there's no real need to render our wrapper in the upper scope of the suite and pass it down to each assertion. Instead, we can just throw away the component after each assertion so we fully isolate each test case.

### Testing DOM Interactions

To test DOM interactions, I would recommend using a library like [sinon](http://sinonjs.org/) to add spies to your test suite, which allow you to test whether a function was called during a particular interaction. 

```js
import { mount } from 'enzyme';
import sinon from 'sinon';
import Foo from './Foo';

describe('<Foo />', () => {
  it('calls componentDidMount', () => {
    sinon.spy(Foo.prototype, 'componentDidMount');
    const wrapper = mount(<Foo />);
    expect(Foo.prototype.componentDidMount.calledOnce).to.equal(true);
  });

  it('allows us to set props', () => {
    const wrapper = mount(<Foo bar="baz" />);
    expect(wrapper.props().bar).to.equal('baz');
    wrapper.setProps({ bar: 'foo' });
    expect(wrapper.props().bar).to.equal('foo');
  });

  it('simulates click events', () => {
    const onButtonClick = sinon.spy();
    const wrapper = mount((
      <Foo onButtonClick={onButtonClick} />
    ));
    wrapper.find('button').simulate('click');
    expect(onButtonClick.calledOnce).to.equal(true);
  });
});
```

By going this route, you can separate your functional/acceptance test from your unit test. You can first test that a function has been called, then separately test that the called function returns expected values.

Sinon can also be used to provide DOM interaction testing with shallow rendering, where you would otherwise be required to use `mount()` and simulate interactions with jsdom.

```js
import { shallow } from 'enzyme';
import sinon from 'sinon';

describe('<SampleComponent />', () => {
  it('simulates click events', () => {
    const onButtonClick = sinon.spy();
    const wrapper = shallow(<Foo onButtonClick={onButtonClick} />);
    wrapper.find('button').simulate('click');
    expect(onButtonClick.calledOnce).to.equal(true);
  });
});
```

The above two code samples come from the [Enzyme docs](https://github.com/airbnb/enzyme), which I highly recommend taking a read through.

### Summary

Jest and Enzyme make testing React applications an absolute breeze... but we've only really scratched the surface of what they can do. We've not yet covered unit testing, snapshot testing, full DOM testing, or any of a handful of other tools and methodologies that we have at our disposal.

Next time you spin up a new React project, be sure to consider Jest for your test framework.

Intro to Testing React Applications with Jest and Enzyme


Welcome to the new digs!

This past weekend, I finally decided it was time to refresh things around here. Despite the fact that I still felt the old design *looked* pretty good, I didn't feel that the underlying technology and overall feel were particularly reflective of how I (or, increasingly, anyone) build sites these days.

I figured I would take an opportunity to walk you through the various updates and decisions that were made during the process.

### The Platform

On the old site, I was using a pretty basic WordPress theme that I'd built from scratch. I took a good bit of care to ensure it was lightweight and performant, achieving sub-500ms render times over a cable connection, but that was really the only remarkable thing about it.

Over the past year or so, I've spent a significant amount of time working with React and have really come to love the experience of building sites with it. So, when it came time for this redesign, I knew where I wanted to start.

I thought briefly about building a WordPress theme that was powered by React and the WP REST API, but decided that I would rather manage a blog about code like I would manage any other code.

After a bit of research, I came across [GatsbyJS](https://www.gatsbyjs.org/), a static site generator for React.

Spoiler alert: It's awesome.

For the last few days, I've been tinkering and building out this site, while learning more and more about Gatsby. I have been really impressed by so many of the features: it has a simple plugin to generate an RSS feed, it handles server rendering out-of-the-box, routing is an absolute breeze, etc.

The thing that probably impressed me the most, though, was the fact that the only thing I needed to do to make the site fully compatible with Google's [Progressive Web App Checklist](https://developers.google.com/web/progressive-web-apps/checklist) was add a `manifest.json` file.

### The Migration

Gatsby actually provides a [plugin](https://www.gatsbyjs.org/packages/gatsby-source-wordpress/) that enables basic support for using WordPress as a data source. Ultimately, though, I decided that I would rather start writing posts in markdown and storing them in my repo, making it easier to track changes and to allow others to collaborate and comment on the things that I write.

Fortunately, my history of infrequent writing paid off for once. I used this [HTML to Markdown](https://domchristie.github.io/to-markdown/) converter to take old posts, convert them to markdown, and do a bit of cleanup. It was a super manual process (and totally not scalable), but I didn't have that many posts to bring over. 

I did make a bit of a controversial decision during this process and only brought over a relatively small subsection of posts. There were a number of posts that I felt were either outdated, irrelevant, or no longer reflected my opinions about code. I'll be working to update many of the posts that I did bring over to be more complete and correct inaccuracies. 

### The Hosting

Based on recommendations found in various places during my time researching Gatsby, I decided to take a look at [Netlify](https://netlify.com). 

I went back and forth between `gh-pages` and Netlify, but decided to go with Netlify primarily due to the fact that I needed to handle redirects for the aforementioned retired posts and didn't want to manage that with React routing. 

Thus far, I've been rather pleased and impressed with the service. Setting up the new site was super easy (authenticate the GitHub repo and go). Netlify handles pretty much all of the deployment configuration for you and uses git hooks to detect updates on your chosen branch.

On the free tier, I'm still provided SSL (by way of Let's Encrypt), a CDN, automated deploys, and a few other handy features.

### The Code

As a final note, I have decided to open source the code that powers [this site](https://github.com/jonbellah/jonbellah.com). Please feel free to poke around the codebase or fork it for your own use.

If you have any questions, comments, or want to share what you've done with your fork, I'd love to hear from you in the Issues section on GitHub!

Introducing a Fresh New Look


I had the privilege of attending [jsDay](https://2017.jsday.it/) last week in Verona, Italy. One of my favorite talks during the two-day event was titled "CS101 Intro to Computational Complexity: The Sorting Problem" by [Claudia Hernández](https://twitter.com/koste4).

When calling `Array.prototype.sort()`, I (as I suspect many of you) had no idea exactly what the magicians under-the-hood were doing with my array. All I knew was that if I didn't pass proper instructions to the method, I didn't always get back the results I was expecting.

The crux of the talk revolved around the various different sorting algorithms that each of the major browser vendors use (MergeSort, QuickSort, and InsertionSort) for the native `.sort()` method and how each of those algorithms perform under various different conditions (sorting an array of 10 items, 100 items, etc. up to 10 million items).

I highly recommend taking a look through [the slides](https://speakerdeck.com/claudiahdz/cs101-intro-to-computational-complexity-the-sorting-problem). I'll be sure to update this post if/when a video of the talk becomes available.

JavaScript Sorting Algorithms


Lately I've found myself working with an ever increasing number of WordPress multisite installations, each built with a slightly different approach than the others. As a result, I've spent a lot of time thinking about how to architect these networks to maximize code clarity and maintainability.

Before going much further, I should point out that in my particular use cases, the individual sites on each of the networks generally share common designs, templates, general features, etc.

There are, however, minor customizations to each site - an additional widget here, additional templates there, and so on and so forth. If you've worked with WordPress in the past, you may be familiar with `add_theme_support();` it's used to register support for things like post thumbnails, title tags, custom headers, etc.

You may not be familiar with `current_theme_supports()`, though. `current_theme_supports()`, in conjunction with `add_theme_support()` and `remove_theme_supports()`, make up the Theme Features API and provide developers with an excellent API that, in practice, allows us to bundle features in a modular way that can easily be enabled or disabled programmatically, on a site-by-site basis.

> **Theme Features** is a set of specific functionality that may be enabled by theme authors. Themes must register each individual Theme Feature that the author wishes to support.<cite>[WordPress Codex](https://codex.wordpress.org/Theme_Features)</cite>

The approach that I've come to favor uses the Theme Features API to break a codebase into three distinct pieces: a feature plugin, a theme, and child themes.

### The Plugin

The feature plugin should be enabled network-wide, whether as an `mu-plugin` or just enabled from the network panel in the WordPress admin. All primary pieces of functionality should be placed in the plugin. Let's say, for example, that we have a custom popular posts widget that we want to enable. In our feature plugin, we can write all our code in a file called `popular-posts`. Then conditionally load that file like so:

```php
if ( current_theme_supports( 'my-plugin', 'popular-posts' ) ) {
    require_once( esc_url( plugins_url( 'includes/modules/popular-posts/popular-posts.php', __FILE__ ) ) );
}
```

### The Parent Theme

In most of my own use cases, the sites on the network shared some sort of common design elements. In these cases, it made sense for us to have a parent theme that we could use as a starting point for each site, then extend and customize as needed.

If the sites on your multisite network do not have these commonalities, you can skip the parent theme. If the sites on your multisite network _do_ share similarities, then leveraging a parent theme makes a lot of sense. Another great thing about leveraging a parent theme is that when you need to customize it for a particular site, you can write your own hooks with `apply_filters()` or `do_action()` and then extend those customizations in your child theme. That way each site on the network can display the same piece of functionality in many different ways.

Let's say, for example, that on **Site A** you label the popular posts feature "Popular Posts", but on **Site B** you label it "Most Popular". In places where you're outputting the title of your popular posts widget, you can use:

```php
echo apply_filters( 'popular_posts_title', esc_html__( 'Popular Posts', 'textdomain' ) );
```

With this architecture, I've also found it useful to leverage the WordPress Customizer for things like logos, color settings, etc. and providing default values for each setting. This makes it especially easy as a new developer on a project to spin up an environment without requiring an exact copy of the production database, as basic settings and features will be enabled and configured programmatically.

### The Child Themes

Finally, having an individual child theme for each site on the network provides you a place to put all of your site-level customizations. The primary function for us will be to enable selected features from our feature plugin. In our `functions.php` file, that would look something like:

```php
function theme_supports() {
    add_theme_support( 'my-plugin', array(
        'popular-posts',
         'my-other-feature'
     ) );
}
 add_action( 'after_setup_theme', 'theme_supports' );
```

### Final Thoughts

If you've ever ramped up on a new WordPress multisite project, you probably understand how difficult it can be to discern where all of the code you're working on is being used, particularly if features are being enabled as standalone plugins; so often test cases get missed and bugs get shipped.

By enabling and disabling features programmatically, we can more easily determine which sites on a network are utilizing a particular feature. I believe this architecture provides a clean code structure and clear separation of concerns, making future maintenance a much less daunting task.

Now, when needing to do maintenance on a feature in six months, it will be easy to discern which sites a particular feature is enabled on just by searching the project directory - as opposed having to hunt through each site to see if the feature plugin is enabled.

Writing on software design, entrepreneurship, and whatever else is on my mind.

A Look at Async/Await in ES2017

Improved Error Handling in React 16 with Error Boundaries

Intro to Testing React Applications with Jest and Enzyme

Introducing a Fresh New Look

JavaScript Sorting Algorithms

WordPress Multisite Architecture with the Theme Features API