Using WebRTC and React to build a basic chat server

February 8, 2016 – 8:00 pm Tags: , ,

In this article, we’re going to look at how to use WebRTC to relay chat messages between browsers in a React application. Last time we learned how to store and handle data in a React app. If you’ve just looking to learn about React and WebRTC, you should be able to follow this without reading the previous entries in the series.

Now at the fourth article in the series, we’re ready to start Connecting People (look at that funny Nokia reference). We’re going to use WebRTC to set up a direct connection between different chat participants, no backend required – well, we do need a little bit of backend for the initial connection handling… but it’ll all make sense soon!

Read the rest of this entry »

React application data-flow: Where and how to store your data?

February 1, 2016 – 5:15 pm Tags: ,

This is the third article in the series where we build a Slack-style chat app with React.

Last time we set up NPM and Browserify for our project. With the tooling set up, we can focus on building our application’s features again.

The first feature I want to add is of course having multiple chat participants. But our code is currently a bit messy. We have messages and other data all over the place – this is going to make it difficult to add the new feature (and test it later).

Let’s fix the problem: In this article, we’re going to look at some best practices on how data should be modeled in a React app. Typically, this is when we would start talking about Flux, Redux and all that, but in this case we won’t. Instead, we’re going to start by implementing a light-weight data store mechanism and use that instead. I’ll tell you why in a moment.

Read the rest of this entry »

Learn to unit test your javaScript code with Mocha and Chai

January 29, 2016 – 5:17 pm Tags: ,

Have you ever made some changes to your code, and later found it caused something else to break?

I’m sure most of us have. This is almost inevitable, especially when you have a larger amount of code. One thing depends on another, and then changing it breaks something else as a result.

But what if that didn’t happen? What if you had a way of knowing when something breaks as a result of some change? That would be pretty great. You could modify your code without having to worry about breaking anything, you’d have fewer bugs and you’d spend less time debugging.

That’s where unit tests shine. They will automatically detect any problems in the code for you. Make a change, run your tests and if anything breaks, you’ll immediately know what happened, where the problem is and what the correct behavior should be. This completely eliminates any guesswork!

In this article, I’ll show you how to get started unit testing your JavaScript code. The examples and techniques shown in this article can be applied to both browser-based code and Node.js code.

Read the rest of this entry

Getting started with npm and Browserify in a React project

January 25, 2016 – 2:47 pm Tags: ,

This is the second article in a series where we build a Slack-style chat app with React.

So far, in the previous article, we’ve built a simple prototype. We want to start adding features to it – such as actually supporting multiple people chatting – but before we do that, let’s set up some tools.

npm and Browserify are useful tools which will make our lives easier in the long run as our app starts becoming more complex.

So, in this article, we’ll move our previous code to use npm and Browserify.

Read the rest of this entry »

Learning React basics and building a basic application prototype

January 17, 2016 – 3:04 pm Tags: ,

This is the first part in a series of articles, where we’ll be using React to build a Slack-style chat application.

In this article, we’ll start by building a basic prototype. We’ll start by learning about React components and JSX. While doing that, we’ll also look at the basics of building React applications.

Read the rest of this entry »

Getting started with React the easy way

January 10, 2016 – 6:39 pm Tags: ,

There’s a lot of talk lately about how it’s hard to get started with JavaScript libraries like React. You need ES6, you need Babel, you need this, you need that. If all you want is to try a library, there’s tons of technobabble getting in your way, sometimes involving so many steps it’s easier to just go and do something else instead.

But that should not be the case. Most libraries – React included – don’t require anything fancy to get started. In fact, it’s better to start with a simple setup. You can always add the fancy extras to it later when you need them.

Let me show you the easiest way of getting started with React. Spoiler: it only requires two script tags on an HTML page.

Read the rest of this entry »

Top 5 articles of 2015

January 3, 2016 – 1:37 am

With one year gone again, here’s the top 5 content from 2015!

In 2015 the site’s traffic more than doubled from 2014, from about 133 000 visitors to 300 782 in 2015.

Can I double the traffic again this year and help 600 000 developers? Hope so, I certainly intend to keep on writing great content for you in the coming year as well.

Looking to up your JavaScript skills in 2016? Join more than 1 000 developers who receive the exclusive content from my newsletter




We will never sell your information or spam you, ever.

Why is fixing bugs so slow? (and how to make it faster)

December 16, 2015 – 8:35 am Tags:

Have you ever wondered why sometimes fixing bugs seems to take much longer than it should? When you finally find the problem, it turns out all you need is one small change. Yet, it took a lot of time to find what’s going on. This happens to me more often than I’d like.

On the other hand, when you’re writing code and you go and test it and it doesn’t work correctly, fixing the bug is really quick. You jump back into your editor, whip up a line of code and the problem is solved.

Why is it that sometimes fixing bugs takes a lot of work even when the problem is simple, and other times, it’s really quick to fix the problem – maybe even when it isn’t so trivial? Is there something we can learn from the bugs that are easy to fix, so that we could spend less time fixing bugs in general?

Let’s talk about that, and see what ways there are that we can use to solve this problem and stop pulling our hair out because of hard to find bugs.

Read the rest of this entry »

Sinon.js best practices for spies, stubs and mocks

December 7, 2015 – 1:57 am Tags: , ,

Sinon is one of the most important tools for testing, as without it writing tests for more complex pieces of code such as Ajax, networking, databases, etc. would become difficult.

In this article, I’ll show you the best practices for using Sinon, so you’ll be able to apply it to your own projects more easily.

  • What are the differences between spies, stubs and mocks?
  • When and how to use each of them for best results
  • Common pitfalls and how to avoid problems

Read the rest of this article

AngularJS: Setting up parallel / sticky states with ui-router and ui-router-extras

November 8, 2015 – 4:05 pm Tags: ,

The application I’m developing at work has many independent parts, which needed their own states. Think of a UI similar to Photoshop, WebStorm, or such – Every panel in the UI is self-contained and can be changed without affecting the others.

The standard ui-router has no concept of parallel states. Everything must be modeled as a tree, which means a setup like this doesn’t work. For example, changing one panel’s state would affect everything else too.

Thankfully there’s ui-router-extras, which adds support for so-called “sticky states” or “parallel states”. We can use this to have as many individual parts, that have their own parallel state trees, as we want.

Let’s go through a small sample app and look how to set this up step by step.

Read the rest of this entry

Big thanks to ui-router-extras author Chris Thielen for helping with this.