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.
In this episode, it’s time to see how our component renders in a real browser.
For a while I was enjoying hot module replacement with React thanks to the fine work ofDan 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 Browser-Sync.
In the meantime, Browser-Sync 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 Browser-Sync that RHL does not provide:
- It’s not React specific — it works regardless of your framework selection.
- 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.
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:
- Install browser-sync
- Create a new `Sync` script in `package.json`
- Make sure everything is being styled correctly.
I’m pretty sure we haven’t thoroughly tested all the button states, and we haven’t fleshed out the button styles, yet. In the static mockup, you can only see one state at a time. Browser-Sync will let us easily explore and inspect all of the states.
If you haven’t cloned the app yet, do that first:
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 browser-sync 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 `browser-sync` 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 browser-sync 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 browser-sync 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.