Tuesday, November 10, 2015

Test friendly JavaScript modules - without Dependency Injection

A while ago, I was trying to figure out how to use test driven development with ES2015 (also known as ES6 at the time). It turned out to be a nice experience, and I wrote a blog post about it: Can I test it?

However, I had some concerns about the import feature and how to deal with module dependencies. I wrote a blog post about that too: Is the ES6 import feature an anti pattern?

Recently, I have been learning Python and was surprised by the similarities with JavaScript - in coding style, philosophy and language features. I guess Python has been a source of inspiration for the new ES2015 stuff. I have quickly become a fan of Python and I think it is a very nice language.

 At first, as a Python newbie, I stumbled upon the same questions on how to unit test modules containing a bunch of import statements. Luckily, at work I am surrounded with great programmers in general, that also are experts in the Python language. With Python, the answer to my questions was both simple and obvious. Python is a dynamic language: load the dependency in the unit test, then just override it. The code under test will use the already loaded in memory module. Simple, huh? It seems to me that there is no need for c#/java like dependency injections. I guess it was my typed language mindset that had guided me to IoC and DI patterns.

What about JavaScript?
I think it is (almost) as simple! Modules and imports in JavaScript are similar to (but not exactly like) the Python way. In JavaScript, I guess it also depends on the module loader used in the current environment. I have experimented with this. My setup contain ES2015 modules and unit tests, that are transpiled with Babel to RequireJS modules, runs in a browser or with PhantomJS. With this setup, I have managed to override module dependencies with fakes from a unit test. The module under test will actually run the fake dependency, and there is no need for custom Dependency Injection.

An example: a unit test
import foo from 'modules/foo';
import bar from 'modules/bar';

const fakeMessage = 'a fake message.';

const original = bar.getMessage;
const fake = () => fakeMessage;

QUnit.module('my example tests', {
    beforeEach() {
        bar.getMessage = fake;
    },
    afterEach() {
        bar.getMessage = original;
    }
});

QUnit.test('can an imported module be mocked?', assert => {
assert.equal(foo.message(), fakeMessage);
});

And the actual code under test:
import bar from 'modules/bar';

let foo = {
    message() {
        return bar.getMessage();
    }
};


export default foo;

I would appreciate your feedback on this!

You will find unit tests, code, settings, project structure and setup at my GitHub page:
https://github.com/DavidVujic/blog/tree/master/es2015-testable-modules

Monday, July 27, 2015

Coding in the dark: ES2015 and TypeScript on an iPad

Coding in the dark
Summertime, and the Swedish weather is ... not great, but good enough! I have spent some of the vacation days here at the countryside of beautiful Värmland, Sweden, without writing any code at all. But ideas have popped up and I want to try them out. So, now I code when everybody is sleeping. The "Dark Theme" of the editor dim the bright screen light - and hopefully won't wake up the family in the middle of the night.

Direct link: Here's some example code I have written that will get you up and running with ES2015 and/or TypeScript on your iPad.




Offline coding
I really want to write code on my iPad mini, instead of using the laptop (that I also have with me, of course). With low bandwidth - sometimes no connection at all - remoting to & write code on a Cloud based VM is not an option here in the wilderness. Local and offline is better. The Coda for iOS app supports local offline files and the latest version has some really nice features. But why code on an iPad? Well ... why not! And it's convenient too, experimenting with code snippets is just a smart device away from being realized. The solutions I present here are of course useful for countryside coding on a laptop too.

ES2015 on the iPad
I decided to give ES2015 coding a try. Does it work, using an iPad and the app only? Yes, the built in web browser and file system of Coda for iOS makes it possible. When I figured out how to transpile and run the scripts in the web browser (by using Babel and the es6-module-loader library), I got carried away and thought it would be cool to also write TypeScript on the iPad. It turns out to be just as easy as the ES2015 setup.





TypeScript on the iPad
I found a nice library on GitHub by Basarat Ali Syed, that makes it possible to transpile TypeScript files to JavaScript in a web browser: basarat/typescript-script 

Here's some example code I have written that will get you up and running with ES2015 and/or TypeScript on your iPad.




Command line experimenting with the JavaScript Playground
One of the new features of the Coda app is a command line based JavaScript playground. Scripts can easily be loaded into it and the transpiler functions can be executed from the command line. I think it is a useful alternative to the web browser, and very helpful when I want to see the actual output from a transpilation.

Happy iPad coding!

Monday, May 25, 2015

Building a bank with EPiServer?

Can it be done?

Yes. And this blog post is about how it can be done. I want to share my thoughts and experiences about writing EPiServer sites, connected to third party services and/or external APIs, with code examples and design suggestions.

 

Should it be done?

Yeah, why not? Long answer: if you already have a nice and smooth communication between product owners and developers - a daily constant flow of feature and content production releases - you probably wouldn't need a Content Management System (CMS) at all. But if you release code a couple of times a month, maybe even longer in between the releases (like most companies out there), a CMS is great to have in place. EPiServer is a good choice for that. Let's build a bank with it!

Actually, I have built one already. Well, no. Not really. But I wrote an example project with some of the building blocks I think an EPiServer site connected to external back end systems should have. 


Here's the code (at Github)
 



I know, I know ... it's a very simplistic example. I wanted to get rid of all the noise, and focus on the "core" stuff that I think is important. I think most of the features in the example code are ready for you to use today, a few things are for demo purposes only (like the implementation of the logger interface). 
 

NoScript First

The example code is an EPiServer MVC site: one page instance with a form that is posted to a controller on the server. The server code is sending the data to an external web service and the service returns user data to be displayed in the user interface. 

Let's zoom in to the form and the posting. All user input should be sanitized and validated. The data sent should be restricted to http POST, along with an anti forgery token. Use the built in model binding and data annotations for the validation of data.





I would recommend you to start developing with JavaScript disabled in the browser. That is a development style I like to call NoScript First. I think it will help you to focus on the security and the basic flow. When you are done with the basics, enable JavaScript and write client side code for a better user experience. You can hijack the form submit action and post the data with ajax, instead of a full page reload.

Here's some more info (with code examples) about NoScript First:
You might not need JavaScript

 

The basics with Dependency Injection

Try keep the controllers as light weight as possible. Extract methods to specialized helper files and inject all dependencies by using a tool like StructureMap. For testability, use c# interfaces instead of concrete classes when injecting the dependencies.

There are trade offs: your source code may seem complex at first look, especially for developers not used to these kind of patterns and abstractions. By hiding the implementations behind APIs (interfaces), you can switch between different implementations, even in runtime. But why would anyone want to do that? I'll will answer that shortly.

 

Isn't unit testing dead?

Dependency injection will simplify testing. A unit test can focus on a specific part of the source code, by providing it with fake implementations of the dependencies and control the data that is passed between them. But why unit test stuff at all? For me, test driven development is a style. A tool, helping me to write code that is specialized, minimalistic and (hopefully) readable. For me, the actual testing is secondary. That's why I think some parts of the source code can be just fine without unit tests. It is alright! However, be strict with unit testing your validation features, like the custom data annotations in the example code. Write unit tests until you are sure that your validation methods does the right thing. Try different scenarios, not only the happy path. Be evil. If you wake up in the middle of the night, because you had dreamed about ways to bypass the validation, write a unit test that prove it. Solve the issue and run the tests again.

To get the dependency injection stuff in place in your controllers, start with a simple unit test "newing up" a controller, develop and refactor the code from there. I think unit tests eventually will help you find the flow, especially when it's done test driven style.

If your controllers handles EPiServer content, such as traversing an EPiServer page tree to create menus or lists, I recommend using FakeMaker - a tool that simplifies unit testing for scenarios like that.

 

Something between the web and the services: Providers

A third party web service or a back end API is probably developed for general purpose, to be used by many different channels. A web site is specialized and customized. The data passed from a service will most likely not fit perfectly with the view of a web user interface. To create a nice user experience, the data probably has to be rearranged in some way (formatted, combined, simplified, renamed). Do that in a separate class library.

Map the data objects from the service to local domain objects that are customized for your user interface. Map the service class properties you need to a local domain object. Let AutoMapper handle the mapping, it's a great tool. Also, make sure you unit test the mappings! Included in AutoMapper, there is a unit testing feature called "AssertConfigurationValid". It has saved my life many times.

Let the library take care of the connection to the service, and keep the user interface unaware of the service API. The library should have only the features needed by the web user interface, no more than that.


I would call a library like that a Provider. Consume the providers by injecting them into the web project code (as described earlier with Dependency Injection). The web communicates with the API (the interface) of a Provider, that means that controllers also are unaware of the actual provider implementation (the concrete class). In the example code, the mappings between interfaces and concrete classes is handled by the StructureMap configuration.

With providers, you can switch service implementations without the need to alter the code in the web project. The same goes for the providers themselves. One provider implementation can be switched to an other one. But why would anyone want to do that? Okay, maybe it's time to give some answers.

 

Fake it!

During development, the back end services may also be developed in parallel and could go offline from time to time. Being dependent on an unstable external service is risky. To be able to write code, browse and test the features of a site, using fake implementations of providers returning fake data is a way out of the problem. Faking it will make it possible for the team to be "offline" and still be productive, i.e. no direct dependencies to a web service or third party system.

There are other practical uses of fake Provider implementations. The site pages that are heavily based on presenting data from back end systems (like an account transaction list) will not look any good at all when logged in as an EPiServer editor (that most likely isn't identified as an existing customer in the back end system). To create a good user experience for editors (and avoiding embarrassing page exceptions in edit mode) fakes can be very useful. Instead of cluttering the controllers with if-else statements all over the place, determining if the current user is an editor or not, you could use your already existing fake providers! That means fake providers actually will be used in production.

To be able to switch between fake and live providers, the injected dependencies need some modification. That is because the StructureMap configuration will run on application start, and checking the logged in user role there won't work. It has to be done per request, triggered from the controllers.

 

Be water, my friend (inject the Factories)

You probably already have noticed in the example code that some sort of factory is injected into the controller, and not the actual provider. The provider is retrieved later in the constructor, by calling a factory method. This occurs on every request. The factory method is where the if-else checking takes place. Is the current user an editor or not? The StructureMap configuration also has two implementations added - one fake, one live - for a provider interface. This makes it possible for the factory to pull the desired implementation from the dependency resolver.

Note: Today I met Jeremy D. Miller (the creator of StructureMap) at the DevSum conference here in Stockholm, and he showed me some examples on how to configure StructureMap without the need of factories. I like it a lot I will try this out (and update the GitHub code repository).


(Okay, maybe this video hasn't that much to do with injecting Factories, but I like Bruce Lee and think this video is cool)

 

What's Pippi Longstocking got to do with it?
Finally, let's talk about the fake data itself. Using this setup, the development team have the opportunity to stress test the UI every day, by providing data that goes beyond the perfect and well balanced placeholder text areas in the design templates delivered by the UX team. 


One obvious thing to test is the name of the logged in user. Here's an idea: add a fake data user with the name Pippilotta Viktualia Rullgardina Krusmynta Efraimsdotter Långstrump (that's the swedish full name of Pippi Longstocking)! How will the user info section of the site behave with a name like that? Well, maybe "Pippilotta Viktualia Långstrump" would be enough, let's not exaggerate. But be aware, in the real world, there are people out there with some really messed up names ... being prepared for it might be a good idea.

What do you think about all of this? Please share your thoughts and ideas about building a bank with EPiServer.

Here's the code (at Github)

Tuesday, May 12, 2015

EPiServer and programmer friendly analytics with _tics.js

Writing web analytics client side code should be really simple, and programmer friendly. If simple and programmer friendly, teams will have control over the production code they are maintaining, knowing what it actually does. To support that, I wrote a little JavaScript helper library called _tics.js a while ago.

The main features of _tics.js are (besides basic page tracking) advanced event tracking of form fields, buttons and links, including grabbing field values, value changes and the position of clicked links in a banner list or a menu.

What is _tics.js and why should I use it? Read about the features here.

I recently tried out some of the features of EPiServer 8 and came across the new Google Universal Analytics support. My first thought was: Can I use it with the features of _tics.js?

Yes, and here's how.

EPiServer Google Universal Analytics and _tics.js

All you have to do is provide _tics.js with a Tracking Id and the Tracking domain. With the new Google Universal support of EPiServer 8 (installed via the EPiServer NuGet feed), the values are added by an editor in the EPiServer CMS admin view. I have experimented and found a way to grab those values, and it can be done by using the Accessors class in the GoogleAnalytics.Services namespace.

var settings = EPiServer.GoogleAnalytics.Services.Accessors.GetTrackerSettings();

You can now provide the data to the client. 


Here's an example. I have used the Alloy MVC template (and perhaps written the C# model code a bit sloppy, but I leave the clean code implementation to you).


Grabbing the analytics values and storing them in the View Model.
Storing the analytics values in html hidden fields. Initializing _tics.js with data.

With the _tics.events() function, changes in individual form fields will be tracked and will make it possible to analyze user behavior.

In this example, the standard _tics.page() function is not used (i.e. basic page tracking), because it is already being done by the generated analytics code from the EPiServer Google Analytics Nuget package.

Note: Client side code from EPiServer add-ons is rendered by using the Html helper method RequiredClientResources, already used in the Alloy template:
@Html.RequiredClientResources("Header"); 


More features?

What about advanced tracking of form fields, like grabbing the actual values and/or the changes in individual fields? The _tics.js library expect form fields to have data attributes (read more about it here). But when using EPiServer XForms, all an editor can add is custom CSS and none of those fancy data attributes. Oh no!

Relax. I have written a little JavaScript "add-on", called _tics.cms.js, that solves this for you.

You will find it in the _tics.js GitHub repository (look in the folder called "add-ons"). Include it in your code and run the function _tics.cms.prepareForm().


Add the script and run _tics.cms.prepareForm() before initializing the library.

It checks for CSS class names and adds the corresponding data attributes to the element.


An example: this is what the editor writes in the CSS field if wanting to grab the value of an individual field (using the "getValue" built in function in the library). Please note that it is case sensitive: analyze-custom-getValue



And that's it.


Simple? Programmer friendly? What do you think about it? Please share your feedback!

Saturday, May 2, 2015

Updates to FakeMaker - helping you with test driven EPiServer development

I have updated the FakeMaker Nuget package with some new features that hopefully will make your days as a test driven EPiServer developer a little bit smoother.

Never heard of FakeMaker? Here's some info.

The updated Nuget package contains new convenience methods when creating fake pages in your unit tests (added the methods WithChildren, WithLanguageBranch, WithProperty and WithContentTypeId). This was developed by Kristian Gimring and I merged it to the source code at GitHub quite a while ago. However, I haven't updated in the Nuget package until now. The current version is 1.0.4.

Recently, I also recieved feedback and suggestions from rbaarda and have added the possibility to set a fake page as the actual StartPage, by using the new method AsStartPage (that will set the EPiServer built in property ContentReference.StartPage).

The dependencies to EPiServer was also outdated, and the latest version of the Nuget package have those and also the Moq library updated. If your current project is not using the (as for now) latest version of EPiServer, I would suggest you to grab the source code instead (two files only: FakeMaker and FakePage), add it to your test project and compile, instead of using the Nuget package version.

I want to thank Kristian Gimring and rbaarda for the contributions. I really appreciate it and am happy to see that the tool is used! 


What features are missing? Let me know! Please contact me by writing a comment in this post, at twitter, as a GitHub pull request or just add an issue to the GitHub project.

Saturday, March 14, 2015

ES6 & TDD: Can I test it?

(Yes you can!)

I like the style of Test Driven Development (TDD), dead or not. I have been using TDD mainly for server side code with C# and NUnit. I think the benefits of writing unit tests for client side code is obvious. Now, with ECMAScript 6 (ES6), we have cool stuff like modules, promises, iterators ... is ES6 testable?

Interested in test driven JavaScript in general? Check out From the Streets of Test Driven Development: JavaScript.


Write, transpile, test?
To use all those cool new JavaScript features today, the source code need to be transpiled to a version that browsers support. What about the unit tests (that is also written in JavaScript)?


The unit tests can (of course) be written in old school JavaScript (ES5). But I think the context switch between the two (ES5/ES6) probably would break the flow. I would like to write both the unit test and the code in ES6. How about using Babel to transpile them both?

Check out my earlier post about some tools I use (like Babel): Sublime ES6 coding - the tools and the flow

QUnit and ES6 arrow functions
I like the simplicity and the basic TDD style of QUnit. I like the words test and assert. Jasmine and Mocha are cool to, using the behavior driven style of writing, but I prefer the classic TDD approach. Maybe it's a mindset thing? 


QUnit uses a test runner, that is where the unit tests are started. The test runner is an html file and lives in a browser (or in PhantomJS). That's the old school world. Transpiled versions of unit tests and transpiled production code will run there. There are some things to think about. QUnit doesn't identify itself as a loadable module (yet). Instead, a variable is added to the global object. By default, QUnit will run when the DOM is loaded. When used with AMD, QUnit have to be paused until the unit test modules are loaded. In this example, I have transpiled ES6 code to AMD modules (RequireJS) using Babel. The test runner is loading a single file that will import all my unit tests.

You will find unit tests, code, settings, project structure and setup on GitHub: 

ES6 and TDD

Example - the script section of the test runner html file, written in old school JavaScript:

(function () {
  'use strict';

  QUnit.config.autostart = false;
 
  require(['script/transpiled/start.js'], function () {
    QUnit.load();
    QUnit.start();

  });
}());



The contents of start.js, importing all unit test modules, written in ES6:

import {} from './modules/exampletest.js';


The unit test, written in ES6:

import foo from 'modules/foo';

QUnit.module('my example tests');

QUnit.test('will this work?', assert => {
     const expected = 'hello foo';

     assert.equal(foo.message, expected);
});


The code under test, written in ES6:

let foo = {
     message: 'hello foo'
};

export default foo;
 


The require and imports of the test runner and start.js uses relative urls. That is because I use the same base url as the production code. This enables the simple kind of imports done in the unit test. The code there is written in the same way it would in the production code.

Run with Gulp 

I use Gulp to automate a lot of things: transpiling with Babel, checking for syntax errors with JSHint and running QUnit tests with PhantomJS (i.e. no browser required). All of these will execute as soon as any ES6 file is changed in my project. By doing that, I will get instant feedback without having to interupt the flow.

Give the code a try and let me know what you think about it. What aspects am I missing? What can be improved, changed, refactored?

You will find unit tests, code, settings, project structure and setup on GitHub: 
ES6 and TDD

Thursday, March 12, 2015

Sublime ES6 coding - the tools and the flow

Sublime Text 3 and JavaScript - a nice combination
A while ago, I decided to give Sublime Text a try when learning ECMAScript 6. I mostly use Visual Studio, and with Sublime It feels like I'm on a diet! As a side effect I am also learning a little bit of Node, because many packages are based on tools installed with the Node package manager (npm). 


ECMAScript 6 (ES6)
In order to get full ES6 syntax, I have installed the babel-sublime package. Enable the package by open or create a file with a .js extension, select View -> Syntax -> Open all with current extension as ... -> Babel -> JavaScript (Babel).





JSHint
I think JSHint does the job well also with checking for errors in ES6 code. I have only found one issue - grouping exports in a module - but I can live with writing separate multiple exports until it is fixed. I think ESLint also looks very promising, but for now I will keep using JSHint.

SublimeLinter-jshint


Linting ES6?
Selecting Babel as the default syntax for .js files will actually disable the JavaScript linting. The SublimeLinter settings file need syntax mappings for Babel (the selected row in the image below). Add the row and the linting will be enabled again.  




Share the Rules
Instead of adding comments to every single .js file (like the esnext option), I use settings files (named .jshintrc). Are you on a Windows machine and can't create file names starting with a dot? Save the file with the name jshintrc, and rename it from the command prompt using the "ren" command:  

ren jshintrc .jshintrc

Transpile to old school JavaScript with Babel
Using Babel from the command line is really simple and it runs fast.
This command will create JavaScript RequireJS style modules (AMD):
babel my/es6/path --modules amd --out-dir destination/path

But running a command after each code change is an interruption, a manual step that should be automated. I use Gulp to run Babel commands and watcher to track changes in files.

Keep the flow with Gulp
With Gulp running in the background, each file change will trigger lint rules validation, ES6-to-ES5 transpilation and unit tests. An example:


var gulp = require('gulp');
var newer = require('gulp-newer');
var babel = require('gulp-babel');
var qunit = require('node-qunit-phantomjs');
var jshint = require('gulp-jshint');
 

gulp.task('lint', function () {
    return gulp.src(source)
        .pipe(jshint())
        .pipe(jshint.reporter('default')) // linting passed
        .pipe(jshint.reporter('fail')); // linting failed
});


gulp.task('transpile', function () {
    return gulp.src(source)
        .pipe(newer(destination)) // is the file changed?
        .pipe(babel({modules: 'amd'})) // run babel and pass options
        .pipe(gulp.dest(destination));
});


gulp.task('qunit', function () {
    qunit('path/to/qunit/testrunner.html', { 'verbose': false });
});


Test Driven ES6 Development with QUnit
This is a separate blog post. Stay tuned!  

Update: Here it is the post: ES6 & TDD - can I test it?

Thursday, March 5, 2015

What? Wait. Really? Oh no! (a post about ES6 classes and privacy)

ECMAScript 6 is here with lots of new features, one of them is the class keyword. Yes, we can now write classes in JavaScript. You knew that already, right? Happy, pappy? 

I guess that about half of the World population currently is doing an imaginary High Five, the other half is probably planning a revolution (or will they just write a function?). Class is a controversial thing in society.

I am not that thrilled about it, but classes are here and will be used. Heavily. JavaScript classes are however a bit different from the ones written in C# or Java. How do I write a property? Are the properties I add private or public? Most of the examples I've seen in blog posts and presentations look something like this:

class myClass {
     constructor(firstName) {
          this.firstName = firstName;
     }
}


Is "firstName" a private property? Nope. It is publicly accessible - everyone can read and change it. If you have ever used function constructors, the behavior will be familiar. Everything added to an object using the this. syntax will be public.


Is it obvious that classes will work the same way? I don't think it is. I think the word class itself implies that certain functionality should be present. Especially for programmers coming from C#, Java or any other object oriented language. In JavaScript, classes also can only contain methods. Private variables cannot be added in the class body in the same way we are used to in C#. This code will throw an error:

// will this work? (No.)
class myClass {
     let _firstName = ''; // illegal syntax
}

Almost private?

To make a property almost private, you could use the new Symbol data type to generate a property name and store it in a Module together with the class. A symbol is a unique value (like a GUID) and will (most likely) prevent properties from being overwritten by code that consumes it.

An example:

// myModule.js
let first_Name = Symbol();

// How about this, will it be private? (No.)
class myClass {
     constructor(firstName) {
          this[first_Name] = firstName;
     }

     get name() {
          return this[first_Name];
     }
}

export default myClass;


This won't make the property private, because all keys of an object (including symbols) can be accessed using the Reflect object or the getOwnPropertySymbols method of the current object.


Really private?

I have searched for and found the following solution to be good enough for creating private properties in JavaScript classes: using WeakMaps (also new in ES6). This data structure will keep track of your property names and keep them private (as long as you don't export them, of course). The data in a WeakMap is linked to the source object and will also be garbage collected when the source object is removed.

// myModule.js
const first_name = new WeakMap();

class myClass {
     constructor (firstName) {
          first_name.set(this, firstName);
     }

     get name() {
          return first_name.get(this);
     }
}

export default myClass;


By adding the current instance of the class and the actual property value to a WeakMap, we have the behavior of private variables. If this class is extended (inherited), the properties cannot be accessed directly, since the WeakMap only exists in the module. You can't have it all, I guess.

Is it worth it?

I don't know. Time will tell. Personally, I think I mostly will use simple Modules and export object literals. Or why not use a plain old Immediately Invoked Function Expression (including private variables and methods) instead of complicating things with classes?


Update:
@stevenlangbroek has shared a nice alternative solution. I think looks like a hybrid between a class and an Immediately Invoked Function Expression. Check it out! Private variables in ES6 classes

Monday, February 23, 2015

Yeah, we got classes now (ES6). You happy, pappy?

Since the beginning of time, JavaScript has been the class less society. Everyone had a function there. With ECMAScript 6, classes have now been added. Ah, man.

Wait, wait, wait! I actually like it. I believe the class keyword is good thing to JavaScript, mmkay?

There is quite a few frameworks out there that already have introduced classes (or class like solutions) to the language: Dojo, Prototype, CoffeScript, TypeScript ... They all have their own way of doing it. ECMAScript introduces a common way of how to write a class, and that itself is great. How can classes be useful in JavaScript?

I think it can simplify the structure of code, we can write functionality that is only accessible within a class. But then again, we have modules now. A module can export an object and keep code private. Why use classes?

Well, I think the benefit of writing a JavaScript class is inheritance (using the extends keyword). Inheritance can of course also be accomplished by creating literal objects extending other objects, simply by adding properties and methods to it. But the functional inheritance style looks kind of awkward sometimes. Writing a class that extends another class will probably make more sense. Especially for programmers used to write code in c#, java, Ruby or any other object oriented language.

However, I don't think consuming a class the traditional way is a good idea in JavaScript. I think it is an anti-pattern. Creating instances of classes using the new keyword spread out all over the code base? Don't do it! 


In sucks in c#, it sucks doing it in JavaScript too. Dependency Injection and IoC containers solve the "newing up classes problem" in c#. How about JavaScript?

Here's a suggestion.

Create your classes in ES6 modules. Export an already created instance (if you want a singleton like functionality), or export a "make" method that returns a new instance of the class.

By doing that, the consumer doesn't have to worry about if the code within the module is a class or an object literal.

An example:

// the foo module, exported as a singleton
class foo {
     constructor() {
          // constructor code here
     }

     myMethod () {
          // method body code here
     }
}

export default new foo();


// the foo module, exporting a "make instance" method
class foo {
     constructor() {
          // constructor code here
     }

     myMethod () {
          // method body code here
     }
}

let makeFoo = () => new foo();

export default makeFoo;



Using the first example, the consumer will get a baked and ready instance of the foo class. The second example will give the consumer the ability to get different instances, by calling the make function. The actual structure (currently a class) of the module is hidden, and not a part of the API.

What do you think about this? Let me know!






" - Happy, Pappy?"





Sunday, February 22, 2015

Is the ES6 import feature an anti-pattern?

The new version of JavaScript is currently occupying my mind. I really like the ECMAScript 6 features, and the fact that we can write code using new stuff like arrow functions, scoped variables and native modules today (by using transpilers) is quite awesome.

There is especially one of the ES6 features that I've been thinking about: importing of modules. Modules will change the way we think about JavaScript for the web. Importing a module is so easy with ES6 and the syntax is very nice, readable and clean. How do I unit test such a module?


-----------
Update: I have experimented with an alternative to the examples in this blog. Have a look at it and please share your thoughts and feedback on the different approaches to unit testing modules:
Test friendly JavaScript modules - without Dependency Injection
-----------

The import statement uses a relative url to perform the module lookup. So, can I somehow configure a "base test suite url" to load fake modules that my module under test is dependent of? Would that require me to write a lot of stubs (files)? Is it even possible, without writing a custom module loader? That's the things I have had on my mind, for a couple of days now.


See, these days I mostly think about code and don't actually write code that much. How come? I am currently enjoying life as a swedish dad on paternity leave. The days with the one year old are great. We read books, build with blocks and laugh a lot. I love it.

When he is sleeping, I catch up on coding by reading blogs (mostly one of the great posts on ES6 by Dr. Axel Rauschmayer) or watching a video tutorial (I recommend the ES6 course on Pluralsight, by Scott Allen and Joe Eames). I am learning new things, slowly, but scheduled and at a steady pace.

Tonight, just when I had finished reading a Pippi Longstocking bedtime story to our four year old son (the big brother), the background process of the brain suddenly sent me a message: keep it simple. Use dependency injection. Dave, you know this already. I think the new syntax and the new ways of writing has blinded me, made me forget about concepts I normally use when writing c# or old school JavaScript (pre ES6).

How about writing modules with dependencies injected, by exposing something like an "init" function, instead of directly importing them? That would make them testable. Something like this:


// foo.js
let message = 'My name is foo';

var foo = {
    getFoo() {
        return message;
    }
};

export default foo;


// bar.js - dependent on foo.js 
let message = '';

var bar = {
    init(obj) {
        let foo = obj.getFoo();
        message = `${foo}bar, and I am foonky`;
    },
    getBar() {
        return message;
    }
};

export default bar;


//app.js
import foo from 'modules/foo';
import bar from 'modules/bar';

// inject dependencies
bar.init(foo);

console.log(bar.getBar());


 

Please let me know what you think about it!

-----------
Update: I have experimented with an alternative to the examples in this blog. Have a look at it and please share your thoughts and feedback on the different approaches to unit testing modules:
Test friendly JavaScript modules - without Dependency Injection

-----------