
Earlier today I spent the better part of a couple of hours scratching my head over a seemingly simple issue, so I thought I’d share the problem I encountered and the resolution I finally found.

When linking to a file using the `<a download>` attribute, I was having trouble getting the actual file to download. The app that I was working on has been using the `download` attribute for a few years and never had any issues.

Recently, though, when users click on the link to download the asset, the file is opened in a new tab rather than being downloaded.

After several dead-ends, I finally found [the culprit](https://www.chromestatus.com/feature/4969697975992320).

A couple of months ago, several browser vendors shipped an important security update to the `<a download>` attribute, effectively ignoring the flag when the file source is cross-origin.

Fear not… There’s hope, after all!

Setting the [Content-Disposition](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition) header to `attachment` signals the client to download the file.

In my case, the files that users download live on S3. Fortunately, AWS allows you to bulk update the the headers for all files in a given bucket or folder within a bucket. Just right click the file or folder and select `Change Metadata`.



Debugging Issues with HTML Download Attribute


In my last post, I wrote about [building offline first applications](https://jonbellah.com/articles/offline-first/). One thing I did not cover was how to detect when a user is online or offline, so that your application can respond accordingly -- such as when you need to display connectivity status to a user or check whether a user is online before performing an action in your application.

Going all the way back to IE8, JavaScript has provided access to `navigator.onLine`, which is a simple little API that returns a boolean where `true` means the user is online, `false` meaning offline. Unfortunately, though, `navigator.onLine` is considered an [unreliable API](https://html.spec.whatwg.org/dev/offline.html#browser-state). In Chrome and Safari it only determines whether a device has connection to a network, not whether or not that network can actually reach the internet. 

However, for some purposes, `navigator.onLine` may be enough to suit your needs. So let's take a quick look at how to use it.

### Basic Detection

Let's say, for example, we want to display a message to our users when they're offline. To implement our status message, we could write:

```js
function updateOnlineStatus() {
  document.getElementById('status').innerText = 'Online';
}

function updateOfflineStatus() {
  document.getElementById('status').innerText = 'Offline';
}

window.addEventListener('online',  updateOnlineStatus);
window.addEventListener('offline', updateOfflineStatus);
```

In the above code, we're just listening for the browser to fire the `online` or `offline` events and we're updating the contents of an element with an ID of status to reflect the current state.

### Better Detection

If your application needs a more reliable mechanism for detecting user connectivity, there is hope! Enter [Offline.js](http://github.hubspot.com/offline/).

Offline.js listens for a request to fail with a network-related error, then triggers a custom offline status event. From there, it begins trying to fetch your `/favicon.ico` every few seconds until it is able to succesfully retrieve that asset, at which time it will trigger the online event.

Implementing Offline.js is actually super simple. Just include the script, a theme, and one of the language files and you're all done. You also have the option of just leveraging the underlying JS API, just by excluding the theme CSS file.


### Further Reading
- [Navigator.onLine Docs (MDN)](https://developer.mozilla.org/en-US/docs/Web/API/NavigatorOnLine/onLine)
- [Offline.js](http://github.hubspot.com/offline/)
- [redux-offline-status](https://github.com/2WheelCoder/redux-offline-status)


Online and Offline Events with JavaScript


Have you ever tried reading your email while riding the subway? Checked your Twitter feed while connected to in-flight wifi? Attempted to pull up a map while wandering around in a foreign country?

If so, you're probably familiar with the problem of poor connectivity.

It took more than 25 years for the first three billion people to come online, but over the next decade that number is [expected to double](http://next3b.com/the-next-3-billion/). The vast majority of these new users will be coming online in under-developed countries, using under-powered devices, and browsing the internet over low-bandwidth connections.

It's with these people and problems in mind that developers have begun shifting towards an offline first approach for websites and applications.

### What does offline first mean?

Before we dig any deeper, I should clarify that offline first doesn't mean that users should be able to reach your site on their first visit without an internet connection. It means that when we, as developers, build applications, we should consider the experience of slow and intermittent connectivity. A user being offline [should not be treated as an error condition](https://alistapart.com/article/offline-first#section5).

For example, [HospitalRun](http://hospitalrun.io/) is an offline first application for managing hospitals in the developing world, places where intermittent connectivity is just a fact of life. It allows records to be carried to remote clinics, where there may be no internet, and then syncs those records when there is.

[Una Kravetz](https://una.im/save-offline/) has implemented a "save for offline" feature for the articles on her site. It's a very useful and thoughtful feature that I've personally taken advantage of while sitting at the airport, waiting to board a flight. I was able to save a handful of articles prior to turning on airplane mode, giving me plenty to read without having to pay for in-flight wifi.

Offline first applications are driven by two key components: [service workers](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API) and some form of client-side, offline-capable storage (such as [PouchDB](https://pouchdb.com/), [hood.ie](https://hood.ie), or [localForage](https://localforage.github.io/localForage/)).

We won't dive too much into the storage aspect of things with this post, but let's go ahead and take a look at the star of the show: service workers.

### Service Workers

A service worker is an event-driven script that browsers run in a separate thread, known as a worker context. Since service workers are run in a worker context, they can't directly access the DOM. Instead, they interact with the client through `postMessage`.

A service worker can intercept and modify navigation and resource requests, giving you complete control over how your app behaves in various situations. This is one of the most powerful features of service workers -- allowing you to cache good responses from API requests and having your worker respond with that data if the user goes offline.

*As an aside, service workers provide access to a few other features worth noting, such as channel messaging, background syncing, and push notifications -- features that will help bridge the gap between native and web apps. However, those features are out of the scope of this post.*

#### Lifecycle

As I mentioned in the last section, service workers are event-driven scripts. A service worker lifecycle contains six distinct events:

- Install
- Activate
- Fetch
- Message
- Sync
- Push

In this post, we're only going to focus on the first three event types, as they're the basic pieces necessary to set up offline first support.

Let's take a look at our `sw.js` file and break down each piece. The first thing we should do is set up our cache keys and precache routes.

```js
const PRECACHE = 'precache-v1';
const RUNTIME = 'runtime';

const PRECACHE_URLS = [
  'index.html',
  'styles.css',
  'main.js'
];
```

In the code above, we name this our precache bucket `precache-v1` and our runtime bucket `runtime`. The reason we split these into two separate caches is so that we can easily invalidate our runtime cache without dumping out our precached files and routes or vice versa.

In the `PRECACHE_URLS` constant, we define an array of files that we want to precache. In this example, we're only caching the index, stylesheet, and primary javascript file -- typically what you'd expect with a single page application. This is also a great place to preload data and assets for commonly-visited pages in your application. 

Next, let's take a look at the `install` event.

The first event a service worker runs through during it's lifecycle is `install`, which is triggered as soon as the worker executes and is only called once per service worker. The install event is where we should cache all the assets we'll need before being able to control the client.

```js
// The install handler takes care of precaching the resources we always need.
self.addEventListener('install', event => {
  event.waitUntil(
    caches.open(PRECACHE)
      .then(cache => cache.addAll(PRECACHE_URLS))
      .then(self.skipWaiting())
  );
});
```

The promise that is passed to `event.waitUntil()` tells the browser when your install completes, and whether or not it was successful. If the promise rejects, the install fails, and the browser discards the service worker.

Now let's take a look at the `activate` event.

```js
// The activate handler takes care of cleaning up old caches.
self.addEventListener('activate', event => {
  const currentCaches = [PRECACHE, RUNTIME];
  event.waitUntil(
    caches.keys().then(cacheNames => {
      return cacheNames.filter(cacheName => !currentCaches.includes(cacheName));
    }).then(cachesToDelete => {
      return Promise.all(cachesToDelete.map(cacheToDelete => {
        return caches.delete(cacheToDelete);
      }));
    }).then(() => self.clients.claim())
  );
});
```

Once the service worker is installed and ready to take control of clients, we'll get an `activate` event. Here we'll clean up any caches that may be left over from old service workers.

Finally, let's look at the `fetch` event, where the magic really starts happening. The `fetch` event acts as an intermediary between a client request and the servers response. For example:


```js
self.addEventListener('fetch', event => {
  if (event.request.url.startsWith(self.location.origin)) {
    event.respondWith(
      caches.match(event.request).then(cachedResponse => {
        if (cachedResponse) {
          return cachedResponse;
        }

        return caches.open(RUNTIME).then(cache => {
          return fetch(event.request).then(response => {
            // Put a copy of the response in the runtime cache.
            return cache.put(event.request, response.clone()).then(() => {
              return response;
            });
          });
        });
      })
    );
  }
});
```

This `fetch` handler first checks to see if the request is for the same-origin, filtering out cross-origin requests to services like Google Analytics, and serves responses from our cache. If no response is found, it populates the runtime cache with the response from the network before returning it.

There are a lot of other ways we can fine-tune our `fetch` responses; for example, we could change our handler so that it only responds to `GET` requests by checking the `event.request.method` before `event.respondWith()`. 

#### Gotchas

Service workers are still a bit raw and can be a real pain sometimes. There are definitely some _gotchas_ to be aware of when you get started.

First, service workers require you to use HTTPS. Allowing a script to run in the background on the client, asynchronously fetching data and images, opens the door to malicious exploitation by [man-in-the-middle attacks](https://www.veracode.com/security/man-middle-attack). 

Be careful with the way that you handle file naming and cache keys with service workers. You should keep the file name consistent and trigger new installs by changing the cache key in the `sw.js` file itself. [Alexander Pope](https://www.youtube.com/watch?v=CPP9ew4Co0M) has an excellent talk about what can happen if you, instead, put the cache key on the service worker file itself.

Your code should be stateless, since the worker is shut down and loses state whenever it isn't in use. JavaScript in a service worker must not block, meaning you need to use asynchronous APIs. For example, you cannot use `localStorage` in a service worker (`localStorage` is a synchronous API).

Debugging service workers can be tricky, since the console is preserved.

### Further Reading
There are tons of great resources out there to learn more about service workers and the offline-first push. Here are a few that I found particularly enlightening:

- [Offline first](https://github.com/pazguille/offline-first) - Repository listing virtually every resource you could ever need to deep dive into offline first.
- [Designing Offline-First Web Apps](https://alistapart.com/article/offline-first)
- [Service Worker, what are you?](https://medium.com/@kosamari/service-worker-what-are-you-ca0f8df92b65)
- [Service worker examples](https://github.com/GoogleChrome/samples/tree/gh-pages/service-worker) - Google has a great public repository of examples that I highly recommend taking a look at, they go a long way towards demystifying some of the trickier parts of service workers.

Building Offline First Applications



I've been spending more and more time with Jest lately and, increasingly, one of my favorite features is [snapshots](https://facebook.github.io/jest/docs/en/snapshot-testing.html#content). In the past, I've [written](https://css-tricks.com/visual-regression-testing-with-phantomcss/) and [talked](https://jonbellah.com/talks/2016/front-porch) a lot about visual regression testing, but snapshot testing is a bit of a new concept to me.

In fact, the first time I heard about snapshot testing, I thought it was just a different term for visual regression testing. It turns out, that's not the case... snapshots are totally different and totally awesome (though, I do still believe they solve some of the same problems, but we'll get to that in a bit).

### What is snapshot testing?

Snapshot testing is a form of regression testing that verifies that your UI does not change unexpectedly. A snapshot test does not test the *visual* representation of a component, but instead uses a JSON representation of a rendered component. You can think of it kind of it a little like copying markup from the browser inspector, except that snapshot tests also contain useful things like props, inline event handlers, etc.

In the simplest form, a snapshot test would look something like the following. Let's say we have just a stateless, functional component called `App` that just spits out a `div` with some text in it.

```js
// App.js
import React from 'react';

const App = () => (
	<div className="App">
		Snapshot test!
	</div>
);

export default App;
```

We could write a pretty simple snapshot test that would look like:
```js
// App.test.js
import React from 'react';
import renderer from 'react-test-renderer';
import App from './App';

test('App renders correctly', () => {
	const tree = renderer.create(
		<App />
	).toJSON();
	expect(tree).toMatchSnapshot();
});
```

Which, when run, would give us a `.snap` file that looks like:
```js
// __snapshots__/App.test.js.snap
exports[`App renders correctly 1`] = `
<div
  className="App"
>
  Snapshot test!
</div>
`;
```

There's a lot going on here, so let's break it down a little bit.

In our `App.test.js` file, on the second line we import our Jest snapshot renderer (`react-test-renderer`) so that we can use it to create our snapshots. Then we use `renderer.create` to render our component in memory, as an object named `tree`.

Finally, we use Jest's `expect()`, pass in the `tree` object that we just created, and use the [.toMatchSnapshot()](https://facebook.github.io/jest/docs/expect.html#tomatchsnapshotoptionalstring) matcher to determine whether our component matches our snapshot.

If a previous snapshot does not exist, Jest will create one (in this case, our `App.test.js.snap` file). Any subsequent Jest runs will follow the same process, but will then begin comparing the new snapshot to the original.

If a change is detected, the test will fail. Jest then asks if you'd like to update the snapshot, which we can quickly and easily do via the command line with `$ jest -u`. If the change is unexpected, you can go back, fix the component, and keep moving.

![](fail.png)

### Why use snapshot tests?

There are a couple reasons that I like using snapshot testing on projects. The first is just simplicity, with only a few lines of code I'm able to capture a snapshot of what a component looked like at a point in time when I was confident that the output was correct. As applications increase in size and complexity, I believe that finding areas where you can simplify becomes crucial.

> Classic assertion based tests are perfect for testing clearly defined behavior that is expected to remain relatively stable. Snapshot tests are great for testing less clearly defined behavior that may change often.
> <cite>[Ben McCormick](https://benmccormick.org/2016/09/19/testing-with-jest-snapshots-first-impressions/)</cite>

Secondly, I think snapshot testing helps create a broader, more complete (and, thus, healthier) testing suite. I believe that adding snapshot testing to an arsenal of unit, functional, and acceptance testing will only help build stronger software. Snapshots are not a replacement for other types of testing, they're complimentary.

### Snapshot testing workflow

Snapshot tests should be written *after* a component has been built, contrary to what some popular testing methodologies (like TDD) would recommend. That's not to say that snapshot testing can't play nicely with TDD approaches, though.

While I don't personally employ a TDD approach in my own work (the nature of agency work tends to make TDD difficult, in my experience), I like the idea of bookending development with testing, taking a TDD approach to unit and functional tests (writing the tests before the component is built). Then once the component passes the established tests, add a snapshot test to keep an eye out for regressions in the UI.

Another important piece to note is that with snapshot testing, you should always commit your snapshots to your repo. If you're working on a project with a distributed team, or even by yourself on multiple machines, it's critical that everyone use the same source of truth.

### Do snapshots replace visual regression testing?

As I mentioned before, visual regression testing is a topic that I have written a lot about, spoken about at conferences, and have generally been passionate about for years. That said, I believe that snapshot testing takes much of the pain that was inherent with VRT.

Visual tests can fail for a number of reasons that make them particularly difficult to work with; for example, sub-pixel antialiasing can render slightly differently across different machines. Or if you want to test real components, as opposed to a style guide, you need to set up dynamic content replacement so that your visual suite was always testing against a predictable UI.

All of these problems added up to make visual regression testing an unpopular choice for many long-term projects. If testing becomes unnecessarily time consuming, difficult, or generally painful, developers just won't do it.

In fact, one of the most common responses to the discussion of visual regression testing is "but I change my CSS because I want things to look different." And that's very true. The friction of constant feedback for each and every *intended* change can, frankly, be pretty annoying.

That said, I still believe that VRT still plays an extremely important role in one common scenario: refactoring. Snapshot testing just is not intended to solve the problem of actual visual changes. 

### Further Reading

All in all, I've really enjoyed digging deeper into snapshot testing and can now say I am a fan. While researching this post, I came across some solid resources that I'd recommend as further reading:

- [Jest Docs](https://facebook.github.io/jest/docs/en/snapshot-testing.html)
- [Testing with Jest Snapshots: First Impressions](https://benmccormick.org/2016/09/19/testing-with-jest-snapshots-first-impressions/)
- [Snapshot Testing React with Jest](https://www.codeproject.com/Articles/1180478/Snapshot-Testing-React-with-Jest)
- [Snapshot Testing React Components with Jest](https://medium.com/@luisvieira_gmr/snapshot-testing-react-components-with-jest-3455d73932a4)

Snapshot Testing with Jest


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. 

Debugging Issues with HTML Download Attribute

Online and Offline Events with JavaScript

Building Offline First Applications

Snapshot Testing with Jest

A Look at Async/Await in ES2017

Improved Error Handling in React 16 with Error Boundaries

Like what you've read?