Debuggable React Native Code: Part 1
In this series I’ll be taking you through methods of writing React Native code that can be debugged (i.e. breakpointed and stepped through) in the Chrome Debugger.
It’s actually pretty easy to end up writing undebuggable React Native code if you’re not careful, which can really hurt both your productivity and the quality of your code.
Culprit #1: Callback methods as arrow functions
For some reason, the ES6 language designers thought it unnecessary to have class methods bound to this, unlike every other language in the world*.
(* that I can think of right now. Oh, except Lua)
This means in practice, any class methods used as callbacks may or may not have this bound to the current instance of your React Component. So if you forget, and try to access this.props.myProp or this.state.myState you’ll get an exception. Very confusing for newbies!
Personally, despite the arguments, I think this was a major language design flaw when it comes to real-world use of ES6 classes, particularly as the new class syntax now looks so similar to other languages that behave as expected.
In any case, the implication is that every time we need a method that may be used as a callback (e.g. onTap or onClose), we have to bind this to it manually. Various methods exist for this and for various reasons I chose the Arrow Method Callback scheme for our developers here at Calvium:
class Bar extends Component() { onFoobar = event => {
//.. do something
}}
After taking over on a project while one of our developers was on holiday, I discovered that Chrome breakpoints for every component were completely broken. As a result trying to trace through the code to see why bugs were happening was really tricky.
With some detective work it turned out that is was in fact my recommendation that was the problem! Any React component containing Arrow Method Callbacks were broken, those without callbacks were fine.
This animation demonstrates the problem:
The reason for this is due to the way the sourcemaps (files mapping line babel-complied code to line numbers of original source code) are generated — i.e. wrongly for this code construct.
As a result we’ve now switched to defining the callbacks in the constructor with the following pattern:
constructor(props) {
super(props);
this.onCallback = () => {
console.log('onCallback');
};
}
With this simple change, a 80% non-debuggable codebase suddenly got a whole lot better!
Next up, export statements..
