Live Reloading Browser Previews: Shotgun Episode 4

Midnight Cowboy — Brandon Bailey (CC-BY-2.0)

Shotgun is a new video screencast show that lets you ride shotgun with me while I tackle real programming challenges for real apps and libraries. The show is only available to members of EricElliottJS.com, but I’m journaling the adventures here.

Catch up:

• Episode 1
• Episode 2
• Episode 3

In this episode, it’s time to see how our component renders in a real browser.

Why Browsersync?

For a while I was enjoying hot module replacement with React thanks to the fine work of Dan Abramov, but that fell apart when pure components threw a wrench in the works.

Dan & friends are hard at work on solutions, and they’ve hacked together an alpha and now a beta of React Hot Loader 3.0 (RHL), but there are still issues to be resolved as of this writing. When it’s had some time to become stable, I’ll want to bring that tool back into the mix in addition to Browsersync.

In the meantime, Browsersync just works. It doesn’t preserve your app state when you reload, but it does reload when you save your files. There are also some great benefits with Browsersync that RHL does not provide:

1. It’s not React specific — it works regardless of your framework selection.
2. It can synchronize preview state to multiple browsers simultaneously — including external devices.

Let’s talk about that second point in more depth: It provides an external URL which lets you browse to the preview using additional devices (such as your phone and tablets). Every action you perform on any device will be reflected on all devices. Type text, click buttons, scroll on any device, and you’ll be able to see how it looks on every device at the same time.

Today’s Goals

The point of looking at the preview in the browser is to catch visual stuff we may have missed in our unit tests. It’s really easy to overlook visual glitches when you’re only working from unit tests. It’s very important to see your work in the browser, too.

As we identify issues with the actual component code, we’ll add unit tests prior to making the changes.

It’s worth noting that I do not unit test CSS. Visual design changes in a completely different way from the rest of the code. The product team may be constantly running A/B tests and fine tuning visual look and feel of the user interface, and we don’t want unit tests impeding that progress. It’s also a bit tricky to unit test visual design. Rather than worry about the exact pixel dimensions and color of our output, our unit tests will focus on the technical details.

Given some data, does the correct data get rendered? Does the button have the right classes? Do the components render the correct text? You get the idea. Let the design and QA teams worry about visual regression tests.

Your team may decide that you want to automate those, too, and that may become part of your responsibility, but chances are you’ll do that with a completely different kind of tool than unit tests (there are image-based visual regression testing tools).

Before we jump into it, let’s put together a little todo list:

1. Install Browsersync.
2. Create a new `sync` script in `package.json`.
3. Make sure everything is being styled correctly.

I’m pretty sure we haven’t thoroughly tested all the button states, and we might want to touch up the existing styles, too. In the static mockup, you can only see one state at a time. Browsersync will let us easily explore and inspect all of the states.

Getting Started

If you haven’t cloned the app yet, do that first:

git clone git@github.com:jshomes/course-player.git

Make sure your local copy is up to date, and then check out the starting point for this episode:

git fetch — all && git merge origin/master
git checkout ep4-start

I like to install Browsersync locally so that it gets installed with `npm install`:

npm install --save-dev browser-sync

Next, add the `sync` script above to your `package.json` file in the `scripts` section:

You’ll need both the `watch` script and `sync` script running at the same time. I run them in two separate terminal tabs. If your terminal doesn’t support tabs, you can run them in separate terminal windows.

npm run sync

Make a note of the external URL so you can browse to it on your mobile devices and experience how cool Browsersync really is. I highly recommend you do that. In another terminal:

npm run watch

Our watch script watches for changes and automatically rebuilds, which will trigger the Browsersync refresh.

You should be all set now to follow along and see how the changes effect things in the browser and the unit tests at the same time. Normally, I’ll run the browser and dev consoles on separate screens so I can easily see everything at once while I’m coding. Try it out with your workflow.

If you want to browse the code after the episode, you can checkout the `ep4-finished` tag.

The Shotgun video series is an exclusive benefit for members. Join now and catch up on the previous episodes:

Learn JavaScript with Eric Elliott

Eric Elliott is the author of “Programming JavaScript Applications” (O’Reilly), and “Learn JavaScript with Eric Elliott”. He has contributed to software experiences for Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC, and top recording artists including Usher, Frank Ocean, Metallica, and many more.

He spends most of his time in the San Francisco Bay Area with the most beautiful woman in the world.