JanDudek.com

Let’s talk about front-end performance

2014-12-11T00:00:00+01:00

This is a video recording of a talk I gave at meet.js Summit in Poznań on September 27, 2014.

JavaScript object model basics

2012-11-09T00:00:00+01:00

The JavaScript object model is very often misunderstood subject among programmers. I'd like to give my own attempt at describing some important bits. You may also want to check the talk JavaScript basics that yashke gave at September DRUG drink-up.

Objects and prototypes

The idea is really simple. Every object is a dictionary that maps from string keys to values. Values can be any JavaScript values, like numbers, objects and functions. Moreover, every object has a special pointer to another object – its prototype, available via __proto__ property. When you look up object's property and it does not exist, the lookup continues to the object's __proto__, then to __proto__'s __proto__ and so on. At the end of this chain stays an object known as Object.prototype. It's __proto__ is null and the lookup terminates.

Here's an example:

> var x = {}
> x.__proto__
{}
> x.__proto__ === Object.prototype
true
> x.__proto__.__proto__
null

> x.__proto__.lorem = "ipsum"
> x.lorem
'ipsum'

I bet no-one would complain about JavaScript complexity if things were just like above. Unfortunately, the language complicates and obfuscates this simple idea.

First of all, __proto__ is non-standard property. Of course every JavaScript implementation has to store __proto__ somewhere, but only some of them expose __proto__ to the programmer. The standard ways to set prototypes are either constructor functions or Object.create. Keep in my mind the latter is not available in older browsers. We will describe the first approach.

Let's say we have a function Foo. Every function in JavaScript is an object. Every function object has a property called prototype. When you evaluate new Foo(), JavaScript executes the following:

create new, empty object: {}
set its __proto__ to Foo.prototype
execute Foo function with the newly created object available as this
return the newly created object, unless Foo returned another object (then return this another object)

Because Foo.prototype is an object, it's __proto__ already points to another object (it might be Object.prototype or something else) and this is how the __proto__ chain forms.

There are some corner cases, like what happens if Foo.prototype is not an object, but we won't dig into such details. Check the spec's section 13.2.2, if you're really interested.

What about `this`?

this is a special variable that holds a "current" object. It's most sane to think about it as another argument to every function, often passed implicitly by the language.

There are 4 ways of calling a function in JavaScript:

foo()
obj.foo() / obj["foo"]()
foo.call() / foo.apply()
new foo()

The critical difference between them is what becomes this during the function's execution.

In first case, the host object (window in browsers) becomes this. This is often confusing.
In second case, obj becomes this. This makes sense.
call() and apply() are ways to set this explicitly to any object you want. The difference between call and apply is how you pass other arguments – either as an array or not. foo.call(obj, 1, 2) is equivalent to foo.apply(obj, [1, 2]).
The last case, using new, works as described previously.

Keep `this` under your control

It's very important to understand the difference between first and second form. In JavaScript, the invocation operator () distinguishes whether it's applied to a refinement (an expression with dot or []). (11.2.3 in the spec).

> var obj = { foo: function () { return this; } }
> obj.foo()
{ foo: [Function] } /* our obj */
> var f = obj.foo; f()
{ ... } /* host object, i.e. window in browser */

This distinction often leads to mistakes, especially when passing callback functions. Imagine the following code:

var obj = {
	elem: document.getElementById("results"),
	loadData: function (callback) {
		callback();
	},
	showResults: function () {
		this.elem.innerHTML = "results";
	}
};
obj.loadData(obj.showResults);

Can you see the mistake? Of course loadData will execute callback, losing the this value, and showResults will refer to elem property on host object, not obj! Hunting bugs like this is not funny.

There are a couple of techniques for dealing with this problem. One of them is using Function.prototype.bind(), which was introduced in ECMAScript 5 (again, not available in some older browsers). Hopefully by now it's clear that Function.prototype.bind is a property bind available on all function objects (because they have __proto__ set to Function.prototype).

Back to our example:

obj.showResults = obj.showResults.bind(obj);
obj.loadData(obj.showResults);

bind returns new function, a wrapper that, once executed, will showResults.call(obj), thus making sure that this is the object we wanted.

If you're using CoffeeScript, it's a good idea to always define methods using fat arrow =>, which is compiled to binding methods during object creation. (To be more specific, CoffeScript has more than one way to compile fat arrow).

Summary

There are some crazy quirks in JavaScript, but prototypes are not among them.

Testing deferreds

2012-02-18T00:00:00+01:00

18 February 2012 - Wrocław

If you've carefully read my last post and its sample code, you may have spotted how I'm using deferreds for FacebookAdapter. While writing tests for the example, I came up with an idea, how we could test methods that return deferreds.

What are deferreds?

Do you use deferreds in your projects? It's a very good pattern for dealing with asynchronous code. The idea is that async function instead of accepting callbacks as arguments will return a "promise" object. You can bind you own callbacks to promise success/failure and they will run once promise is "resolved" or "rejected".

Here's an example:

@facebook.login().done =>
  @view.showLinksForLoggedIn()
  @view.hideLogin()

class FacebookAdapter
  login: =>
    $.Deferred (dfr) =>
      # do some Facebook async stuff here, and call dfr.resolve() when ready
    .promise()

Once dfr.resolve() is called, every function that you bound to the promise with done() will be called. Conversely, calling dfr.reject() will run callbacks bound with fail() method.

You'll find more detailed explanation in slides from my talk presented at RailsCamp 2011 and of course jQuery docs. There are many implementations of deferred pattern other than the jQuery one, like this one by medikoo (but it's seems targeted at Node.js).

Deferreds vs events

The other common pattern to structure async code is using events. They are great in many cases, like responding to user actions. However, deferreds are better when dealing with async computations or communication:

Deferred represents *one* instance of computation. You don't need to worry about your callback being run multiple times unexpectedly (like, for example, if someone called facebook.login() again and you were bound to event like facebook:loggedIn).
The callbacks will run even if you bind to already resolved promise - you don't have to care whether something is still going on or just finished.
It's very easy to run things in parallel and wait for all computations to finish - using $.when(oneDeferred, anotherOne, ...).done(doMyStuff).

Back to testing

When dealing with callback-based async code, Jasmine tests usually involve spying on the async method and running callback after the spy was called. There was even an example of this approach in samples for my previous post:

spyOn(facebook, "showWallPostDialog")
# later, when facebook.showWallPostDialog has been called
callback = facebook.showWallPostDialog.mostRecentCall.args[1]
callback()

This is hardly elegant or readable, so I thought we could do better with deferreds. What about this?

spyOn(facebook, "showWallPostDialog").andReturnDeferred()
# later, when facebook.showWallPostDialog has been called
facebook.showWallPostDialog.resolve()

It turns out to be quite easy to implement in Jasmine. When writing the last post, it was quick'n'dirty trick, but today I've put together a cleaner implementation (and I've updated FacebookAdapter mock in example for previous post). I really like Jasmine's simplicity and hackability. It's so easy to hook into the library and create all kinds of things you need.

Please keep in mind we're extending a class we dont own (jasmine.Spy), so I'd advise to be careful, especially when upgrading Jasmine or using other 3rd party extensions.

I hope you've enjoyed reading this post as much as I've enjoyed writing it! :-)

Post scriptum

Have you already bought your ticket for wroc_love.rb? It's going to be this year's best opportunity to drink beers and discuss with other hackers!

Implementing popups in do-it-yourself MVC

2012-01-29T00:00:00+01:00

29 January 2012 - Wrocław

The goal of this post is to describe how I've implemented a (not very complex) feature in one of my projects. I hope it will give you a peek into my architecture choices and show how to build a JavaScript MVC app without MVC framework.

Some ideas presented here were developed in our team while working on Gameboxed, but this post does not necessarily reflect opinions of my teammates :)

We'll use jQuery - but only in the view layer, except utilities like $.extend. We also need implementation of observer pattern (sometimes called EventEmitter) - the examples use my own, tiny Observable library, but you could just as well borrow Backbone.Events.

At the end of the post you'll find links to working example and source code.

Ok, let's begin.

What is a popup in terms of MVC? Popup is a kind of widget. Widget consists of a view and a controller. Each time we want to display a popup, we'll have a controller object of class with name ending *Popup and another one - view - with name like *PopupView. The controller can talk to the model and receive events from the view. The view should be dumb.

Who will start displaying a popup? In my understanding of MVC, this is role of the controller, often in response to an event from the view.

For example:

class MainController
  constructor: (@view) ->
    @view.bind "about:clicked", =>
      popup = new AboutPopup(new AboutPopupView)
      @view.append(popup.view)

This example looks a bit too verbose and keeps a hardcoded dependency on AboutPopup and AboutPopupView classes. If you've read my last post about factories, you might already know how I'd solve it:

class MainController
  constructor: (@view, createAboutPopup) ->
    @view.bind "about:clicked", =>
      popup = createAboutPopup()
      @view.append(popup.view)

# in application bootstrap:
createAboutPopup = -> new AboutPopup(new AboutPopupView)
mainController = new MainController(new MainView, createAboutPopup)

We want to be able to display many popups, but not simultanously, rather one after the other. They cannot overlap, becuase this is ugly and confusing. That's why we'll have a queue object, responsible for showing next popup after one is closed (which they'll indicate by triggering closed event).

class MainController
  constructor: (@view, @popupQueue, createAboutPopup, createAnotherPopup) ->
    @view.bind "about:clicked", =>
      @popupQueue.register(createAboutPopup())
      @popupQueue.register(createAnotherPopup())

Popups should be modal, which means other parts of interface have to be blocked while popup is visible. We'll achieve this using an "overlay" - semi-transparent div laid over page content. We want to have only one overlay, so its appearance will also be managed by queue. This leads us to the conclusion, that popup queue is also a kind of widget - it consists of a controller (PopupQueue) and a view (PopupQueueView).

Ok, enough philosophy, back to reality. Here's Jasmine spec for our queue:

describe "PopupQueue", ->
  beforeEach ->
    @popupQueueView = jasmine.createSpyObj("popupQueueView",
      ["showOverlay", "hideOverlay", "append", "remove"])
    @popupQueue = new PopupQueue(@popupQueueView)

  describe "when registered two popups", ->
    beforeEach ->
      mockPopupView = -> new Observable
      mockPopup = (view) -> $.extend({ view: view }, new Observable)

      @popup1View = mockPopupView()
      @popup1 = mockPopup(@popup1View)

      @popup2View = mockPopupView()
      @popup2 = mockPopup(@popup2View)

      @popupQueue.register(@popup1)
      @popupQueue.register(@popup2)

    it "should display overlay", ->
      expect(@popupQueueView.showOverlay).toHaveBeenCalled()

    it "should display only first popup view", ->
      expect(@popupQueueView.append.callCount).toEqual(1)
      expect(@popupQueueView.append.mostRecentCall.args[0]).toBe(@popup1View)

    describe "when first popup is closed", ->
      beforeEach ->
        @popup1.trigger("closed")

      it "should remove first popup view", ->
        expect(@popupQueueView.remove.callCount).toEqual(1)
        expect(@popupQueueView.remove.mostRecentCall.args[0]).toBe(@popup1View)

      it "should display second popup view", ->
        expect(@popupQueueView.append.callCount).toEqual(2)
        expect(@popupQueueView.append.mostRecentCall.args[0]).toBe(@popup2View)

      it "should not hide overlay", ->
        expect(@popupQueueView.hideOverlay).not.toHaveBeenCalled()

      describe "when second popup is closed", ->
        beforeEach ->
          @popup2.trigger("closed")

          it "should remove second popup view", ->
            expect(@popupQueueView.remove.callCount).toEqual(2)
            expect(@popupQueueView.remove.mostRecentCall.args[0]).toBe(@popup2View)

          it "should hide overlay", ->
            expect(@popupQueueView.hideOverlay).toHaveBeenCalled()

The implementation should be left as an exercise for the reader, but I'll need it later in this post, so here's the code:

class PopupQueue
  constructor: (@view) ->
    @queue = []

  register: (popup) =>
    @queue.push(popup)
    if @queue.length == 1
      @view.showOverlay()
      @processNext()

  processNext: =>
    if @queue.length > 0
      popup = @queue[0]
      popup.bind "closed", =>
        @hidePopup(popup)
        @queue.shift()
        @processNext()
      @displayPopup(popup)
    else
      @view.hideOverlay()

  displayPopup: (popup) =>
    @view.append(popup.view)

  hidePopup: (popup) =>
    @view.remove(popup.view)

And here's PopupQueueView:

class PopupQueueView
  constructor: ->
    @elem = $('<div class="popups"></div>')

  showOverlay: =>
    $('<div class="overlay"></div>').hide().appendTo(@elem).fadeIn()

  hideOverlay: =>
    @elem.find(".overlay").fadeOut(=> @elem.find(".overlay").remove())

  append: (subview) =>
    @elem.append(subview.elem)

  remove: (subview) =>
    @elem.find(subview.elem).remove()

Is it dumb? I think it is. I don't feel the need to unit-test such views. I'll click through the application anyway to see if animation looks good and CSS is OK.

Finally, we'll need the Popup and PopupView classes. They're fairly straithforward:

class AboutPopup
  constructor: (@view) ->
    $.extend(@, new Observable)
    @view.bind "close:clicked", => @trigger("closed")

class AboutPopupView
  constructor: ->
    $.extend(@, new Observable)
    @elem = $(this.getHtml())
    @elem.on "click", "a.close", (e) =>
      e.preventDefault()
      @trigger("close:clicked")

  getHtml: =>
    """
      <div class="popup about">
        <a href="#" class="close">Close</a>
      </div>
    """

The controller (AboutPopup) forwards event triggered when user clicks "Close", the queue will catch it and remove the view.

So, to sum up:

we divide popups to controllers and views
we use a queue that orchestrates their visibility

The benefits of this approach:

Popup as a controller may contain any complex logic, depend on many models etc. - anything you need. The caller doesn't know anything about it. The view may be just a message, may contain complex HTML, use localization, and so on.
It's easy to reuse popup classes with different views, e.g. one controller for class with just "close" button, but different views for different content. Popups are objects, so we can use any OO techniques to make them DRY and still maintainable.

Basically, every time we need some custom behaviour, we have a place to put it in. How often do we need it? In my last application, from which these examples come from, 7 of 10 popups were "custom" and needed specialized classes.

There's more...

We'll squeeze even more from this code. Suppose your app uses Facebook JavaScript SDK and you want to display wall post dialog - something like this:

Seems like another kind of popup, don't you think? It would be great to put them in our queue, so they're modal (just like any other popup, with overlay blocking rest of the interface) and so we can easily display them between other popups. In my opinion this results in much better user experience. We'll also have just one API to display popups, with no exception for those Facebook ones.

The (small) problem is that Facebook SDK does not follow MVC pattern, and even if it did, it would not follow our conventions with appending subviews. So one of our popups won't be really MVC, but it doesn't bother us, because no-one will know (maybe except PopupQueue). This is the kind of "code smells" that I don't care about - when our dirty implementation does not leak anywhere else, because the interface is clean.

The only changes are that displayPopup/hidePopup in PopupQueue have to be altered to support popups that will display/hide themselves, just like our Facebook ones. We discover whether a popup manages itself by looking if it supports display/hide methods.

displayPopup: (popup) =>
    if popup.display?
      popup.display()
    else
      @view.append(popup.view)

  hidePopup: (popup) =>
    if popup.hide?
      popup.hide()
    else
      @view.remove(popup.view)

And here's our example wall-post-popup:

class WallPostPopup
  constructor: (@facebook) ->
    $.extend(@, new Observable)

  display: =>
    message = "I'm reading about JavaScript MVC on JanDudek.com"
    description = "Read more about JavaScript, Ruby and web development"

    options =
      link: "http://jandudek.com"
      name: message
      description: description

    callback = => @trigger("closed")
    @facebook.showWallPostDialog(options, callback)

  hide: =>
    # hide method is just to indicate that this popup will manage hiding by itself

Note that we don't call FB.ui directly, but use an adapter object. This approach simplifies testing and makes much clearer what are dependencies of our class (everything listed in constructor arguments). Below is the relevant snippet of our adapter:

class FacebookAdapter
  # ...
  showWallPostDialog: (options, callback) =>
    defaults =
      method: 'feed'
      display: 'dialog'
    options = $.extend(defaults, options)
    FB.ui(options, callback)

Still reading?

Ok, here's another issue. Some objects will need to show many popups, 3 or 4. So they'll receive 4 factories in constructor + popupQueue object. Add a few other dependencies and suddenly arguments list of your class' constructor spans three lines of code.

Also, maybe knowing that there's a queue and popup objects is just too much knowledge for others? Basically you just want to fire a popup and don't care what will happen.

That's why I decided to introduce another class: a PopupManager (yeah, great name...). It knows about any kind of popup and you just call one method to display what you need.

popupQueue = new PopupQueue(new PopupQueueView)
popupManager = new PopupManager(popupQueue, {
  about: -> new AboutPopup(new AboutPopupView)
  wallPost: -> new WallPostPopup
})

class MainController
  constructor: (@view, @popupManager) ->
    @view.bind "about:clicked", =>
      @popupManager.display("about")
      @popupManager.display("wallPost")

Here's the implementation:

class PopupManager
  constructor: (@queue, @factories) ->

  display: (args...) =>
    popup = @create(args...)
    @register(popup)

  register: (popup) =>
    @queue.register(popup)

  create: (args...) =>
    name = args.shift()
    factory = @factories[name]
    factory(args...)

If the list of factories passed to manager grows too large, or the manager exposes too many kinds of popups for other objects, you can split factories list and have many managers sharing one queue.

That's all, folks!

I hope that you've found something useful in this long blog post, even if you're experienced JavaScript developer. Feel free to leave comments if you have any questions. Or if you think it was total bullshit :-)

I've also prepared a a working example (with tests). Here's its source. In the example code there are many details and techniques that are beyond scope of this blog post. Again, feel free to ask in comments if you have any questions.

Factories in JavaScript

2012-01-03T00:00:00+01:00

3 January 2012 - Wrocław

In recent projects I've been working on, I tried to use dependency injection in JavaScript as much as possible. The idea is to create instances of objects in one place, an Application class or some other kind of initializer - instead of using new all over the code. However, sometimes you need to defer object instantation for some reason, for example:

the object's constructor needs parameters unknown during initalization
there will be many instances of such object (possibly unknown number of them)

This is easy to solve with factories: functions that create instances. I know it sounds a bit Java-like and enterprisy, but in JavaScript (and especially in CoffeeScript) it's really simple. Here are some examples:

audioPlayer = new AudioPlayersPool(10, -> new AudioPlayer)
# the pool will create 10 instances of the player

clock = new Clock
createCountdown = (seconds) -> new Countdown(clock, seconds)
# we don't know how many countdowns we'll need

createTask = (attributes) ->
  new Task(serverSide, gameWorld, clock, earth, cannon, attributes)
createGameSession = (attributes) ->
  new GameSession(serverSide, createTask, attributes)
game = new Game(serverSide, createGameSession)

The last example shows another advantage. Before refactoring and moving GameSession and Task creation outside of Game class, the initialization looked like this:

game = new Game(serverSide, gameWorld, clock, earth, cannon)

The first, refactored version is much better, because game only needs to create gameSessions, not to deal with clock or gameWorld directly. Introducing factories leads to passing more specialized dependencies to other objects. Often it means less dependencies as well. As a result, objects have less knowledge about other parts of the application - which seems to be a good thing.

I hope you'll find factories useful in your code too!

Bbq & sessions pool

2011-12-16T00:00:00+01:00

16 December 2011 - Wrocław

Yesterday my friend paneq merged my patch that adds sessions pool to Bbq. This is nice addition, especially because it's mine :) I will quickly describe the ideas behind bbq and my contribution.

Bbq is a Ruby gem for acceptance testing of Web apps. The idea is to use objects - so called test actors - that have meaningful methods describing their actions and/or expectations. Similar to Cucumber, but without the natural language part (but still pretty much readable). Here's an example:

@alice = TestUser.new(:driver => :selenium)
@alice.visit_homepage
@alice.click_link "Posts"
assert @alice.see? "My post"

Bbq is rather thin wrapper around Capybara - an excellent gem that gives consistent API for different testing tools, like Selenium or rack-test.

One of use cases where Bbq really shines is testing interaction between many users. Each TestUser instance has it's own Capybara session and you can mix actions of different users:

@bob = TestUser.new
@bob.visit_homepage
@bob.click_link "Posts"
assert @bob.see? "0 comments"

@alice.fill_in "Comment", :with => "Lorem ipsum"
@alice.click_button "Add comment"

@bob.click_link "My post"
assert @bob.see? "Lorem ipsum", :within => "#comments"

Please note that @alice and @bob can use different drivers, for example one of them might be using Selenium to execute JavaScripts and the other could use rack-test (and run much faster). You can even replace TestUser with TestClient - an API client - that issues HTTP requests without a browser. This is a great approach used in some of our Facebook games that expose REST API and also a "traditional" admin panel with regular views etc. Successful testing of such app often involves combination of rack_test, Selenium and API clients (and some client-side acceptance tests, but that's a different story).

So what does my addition do? Before yesterday, each time you created a TestUser, a new Capybara session was created. This can be quite expensive, especially when using Selenium, as it means running a new browser instance. That's why we added a sessions pool, that reuses sessions between test cases. Each time you create a TestUser, it calls Bbq::Session.next. If there are "idle" sessions, one of them is returned. Otherwise it creates a new one. All existing sessions are kept in Bbq::Session.pool (i know, ugly global object) and released during test's teardown.

You can skip using session pools by providing :pool => false as TestUser option or by providing already created Capybara session with :session option.

I hope you enjoyed this post! If you're interested, try bbq today! It's really easy to get started. Bbq supports Test::Unit as well as RSpec out of the box, but you should be able to easily use it within any other test framework.

PS. Bbq was developed by folks from DRUG, a Ruby users group from Wroclaw area. If you live anywhere near, or if you want to visit Wroclaw, feel invited to one of our meetings! There's always a good amount of tech talks, flame wars and lots of beers. We're also organizing wroc_love.rb, great conference about Ruby & related topics.