Hello web devs! CanJS 3.0 is out. It has a new developer-centric website and new features like:

One of the most impressive parts of a DoneJS application is Server Side Rendering (SSR). You can write your code once and it will render both on an SSR-enabled web server and in the browser. You’ve probably noticed, while building your DoneJS app, that it’s a generally seamless experience. However, you’ll eventually run into a situation where the code on the server doesn't execute the way you would expect. Let’s take a look at why that’s the case, then I’ll show you a neat little DoneJS utility that makes it easy to debug these situations when they appear.

Everyone at Bitovi works from home, so each year we all get together for a week-long company retreat in a new city. We’ve visited places such as New Orleans, Las Vegas, and Austin, so this year we held our retreat in beautiful Phoenix, Arizona!

We will focus on how a JavaScript module can be loaded, and get a gist of what all module loaders do.

If you are new to modules in JavaScript I would recommend to start with this article by Addy Osmani.

Do you use Browserify, WebPack, jspm, StealJS, or SystemJS? This article will provide a peak under the hood at the layer on top of which those libraries are implemented.

The nature of a human brain is that it cannot deal with a lot of objects at the same time (Miller’s Law). If you are going to build a large JavaScript application, you should stop, remember this limitation and start thinking in terms of modules.

Modules are a way to organize your application. Simply break your functionality into small pieces, focusing on how they will work with each other, and then assemble them together. A module could be seen as a black box with a clear, simple API. Modules commonly depend on other modules.

In today's modern browsers, there is support for not only writing and loading modules, but performing various low-level tasks around loading and executing the module. This article will explain the current standard for module loaders - their lifecycle and their hooks. A future article will show a detailed example for how to use these hooks.

Pop quiz! If you have modules written in CoffeeScript and CommonJS, is it possible to use them both within an ES6 application?

Today, we're re-releasing our old jQuery fixture library - jQuery.fixture.js - as the new and improved can-fixture. In this article, we'll cover:

Note: Come join us for a live training on Dependency Injection with StealJS on Wednesday, March 16, 2016 at 12:30 PM CST.

Writing small modules with good unit tests greatly increases the maintainability of your code. However, it can be difficult to test a module without first understanding how its dependencies work. Dependency Injection (DI) allows you to isolate your tests to exactly what you’re trying to test.

While many Dependency Injection implementations require you to use them as plumbing throughout your code, you can use Dependency Injection with the JavaScript module format you’re already using by loading your modules with StealJS. No need to modify your code -- use Dependency Injection when you want it and your existing module format to load modules everywhere else.

What is Dependency Injection?

Dependency injection is a Computer Science design principle that has been around a long time. There are lots of articles (here are a few) that go in depth on this topic, but I’ll use this simple definition:

Dependency Injection - replacing the code that will be loaded when a JavaScript module is imported.

The most useful way to use DI in JavaScript is to simplify unit testing. To better understand this, we'll go over the simple example shown in the GIF above.

Take these two modules:

• user - exports a name function that makes a call to the server and returns the current user’s name.
• navigation - exports a greeting function that uses the user.name function to display “Welcome Back, name!” if we know the user’s name or just “Welcome!” if we don’t.

In the next sections, we'll show how to unit test them, with and without using DI.

Testing Without Dependency Injection

If you want to test navigation.greeting without Dependency Injection, you need user.name to return a value. One way to do this is to intercept the request being made to the server and return a mocked AJAX response with the data needed for your test case.

With this approach, you’re testing more than just the greeting function:

In order to set this up you also have to know implementation details about the user module.

• What request is it making to the server?
• Is it using a library or framework to make the request?
• What does the server’s response look like?

If the user module changes, you might have to modify your test, even if the changes don’t affect the navigation module. Consider the following scenarios:

What happens if the server’s response changes?

What happens if the user module starts caching its data in localStorage?

The paradigm of unit testing is broken. Unit testing should be isolating and testing a single module, but in practice, this unit test is dependent on many modules that we’re not trying to test.

The tight coupling of the navigation module’s tests to the implementation of the user module leads to brittle tests and lots of frustration - if you don’t just give up on testing the module altogether.

Testing With Dependency Injection

Testing the navigation module becomes much easier when using dependency injection because you can inject a version of the user module that does exactly what you need for your navigation module’s tests:

Now if the implementation of user.name changes, it won’t affect your tests at all.

Dependency Injection with StealJS

StealJS is a client-side JavaScript module loader. A recent extension to steal, steal-clone, added the ability to do dependency injection of JavaScript modules. Here is the navigation example using steal-clone:

Navigation Module Code:

import { name } from 'models/user';

export class Navigation {
  greeting() {
    return name()
      .then(name => {
        return name ?
          `Welcome Back, ${name}!` :
          'Welcome!';
      });
  }
};

Navigation Test Code:

import QUnit from 'qunit';
import clone from 'steal-clone';

let navigation, name;

QUnit.module('navigation', {
  beforeEach(assert) {
    const done = assert.async();

    clone({
      'models/user': {
        name() {
          return Promise.resolve(name);
        }
      }
    })
    .import('navigation')
    .then(({ Navigation }) => {
      navigation = new Navigation();
      done();
    });
  }
});

QUnit.test('greeting - no name', (assert) => {
  const done = assert.async();

  name = null;

  navigation
  .greeting()
  .then(greeting => {
    QUnit.equal(greeting, 'Welcome!');
    done();
  });
});

QUnit.test('greeting - with name', (assert) => {
  const done = assert.async();

  name = 'Kevin';

  navigation
  .greeting()
  .then(greeting => {
    QUnit.equal(greeting, 'Welcome Back, Kevin!');
    done();
  });
});

You’ll notice a few things in this code:

• This example is using ES6 module syntax, but if you prefer CommonJS or AMD that is fine too; steal-clone will work with whatever syntax you choose.
• You only use Dependency Injection exactly where you want it. You’re not forced to use any libraries or frameworks in your modules.

This simple example shows how Dependency Injection can isolate your tests to exactly the module you’re testing and how simple it is to use DI with StealJS and steal-clone. If you want to start simplifying your tests and you’re already using StealJS, take a look at the docs for steal-clone and start using it today. If you’re not using StealJS, take a look at its homepage and docs to get started.