Re-exporting ES6 modules

Still need a little help getting ES6 compiling smoothly? First find out how.

With the advent of Babel, ES6 modules have become a real option for organising code. Mapping your require statements to import and module.exports to export is intuitive and will get you up and running, but the syntax for doing anything else can be downright unexpected.

I ran into this today while translating index.coffee from numbat-ui to ES6. index.coffee follows a fairly common pattern for libraries – instead of defining anything interesting itself, it just re-exports the classes from component modules for consumption by the app using the library. Basically, doing this:

Continue reading →

Webpack Made Simple: Building ES6 & LESS with autorefresh

Update on 2015/11/08: Now works with Babel 6.0

Just want a starter kit? Clone webpack-black-triangle for something minimal, or the Unicorn Standard Starter Kit for the works.

There’s been a huge amount of press since ES6 was finalised as ES2015 – but for all the awesome features it adds, it won’t help you much if you can’t actually use it. The problem is that while ES6 is the future, the current crop of browsers are stuck in the past. Want proof? Give Chrome an arrow function, and it’ll give you this:

Chrome being stuck in the present

Of course, there is more to the story than this. You can use ES6 in the vast majority of modern browsers, but with a catch: you’ll need a build step. And while this has been a deal-breaker for many in the past, we’ve entered an age where it doesn’t have have to be.

Continue reading →

Announcing Maxim

tl;dr – Try Maxim by cloning react-black-triangle, it’ll only take two minutes!

One recurring theme lately is that a number of people have found themselves quite attached to flux‘s core idea of unidirectional data flow, while at the same time Facebook’s implementation of it hasn’t really won people’s hearts (and neither have many of the other same-thing-but-not-the-same-thing implementations).

I too have found myself in this position. I’ve been craving something which like flux is easy-to-reason about, but like rails is elegant and has enough well-defined conventions to prevent me from spending a stupid amount of time stuck in decision paralysis.

My first attempt at fixing this was producing a simple react starter kit with a custom Flux implementation, react-black-triangle. However, one thing lead to another, and the result was Maxim.

Continue reading →

Six essential JavaScript libraries

Have you ever found yourself searching through the 153,882 packages on npm (as of the time of writing), sure that there must be something which solves your problem, but bewildered by your inability to find it? You’re not alone!

The abundance of packages in the JavaScript ecosystem can at times feel more like a curse than a blessing – all the code in the world can’t help you if you don’t know where to find it. However, the great thing about well designed libraries is that you only need a few of them to get you a long way.

With that in mind, here are six of the libraries I use to solve problems in my web and node projects. In alphabetical order:

Continue reading →

Introduction to ES6 Promises – The Four Functions You Need To Avoid Callback Hell

Update October 2018: If you need to brush up on promises and async/await, I highly recommend you look instead at my Mastering Asynchronous JavaScript course on Frontend Armory. The course contains 47 live examples and exercises, and also comes with this spiffy Promises and async/await cheatsheet.

Of course, my original promises guide is still useful today! Here it is:

Apart from being new and shiny, Promises are a great way to clean up your code, reduce dependencies on external libraries, and prepare yourself for async and await in ES7. Developers who use them swear by them, and developers who don’t just don’t know what they’re missing.

That said, promises can take a lot of work to understand. They feel completely different to the callbacks which we often use to accomplish the same thing, and there are a few surprises in their design which often cause beginners hours of debugging pain.

So why should I learn promises, again?

If the fact that promises are awesome doesn’t convince you, maybe the alternative to promises will.

Up until promises arrived, developers in JavaScript land had been using callbacks. In fact, whether you realise it or not, you’ve probably used them too! setTimeout, XMLHttpRequest, and basically all browser-based asynchronous functions are callback based.

To demonstrate the problem with callbacks, let’s do some animation, just without the HTML and CSS.

Say we want want to do the following:

Continue reading →

The three faces of JavaScript`this`

JavaScript is a language which is full of surprises: its type coercion has been the subject of comedy, and one of it’s most well known books is titled JavaScript: The good parts. But of all of it’s eccentricities, the this keyword is likely the one which causes the most day-to-day confusion.

While there are a number of articles about this, they generally take an exhaustive approach to explaining the many ways of using it. This is great for reference, but not so great if you just want to know how you should use this in your next project.

That’s why in this tutorial, I explain only the three most common senses of this, by building a simplified version of a component taken from a real project – clubroom. In particular, I explain how this is used in the code which generates unique IDs for users and chat rooms.

So without further ado, let’s get started!

Continue reading →

Are JavaScript Promises swallowing your errors?

This article has kindly been turned into a video by the folks at Webucator who do JavaScript training.

When dealing with asynchronous code, JavaScript’s ES6 promises can make your life a lot easier. No more callback pyramids, no more error handling on every second line, and no more reliance on external libraries to do things as simple as getting the result of a for loop.

But ES6 Promises can have their own pitfalls, the biggest by far being disappearing error messages. Reddit’s /u/ledp put it better than I ever could:

What the actual flying fuck? Promises swallows errors by default! Who’s idea was that?

More specifically, any exception which is thrown within a then handler, a catch handler, or within the function passed to new Promise, will be silently disposed of unless manually handled.

The problem

Let’s test your understanding. Which of the following would you expect to print an error to the console?

Continue reading →

Rendering React components to the document body

One of React’s best features is the simplicity of it’s API. A component can be as simple as a render method which returns the component’s structure – just write a simple function, and you have a useful, re-usable piece of code. There are times where this can be limiting, however. In particular, the fact that this API gives a component no control over where in the DOM it will be mounted makes popup components (like modals or menus) difficult to implement. Problems arise when a parent element has overflow set to 'hidden', for example, causing something a little like this:

Continue reading →

The importance of consistent goals

Do you stuggle to build useful habits? If so, the don’t break the chain method might be worth a try. It is as simple as setting a goal you’d like to accomplish each day, and then recording your progress. There is a trick involved, however – the type of goals you set will have a huge impact on your success. My experience over the last month has shown me that not only are the size of the goals improtant, the consistency of them is arguably even more so.

For the past month, I’ve been using don’t break the chain for Japanese reading practice. Heeding the advice of Nick Winter’s Motivation Hacker, I made a small daily goal for myself – in my case, reading one page of a Japanese history comic aimed at primary school students. It actually went pretty well for most of the month – I managed to get the first of 20 books out of the way way ahead of schedule.

However, a problem appeared at the beginning of the second book. Each book is broken into two sections – a chapter of text aimed at the teacher, and a graphic novel section for the (young) students. Thinking myself above skipping the textual sections, I made myself read through the first couple of pages on their set days. However, the difference in difficulties was extreme, and in the end the sudden change in the time it took to complete my goals proved too much. I’ve failed to do more than one consecutive day since breaking the chain.

The interesting thing is that I originally decided on that goal while reading the teacher’s section of the first book, and had no trouble reading that book’s longer passages. In fact, the easy comic-style pages which followed the long-form part actually came as a bit of a surprise – and as such the “1 page a day” goal ended up taking much less effort than I expected. I doubt I’d have had a problem continuing the harder goal of reading one teacher-page a day if I’d never had been given the easier goal of reading a comic page a day in between.

This suggests that while easy goals are important, consistent goals are even more so. My next attempt at a reading chain will be with a goal of reading 5 minutes a day, as opposed to a goal of a single page.

I’d love to hear from you if you have any other tips on getting stuff done with don’t break the chain.