Why use parenthesis on JavaScript return statements?

A while back, I received a great question from a reader:

Just a note in your Learn React By Itself tutorial. In the “Components” section, where you say:

return (
  React.createElement('li', {className: 'Contact'},
    React.createElement('h2', {className: 'Contact-name'}, this.props.name)
  )
)

It’s not clear to me why you need the parens and can’t just do return React.createElement. I tried that and it fails but I can’t see why. Isn’t typeof x === typeof (x) in JavaScript?

And while it is true that typeof x === typeof (x), the same doesn’t always hold for return. Why?

Continue reading

Lament of the keyboardist

I browsed the Truly Ergonomic
But support sounds truly lethargic

I wanted the Keyboard IO
But manufacture is too slow

I trailed the Filco Ninja
With staggered keys which may cause injure

So stuck with Kinesis Advantage
Somewhat like an unwilling hostage

As jamming shift causes excitement
And coloured keys make Colemak blighted

But faced with carpal tunnel syndrome
I’ll gladly take stockholm syndrome

State of React #2 – From Inception to Redux

Welcome back to the second instalment of State of React! In case you missed it, the first instalment demonstrated a small app without component state. And it received a bunch of interesting responses, like this one from @metapgmr:

using props as state and claiming that components are … stateless! The React Emperor has no clothes

Yes, the app was basically wearing its birthday suit. And yes, the app did contain state. But no, the state wasn’t in the props – and it wasn’t component state either.

So what was it?

Continue reading

State of React #1: A Stateless React App?

Have you ever been frustrated with the task of making loading spinners appear at the right time? Or maybe you’ve had trouble making a popup appear when and where you want it? These are both signs that your code suffers from unmanaged state — the bane of basically every web developer on the planet.

And luckily, the React ecosystem is brimming with tools to help. Redux, MobX, Flux and RxJS are just a few. And while they have a number of things in common (including for some reason the letter “x”), the one which stands out the most is that they just convert the problem of “managing” state into the problem of “structuring it”.

But if it seems that there is no way to dull the state of pain, it begs the question — instead of managing our state, why don’t we just avoid it?

Continue reading

Announcing ReactJS Tokyo

Have you ever wondered how other people write React apps? There are often multiple ways to solve the same problem, but finding the best way doesn’t have to mean implementing each of them yourself!

So what I’m trying to say is that if you don’t like learning things the hard way and you’re in Tokyo, you should totally come along to the first ever ReactJS Tokyo meetup.

All skill levels of English, 日本語 and JavaScript are welcome. Snacks and drinks will be provided. It will take place on Thursday, 28th July in Roppongi, and places are limited. So make sure to register early.

Look forward to seeing you there!

Should I use shouldComponentUpdate?

So you heard React was fast, and decided to give it a go. You grabbed a boilerplate, started working through it, and noticed shouldComponentUpdate and PureRenderMixin. Some googling reveals these are the things you use to make React fast. But wasn’t React already fast?

The answer is that React is fast… sometimes. The other times, you should use shouldComponentUpdate. But when are the other times? Wouldn’t it be so much easier if there was just a simple yes-no question which you could ask to decide whether to use shouldComponentUpdate or not? And wouldn’t you believe it, there is!

Continue reading

How I learned to stop worrying and love the JSX

So you’ve heard the commotion about React, and thought you’d take a look. And you’ve liked what you’ve seen! Or you did, until you saw this:

<div onClick={this.handleClick}>JSX butters my toast</div>

OK. You’re happy to give a new technology the benefit of the doubt. But this? Didn’t we escape PHP years ago? And what ever happened to separation of concerns?!

But I’m here to reassure you that not everything is as it seems. The above code is not JavaScript-in-HTML. If anything it actually promotes separation of concerns, especially compared to “competitor framework A”. And its best feature?

Continue reading

Universal React: You’re doing it wrong

So you’ve got the React basics down, and you’ve decided to put together an app. Given that React runs on both the server side and the client side, it seems that making a Universal (or Isomorphic) app is a no-brainer. Or it did until you’d spend hours trying to figure out how to set up Node.JS and Express, and make it distinguish between requests for JSON and HTML. And that’s if you’re lucky enough to not already have a server written in Rails or Java – at which point you’re probably considering rewriting your entire backend. But wasn’t Universal supposed to be a no-brainer?

While rendering server-side certainly has its benefits, they are by no means… universal. So the question is: should your app be Universal?

Continue reading

React with Babel Cheatsheet

One of my favourite blog posts on the internet is Steven Luscher‘s guest post on the Babel blog, React on ES6+. It manages to be both incredibly helpful and easy to understand, while being short enough that when you hit the end you’re like “wait, is that it?”.

And as it happens, one of the most frequent requests I get is for an updated version of my React cheatsheet, showing the newer React component syntax using ES6 classes and React.Component.

So what I’m trying to say is I’ve finally gotten my act together and made your React/ES6 cheatsheet. And I’ve based it on Steven Luscher’s post. I’ve even made it free; as in speech, and as in beer:

Continue reading

Should I use React.createClass, ES6 Classes or stateless functional components?

So you’ve decided to build a React component. You know what it will do, what it’s called, and where it’ll go. But when you open your editor and go to write the first line, you’re confronted with the decision between three different ways to declare it? Why three? And which one should you use?

Luckily, this decision doesn’t need to be a hindrance. In fact, with a little history and two simple rules, it’ll only take a few seconds to get on with the job of writing your component. And without further adieu, here’s the first rule:

Continue reading