JavaScript

Javascript Method Chaining, aka Fluent Interface

There are several ways to implement the Fluent Interface in JS, and this is one I was using in a project, and halfway forgot.

Testing Angular Promises and the $http XHR Service with Jasmine

This is a rough note, because I finally figured this out after several hours of trying. If I'm wrong, please email me, and I'll fix it.

I had a problem because I wanted to centralize my $http requests in services rather than having XHR calls in controllers. My first attempts used callbacks, but I wanted to convert them to promises, which are a lot nicer. Thus, I had to test promises that used $http.

The TDD/BDD Religion, Getting The

I must admit that I'm fully drunk on the Kool-Ade.

The tl;dr : testing isn't just writing tests, but also using mock objects and services to simplify testing, and using package managers to port code to new versions of modules. It takes days to learn how, but it's worth it.

Making Some Promises (in Parse, but also relevant to jQuery and Backbone)

What a confusing topic. Unfortunately, if you start wanting to add "library" features to your code, like I did, you have to study Promises.

These are notes about Parse.Promises, and the end product is a small object that caches models.

Some Parse.com Cloud Code Gotchas

Getting back into CC has been full of annoying gotchas.

console.log() prints incorrectly

It stringifies the objects instead of using the formats favored by FireBug and Chrome's dev tools. So you will see things like {"foo":1} which aren't plain JS objects, but are really Parse Objects. Parse Object properties are accessed via get() and set().

Assume printed objects are really Parse Objects, which are like Backbone objects, and have a get() and set() method.

How do you get to the object that was saved?

request.object

Translating Angular Events into D3 Events

Converting or translating Angular events into d3 events was a lot easier than I thought it would be. Here's the code:

disp = d3.dispatch('resize');
angular.element(window).bind('resize', function() {
    disp.resize('foobar');
});

disp.on('resize', function(arg) {
    console.log(arg);
    // resize code is here
});

DOM tests in Jasmine

This continues some notes about working on sf-active-js, moving it to a contemporary Javascript development environment.

Here's a Jasmine spec to instantiate an HTML5 widget and test a few of the method calls. These method calls cause changes in the DOM, and these tests verify that the changes happened.

describe("comment", function() {
    var comment;
    beforeEach(function() {
        var elements = $('<div id="disclose"></div><div id="edit"></div>');
        $('body').append(elements);
        comment = Comment('#edit', '#disclose');
    });

Browserify libraries that can be tested with Jasmine... before they are rolled up by Browserify

This is part of a series of notes about bringing a JS project, sf-active-js, over to a contemporary Javascript development environment.

This is a trick to write modules that are testable in a browser, without subjecting the test to Browserify. Why?

I want to develop without the compilation step. It's easier and faster to work in the browser. (This particular app is mostly DOM manipulation, so headless isn't important.) Once the module has settled down, it can be added to the library.

The rest of this note assumes you know the Jasmine sample test runner included with the distro.

Notes on migrating to a contemporary javascript development environment

I'm writing this after writing the first two notes in this series about migrating sf-active-js to a contemporary Javascript development environment.

I wrote the original experiment a couple years ago. It's a JS client that retrieves some json data from the la.indymedia.org server, and displays it. I ran out of time, and didn't finish it then.

Upon revisiting the code, I found it a little confusing. It was around 800 lines of jQuery-style JS.

Node Package Manager, Bower, Yo, Jasmine Beginner Notes

Some rough notes related to the JS development toolchain. I've known JS for years, and have done Crockford-style dev a while, but this JS toolchain stuff is mindblowing and pretty complex. The docs are also pretty confusing. So these are rough notes. Not really a tutorial or the voice of experience.

Local, Global

"Local" means "local to the project".

"Global" can mean "global to the computer" or "global to the user, meaning really local to the user, but global across multiple projects."

It's a bad idea to install things globally to the computer system.

One Event Bus to Rule Them All! d3 dispatch, the d3 event system, notes

Learning d3 events this afternoon. These are the notes I'm taking while I'm learning it. I hope it helps.

It's called d3.dispatch. d3.dispatch('eventname1','eventname2') returns an object that manages setting event handlers, and dispatching events. The event system isn't global (unlike in most frameworks, where the event system appears to be globally available)- it's contained entirely within the object.

Bitten by the "this" scope issue in JavaScript callbacks

I took a step away from Angular and jQuery style coding conventions and dropped back to the traditional JS-style OOP, mainly because I wanted to get familiar with regular JS programming using the MDN docs, and learn the new HTML5 calls (which aren't new anymore).

I ended up coding using an MVC style, and consequently, added an event handling system. It was easy-but-cheesy so I eneded up using Backbone's event system. (It makes me look more hip.)

BTW, here's one way to use Backbone events within traditional JS code:

FooController = function() {
  var obj;

What is Dependency Injection?

I've answered this a couple times so I'm writing it down :)

DI is a way to separate services from the code that uses those services.

DI makes testing easier. It also allows the services to be replaced with alternatives - but this is less important than the testing.

DI is used in Angular, Zend Framework 2, Symfony and more frameworks.

DI is implemented as an array or dictionary of services with generic names. Services are created during startup, and registered.

CORS, Angular JS, and Parse.com, together, didn't let me login twice.

Things were going well with a re-architecting and re-factoring of a service to use Angular's awesome $request, and Django REST Frameworks' awesome ModelViewSet generics. As usual, when things are chugging along, you come across a weird bug that just sucks you in for a while. The bug I hit today involved CORS, AngularJS, and Parse (we're using Parse for part of our backend).

The symptom was that, if I logged in once, then logged out, I could not log in again. I could reach the server, but it wouldn't let me do the exact same thing I'd done just 30 seconds before.

Not Hating on HATEOAS

There's been some loving and some hating on HATEOAS (which I don't know how to pronounce), but I'm starting to get it. See: REST Cookbook, Timeless, and PayPal's API.

The core idea is, in addition to the data, you send over some information about the possible URLs you can use as a next step.

Syndicate content