The Haiku Of React Routing Principles

This is the third article in a series on junctions.js. You can read this without reading the others first. But for your convenience, here is part one and part two.

Junctions.js is a router that is based on principles. These principles ensure that Junctions works with React instead of fighting against it. They’re the reason that junctions.js lets you write idiomatic React components instead of some routing-specific dialect of React. And as it happens, they form a haiku:

Components compose

Browsers show “Back” and “Forward”

Get outta’ the way!

But haiku gimmicks aside, each of these principles can make a huge difference to how you route your application. So let’s have a look at each in turn.

Continue reading →

Why I created junctions.js

TL;DR? Junctions is a new, composable alternative to react-router. Get it at the junctions.js website!

It was pretty normal day in Tokyo when I received a request from a client. “I’d like this application screen to be a React Component. And I want it to be reusable.”

Given my client’s app was created with React, I naturally said “Yes Sir”. I mean, the best part about React is that components are reusable. What could go wrong?

Continue reading →

Do I Even Need A Routing Library?

So you’ve decided to build a React app. It has a few screens, so you need a router. And react-router seems pretty popular, so you npm install it and put together a quick demo. Everything seems fine and dandy!

Or it did, until you googled for some docs the next day. Something seems off. The logo has changed colour from blue to red. And the version number has mysteriously increased from 2 to 4. Huh?

Well at least it didn’t jump to 5. But this makes you think — do I really even need a routing library? Imagine if we lived in a world without JavaScript fatigue where the APIs never change and we could just focus on making awesome stuff. But actually – we kind of do! The browser APIs rarely change. And how much longer could it take to just use them instead of some complicated library?

Continue reading →

The 5 Types Of React Application State

I don’t know about you, but when I started writing React apps, I struggled to decide where my state should go. No matter how I re-arranged setState calls, things never felt quite right.

"Messy state"

And maybe that is why I got so excited when I found Redux. Redux gave me a single place to put all my state. Which sounded great in theory.

"What if"

But then I realised that having one spot to put things doesn’t necessarily make them easy to get to.

"Still messy"

It turns out that I needed more than just a place to put things. I also need a system for putting them in the right place.

"Banzai!"

For me, that system came from splitting my state into five categories. It turned the problem of deciding “how does this piece of state relate to all the other state”, into the problem of deciding “what type of state is this”. And as it turns out, this is a whole lot easier.

Continue reading →

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 →