Real World React Debugging

Jared Forsyth

@jaredforsyth

Confidence 😀

that you can fix the bugs you find

Serenity 😇

sleep peacefully w/ tools in place to catch bugs

Self esteem 😎

from a codebase that's clean & easy to maintain

@jaredforsyth

Fix bugs ⛏🐛

with devtools

Catch bugs 🎣🐛

with linting, types, and tests

Prevent bugs 🚫🐛

with Good Practices™

@jaredforsyth

FatigueFighter™

🎉 Minimal hassle
🔧 Some hassle
🛠 Large hassle

@jaredforsyth

Fix bugs

@jaredforsyth

As developers, we spend an aweful lof ot time simulating a computer in our heads - to predict what will happen, to understand the current state of the program so that we can safely make changes to it. This is especially true with debugging -- we know the starting parameters of the program, and we see a failure case, and then it's up to us to fill in the gaps, simulating the steps that resulted in a failure. This has always bugged me, because we have a perfectly good computer sitting in front of us, which has already done all these steps, and at any rate does the simulation faster & more accurately! Therefore, one of the primary functions of debugging tools is to shine a light into the black box -- to give you insight into the runtime state of your program, so you don't have to replicate everything in your head.

React warnings

(tip: install babel-plugin-transform-react-jsx-source)

@jaredforsyth

Shine a 🔦 into the ◼️

with React Devtools

What component is this?
How is this organized?
Where's this defined?
What's the data doing?
Why is this slow?

@jaredforsyth

Catch bugs

Just add Process™

@jaredforsyth

How do we catch bugs?

your users 🎉

@jaredforsyth

How do we catch bugs?

your users 🎉 🙃
propTypes 🎉🔧
linting 🔧🛠
type annotations 🔧🛠
testing 🛠🛠

@jaredforsyth

Is it worth it?

🙃 Our users are great 🙃

you have lots of production users that you care about
several people are touching the code
you expect to support this code for at least several months

@jaredforsyth

Prop Types 🎉

documentation that's code
tests w/ runtime warnings in dev
much more flexible than types
no runtime cost in production

@jaredforsyth

Prop Types 🎉

								            const {cursorContextPropType, keyIdPropType} = require('./prop-types');
const ExpressionKeypad = React.createClass({
    propTypes: {
        // basic propType
        currentPage: React.PropTypes.number.isRequired,
        // shared proptype definition, imported from `./prop-types.js`
        cursorContext: cursorContextPropType.isRequired,
        dynamicJumpOut: React.PropTypes.bool,
        // complex prop type, using an imported definition
        extraKeys: React.PropTypes.arrayOf(keyIdPropType),
        roundTopLeft: React.PropTypes.bool,
        roundTopRight: React.PropTypes.bool,
    },

@jaredforsyth

Lint all the things 🎉🔧🛠

with eslint

								            {
    "rules": {
        // ---------------------------------------
        // ES6 and jsx rules.
        "arrow-spacing": 2,
        "computed-property-spacing": 2,
        "constructor-super": 2,
        "no-const-assign": 2,
        "no-this-before-super": 2,
        "no-var": 2,
        "prefer-const": 2,
        "prefer-spread": 2,
        "react/forbid-prop-types": [2, { "forbid": [ "array", "object" ] }],
        "react/jsx-closing-bracket-location": [2, "line-aligned"],
        "react/jsx-curly-spacing": [2, "never"],
        "react/jsx-indent-props": 2,
        "react/jsx-no-duplicate-props": 2,
        // This triggers a ton on stuff like 'if (window.x) { x(...) }'.
        "react/jsx-no-undef": 2,
        "react/jsx-sort-prop-types": 2,
        "react/jsx-uses-react": 2,
        // (Maybe we can be more strict and not need allow-in-func?)
        "react/no-did-mount-set-state": [2, "allow-in-func"],
        "react/no-did-update-set-state": 2,
        "react/no-direct-mutation-state": 2,
        "react/prop-types": 2,
        "react/self-closing-comp": 2,
        "react/sort-comp": 2,
        // ---------------------------------------
        // ES6/jsx stuff we explicitly disable.
        // We turned this off since it was too much work for too
        // little benefit, especially for one-line props.
        "react/jsx-sort-props": 0,
        // We turned this off because it complains when you have a
        // multi-line string, which I think is going too far.
        "prefer-template": 0,
        // We've decided explicitly not to care about this.
        "arrow-parens": 0,
        "prefer-arrow-callback": 0
    },
    "ecmaFeatures": {
        "arrowFunctions": true,
        "blockBindings": true,
        "classes": true,
        "destructuring": true,
        "experimentalObjectRestSpread": true,
        "forOf": true,
        "jsx": true,
        "restParams": true,
        "spread": true,
        "templateStrings": true
    },
    "plugins": [
        "react"
    ],
    "env": {
        "node": true,
        "browser": true,
        "es6": true
    },
    "extends": "./eslintrc.shared"
}

@jaredforsyth

Linting typos 🎉

no-undef, react/jsx-no-undef 🎉
no-dupe-keys,
react/jsx-no-duplicate-props 🎉

@jaredforsyth

lint: no-undef 🎉

Catching simple mistakes

							            import React from 'react'

const NoUndef = React.createClass({
  render() {
    return <Component /> // Oops, forgot to import!
  }
})

@jaredforsyth

lint: no-duplicate-props 🎉

Catching simple mistakes

							              <SomeComponent
    height={200}
    items={theItems}
    width={500}
    profileUrl={this.props.profileUrl}
    showHeader={false}
    items={null}
    responsive={this.props.flags.responsive}
  />

@jaredforsyth

Linting PropTypes 🔧🛠

react/prop-types 🔧
react/forbid-prop-types 🛠

@jaredforsyth

Type annotations

Flow or TypeScript

@jaredforsyth

Type annotations

What bugs will they catch?

calling a fn with the wrong args
accessing a property that doesn't exist
"x is not a function"
data has the wrong "shape"

@jaredforsyth

Automated testing

@jaredforsyth

What does testing give us?

verify complex behavior
prevent regressions

@jaredforsyth

Verify complex behavior

								            const myComplexFunction = require('../lib/my-complex-function');

// better make sure we cover these edge cases
assert.equals(myComplexFunction({edge: true}), 100);
assert.equals(myComplexFunction({edge: false}), 10);
assert.equals(myComplexFunction({edge: false, corner: true}), 780);

complex logic doesn't belong in components

put it in a pure function!

@jaredforsyth

Prevent regressions

								            // we better render that signup button
assert.exists($('#signup'));
assert.isFunction($('#signup').onclick);

// ... ad nausium

How many of you have this kind of test where you work? There's no complex logic here - it's super basic rendering, but this test is just to make sure somebody doesn't accidentally break your signup button. How many have been saved by this kind of test? How many have been *slowed* by this kind of test? You see, the real problem we're trying to solve here is unintended consequences. You make a change to something this component depends on, and you don't realize it changed this component. Or you make a change to this component, but accidentally delete the submit button. Well, one way is to list out all the possible things we might care about this function. But that gets brittle fast. Another way, and I would argue a better way, is to just have a tool that alerts you to changes so that you're aware of the effects of your code. I'll explain more in a second, but first I'll talk about fixtures. We've had prop fixture data at Khan Academy for a couple years now, and they're helpful in a bunch of different ways. I initially built this fixture system to be able to see different configurations of a component at the same time, to make sure I wasn't breaking anything.

@jaredforsyth

Automated Testing

prevent regressions with less hassle

Fixtures 🛠
Jest Snapshot tests 🛠
Visual regression tests 🛠

@jaredforsyth

Fixtures 🛠

@jaredforsyth

Fixtures 🛠

@jaredforsyth

Fixtures 🛠

							            // exercise-progress-phone-ui.jsx.fixture.js
module.exports = {
    instances: [{
        "attempts": [
            {
                "correct": true,
                "seenHint": false,
                "timeDone": "2015-12-01"
            },
            {
                "correct": false,
                "seenHint": false,
                "timeDone": "2015-12-01"
            }
        ],
        "isSkillCheck": true,
        "criterion": {
            "type": "num_problems",
            "numRequired": 10
        },
        "answerStatus": "correct"
    }, ...]
}

@jaredforsyth

Jest snapshot tests 🛠

								            // signup-page-test.js
import renderer from 'react-test-renderer';
test('Signup page renders correctly', () => {
  const tree = renderer.create(
    <SignUpPage />
  ).toJSON();
  expect(tree).toMatchSnapshot();
});

⬇

                            <!-- signup-page-test.js.snap -->
<div
    className="SignUpPage"
    onClick={[Function]}
>
    <input
        placeholder="Name"
        ...
    />
    ...
    <button
        onClick={[Function]}
    >
        Sign up!
    </button>
</div>

So that was fixtures. However, the fixture testing that we do currently at KA only verifies that they don't literally throw an error in the render method. Jest snapshot tests are a way to up the game, still without requiring you to spend all your time maintaining tests. Jest snapshot tests store the HTML output of your components -- so not the higher-level components, just the div, span, etc that end up being rendered to the page. Later, after making a change, you can regenerate this "snapshot" and compare it to the previous one. That way, you can see the impact that your changes had on the component at a DOM level, to make sure that your expectations for the change line up with reality. I think there's definitely work to be done to make this a seamless process though; there are plenty of ways to set this up such that it is a pain. But the key thing is -- you don't write the expected output by hand. The tools do that for you, notify you of any differences, and ask if you want to overwrite the current snapshot, or if you want to fix your code. Visual regression tests can function in much the same way. You fire up a browser with your rendered component, take a screenshot, and compare that to the screenshot you have stored on file. An added bonus to this is that you now have a record of what all of your components look like, so that a new developer coming in can get a much better idea of what things look like & how they work.

@jaredforsyth

Jest snapshot tests 🛠

implement a feature
run jest before submitting for review

								            - expected
+ actual
  <div
      className="SignUpPage"
      onClick={[Function]}
  >
+     <div>
+       My new feature thing
+       ...
+     </div>
      <input
          placeholder="Name"
          ...
      />
      ...
-     <button
-         onClick={[Function]}
-     >
-         Sign up!
-     </button>
  </div>

⬅ yup, we added this

⬅ oops!

@jaredforsyth

Jest snapshot tests 🛠

implement a feature
run jest before submitting for review
commit new snapshot file

@jaredforsyth

Visual regression tests 🛠

compare images instead of HTML
😀 catch css bugs!
😟 can be finnicky

@jaredforsyth

Prevent Bugs

with Good Practices™

State management 🎉
Logic // presentation 🎉

@jaredforsyth

"Figuring out where state should live is one of the hard problems of UI"

- me

@jaredforsyth

State Management

One owner
Least Common Ancestor
Embrace the tree

							              handleClick() {
    this.setState({clicked: true});
  },
  render() {
    return <div style={...}>
      <button onClick={this.handleClick}>
        click me
      </button>
    </div>
  }

              ...
  handleClick() {
    this.setState({clicked: true});
    this.props.onClick();
  },
  ...

If a parent needs to know about it, the parent should own it.

@jaredforsyth

State Management

One owner
Least Common Ancestor
Embrace the tree

								              ...
  getClickedState() {
    return this.refs.child.hasBeenClicked();
  },
  ...

If a parent needs to know about it, the parent should own it.

@jaredforsyth

Decouple logic from presentation

@jaredforsyth

React Devtools to fix bugs

Linting & Tests to catch bugs

Best Practices to avoid bugs

github.com/jaredly/real-world-react-debugging

Jared Forsyth

@jaredforsyth

FIN

@jaredforsyth