Unlikenesses A Backend Developer

understanding react

4 April 2017

I'm working my way through the Survive.js React: From Apprentice to Master book and wanted to highlight a few points of confusion for me, hoping to clarify them on the way. Compared to the approaches I've been taught in other tutorials the approach here is slightly different. I'll try to pinpoint two or three areas of difference.

This is a simple one. In one of the early chapters the author export defaults a function without assigning it to a variable or constant:

export default () => (

Just a detail but it was a shortcut I hadn't encountered before. Easy enough to get accustomed to. (NB. Arrow functions were new enough to me that I was a bit confused by the use of round brackets instead of curly braces. If we don't use curly braces the arrow function implicitly returns whatever comes after the arrow. )

The next issue came from the fact that the author is, at the start at least, using functions instead of classes to define their React components. This meant that props were being passed in a way that was unfamiliar to me (though perfectly clearly documented in the official docs). See this from the same chapter:

export default ({notes}) => (

Still slightly confusing, because the above-linked official docs always have props as the function's argument - the above example is obviously a way to extract a particular prop from the props object by putting it in curly braces, but I haven't seen it documented.

When they move on to introducing state, the main App component is converted from a function to a class. I'm on more familiar territory here, but there's one or two niggles. First, where before my constructors have looked like this:

constructor() {
    super();
}

their's looked like this:

constructor(props) {
    super(props);
}

In fact, it seems that no one really knows why the docs recommend passing props to super. The book says:

We're passing props to super by convention. If you don't pass it, this.props won't get set!

But as this Stackoverflow answer says, this.props will still be available in later methods in the class even if it's not passed to super(). As the answer puts it, although the docs recommend passing props,

However, no reason is provided. We can speculate it is either because of subclassing or for future compatibility.

Second niggle in the App class. Ok, this is less a niggle than something I had to learn. In the render method of App, the notes object of the app's state is passed as a prop to the Notes component:

const {notes} = this.state;
[...]
<Notes notes={notes} />

This is an ES6 feature called destructuring. It just grabs the notes object from this.state and puts it in a notes constant.

Next one is to do with binding: the author adds an addNote method to the class. From the Wes Bos React for Beginners series I learnt that when a method wants to access this it has to be bound in the constructor like so:

this.addNote = this.addNote.bind(this);

The author doesn't have this, and his method is instantiated like this:

addNote = () => {

Now, when the author mentions binding here, he says:

It would be possible to do that at the constructor, render(), or by using a specific syntax. I'm opting for the syntax option in this book.

A quick google comes up with this article about different approaches for binding this. It looks like the approach used by the SurviveJS author is number 5, "Use Arrow Function in Class Property". As the Medium article says, this has several advantages - mainly lack of repetition and performance enhancements.

Wes Bos's tutorial says we need to make a copy of state before updating. It doesn't look like the SurviveJS tut does that:

this.setState({
  notes: this.state.notes.concat([{
    id: uuid.v4(),
    task: 'New task'
  }])
});

What I think is going on here is that since concat doesn't change an existing array, but returns a new array, this is equivalent to taking a copy of the existing array, modifying the copy, then assigning the modified copy to the state.

The files have the .jsx extension, while some other tuts I've seen use .js. This appears to be a debate that is not particularly interesting.

Ok - those are just from chapter three of the Getting Started section... More to come.