Introducing react-pacomo: Automatic namespacing for className

So you’ve got a React application, and you want to style it. But no matter how hard you try, you just can’t get excited about the existing options.

Maybe you like how Inline Style eliminates globals, but don’t want to gamble on an untested technology which doesn’t play well with others. Or maybe you like the concept behind CSS Modules, but feel they are too heavyweight for your own application.

Wouldn’t it be great if you could have the ease-of-use of Inline Style with the compatibility of CSS Modules? Say, something which automatically prefixes className props with a unique namespace? Actually, react-pacomo does exactly that. Build-process free. Without any modifications to your existing components. Almost like magic.

See react-pacomo in action in the Unicorn Standard Starter Kit.

Continue reading

Why You Shouldn’t Style React Components With JavaScript

Update: I’ve announced react-pacomo, a solution for some of the problems with CSS outlined here, without the downsides of Inline Style.

So one of the hottest topics in the React world lately is Inline Style, i.e. setting styles with an element’s style property instead of CSS.

This new and shiny way of doing things promises to make your life easier. It eliminates the bugs caused by global styles, it allows you to package styles with your components, and it unifies the entire development process under the single language of JavaScript, fuck yeah. And now that all the cool kids are using it, it’s time to jump on the bandwagon too!

But don’t just take my word for it! See for yourself with this handy dandy list of all the problems which you could have fixed with plain old CSS if you hadn’t of drunk the cool-aid, and the new problems you’ll now have to deal with too.

Continue reading

Join The Dark Side Of The Flux: Responding to Actions with Actors

Have you ever wanted to respond to a change in your Redux store’s state by dispatching another action?

Now you know that this is frowned on. You know that if you have enough information to dispatch an action after the reducer does its thing, then it is a mathematical certainty that you can do what you want without dispatching another action.

But for some reason, you just don’t care. Maybe your store is structured in such a way that it is easier to send requests after an action is processed. Maybe you don’t want your actions or components to be in charge of fetching remote data for each new route. Or maybe you’re just a dark side kind of person. Whatever the reason, actors will allow you to dispatch with impunity.

Continue reading

Can I dispatch multiple actions from Redux action creators?

When using Redux, you may have come across a scenario where you’d like one action creator to dispatch multiple actions.

There are a few reasons you’d want to do this, but let’s consider the problem of handling a submit event from a form. In response, you’ll want to do multiple things. For example: RESET your form’s view model, POST your form’s data to the server, and also NAVIGATE to another route.

So should you dispatch separate actions for each of these behaviours, or instead dispatch a single action which is handled by each of the applicable reducers?

Continue reading

Choosing a JavaScript Build Tool – Babel, Browserify, Webpack, Grunt and Gulp

When starting a new JavaScript project, one of the first things you’ll do is set up a build system. But with so many options, deciding on tools often gets in the way of building the app itself.

Imagine if there was a simple rule you could follow to choose which build tools to use – wouldn’t it be great being able to just get stuck into writing your app? Actually, after spending five years writing apps with automatic build systems, I’ve come upon just such a guide. I know what to use and where to use it — and after reading this article, you will too!

Continue reading

Which Flux Implementation Should I Use With React?

So you’ve sifted through the seemingly infinite sea of JavaScript frameworks, and finally settled on React. But then you realise that React only solves half the problem, and everyone is now using Flux for the other half. But that’s ok — if Flux came from the same place as React, it should have a simple and easy-to-learn API, right?

Wrong.

Flux is like a framework for frameworks – frameworkception, as one redditor put it. There are as many implementations as there are opinions, all with their own strengths and weaknesses, and none of them with authority.

So what is a developer to do? Contribute to the malaise by rolling your own, like I did? Don’t do it! Instead, use Redux.

Wait, is it really that simple? Yes, it really is! But since you’re still reading, you’re probably not someone who is easily convinced. And that’s why I’ve prepared this comparison for you:

Continue reading

Building a Router with Raw React

So you’ve decided to build a Single Page App with React, and everything seems to be going dandy. You’ve got yourself some wireframes, a HTML file and a few components, and then you decide to add some routes. Easy, right?

Well, thats what you thought until you started reading the internet. But now you’re worrying about isomorphism and the HTML 5 history API and even how to pass props to your view components again. And if you thought learning all this was painful, imagine rewriting your application when the routing library’s API breaks in a few weeks.

Routing doesn’t have to be complicated, so why stress yourself out with libraries when a hand-rolled router can take less than 20 lines? Especially seeing that if you’d have just kept following this guide, you would have had something working in only two minutes

Continue reading

React and pushState: You’re doing it wrong

In the world of React.js single-page apps, there are two types of routing: push-state, and hash-based. Each of these have their strengths and weaknesses.

Now as you may know, most of the React ecosystem focuses on push-state routing, using the HTML5 History API and (sometimes) server-side rendering with Node.js. There are a number of reasons for this, the two main ones being:

Continue reading

Learn Raw React: Ridiculously Simple Forms

Update August 2018: A newer, more complete introduction to React’s fundamentals is available at my course “React (without the buzzwords)”. It uses the latest version of React, and covers many topics that “Learn Raw React” is missing, including component state, asynchronous data storage, JSX, structure best practices, and more.

“React (without the buzzwords)” is composed of 30 lessons, with 55 live examples and exercises. It lets you save your progress through lessons, and automatically saves your exercise answers so you can pick up where you left off.

React (without the buzzwords) is exclusive to Frontend Armory Pro members. But you can try these 8 free lessons just by clicking one of the links – no signup required:

Of course, the original “Learn Raw React” guide is still useful today! Here it is:


So – you’ve got the hang of React, and you’ve even built a little app. But after making your app look nice, you remember that you also need to make it work. And that’s when you start searching for form libraries.

First you look for tools to structure data and event flow. Then you shift focus to libraries which reduce repetition in form components. And while you’re at it, tools which validate user input would certainly help. Tools like react-forms and formsy-react and flux and redux and RxJS and as one redditor put it:

I’ve been evaluating a few frameworks out there. It’s been the bane of my existence for the past two weeks.

Wasn’t the whole idea that tools would save you time?

Why spend two weeks investigating when you could have implemented the most important part in three minutes? Its not even like you’d have to think that hard; all you have to do is follow this exercise:

Continue reading

React.js By Example: Interacting with the DOM

This article is based on the code from part 2 of my Learn Raw React series: Ridiculously Simple Forms.

Sometimes, the user’s next action is so obvious that it feels almost rude not to do it for them.

The textbook example is when a form has failed validation after “submit” was pressed, and the user needs to correct their mistake. What you’ll often find is that despite the obviousness of this, the user has to manually click on that field.

This is stupid. If the user liked clicking that much, they’d be playing Diablo.

If there is only one field with an error, and the user has to fix it, then the field should be focused for them. But how do we automatically focus fields with React?

Well, assuming we’ve got a reference to the <input> element’s DOM node, it is as simple as calling the focus() method. Ta-da! But React uses the Virtual DOM, not the real DOM! Help?

Continue reading