Monday, February 15, 2016

Partial application using bind


There has been renewed interest in Functional Programming in the JavaScript community over the last couple of years. And this may be in part due to Facebook's React, Flux and Flux- inspired Redux frameworks. 
I have been learning a bit of FP myself. Along the way, I noticed that I was using a powerful JavaScript feature for doing something very trivial i.e. to hard-bind function context to an object, using Function.prototype.bind
At the risk of digressing, here is a little background:
Most of us are aware of the this problem in JavaScript. Dont worry if you are not, you should still be able to recognize this type of code:
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
var Widget = {

 addEventListeners : function(btn){
   var self = this; 

   on(btn, "click", function(){
     self.updateText();
     self.doSomeOtherStuff();
   });
 }

 updateText: function(){
   // update text of some label
 },

 doSomeOtherStuff: function(){
    // do other stuff, isnt it obvious? 
 }

}
Look at line # 4. The reason we need to do self = this is because, inside the event handler, the value of this may have changed. (If you are using jQuery, i think its the button object. If its the plain old button element, it is the event object.) Kyle Simpson does a fantastic job at describing the this confusion in his YDKJS series
Link to relevant chapter

bind offers an elegant way to...for the lack of a better word.. bind the context i.e. the this variable. So, the above code can change to: (I will capture only the changes below):
1
2
3
4
5
6
 addEventListeners : function(btn){
   on(btn, "click", function(){
     self.updateText();
     self.doSomeOtherStuff();
   }.bind(this));
 }
Notice line #5 .. we used the syntax function(){ }.bind(this)
By doing this, we no longer need an intermediate variable (self) because we hard-bound this to the function using the syntax
The above is what I am referring to as a trivial application of using bind.

Coming back to our main topic of discussion.. I recently learnt that bind can be used as a way of using a neat Functional programming paradigm known as partial application. .
Lets start with the definition: Giving a function fewer arguments than it expects is called partial application. The act of giving fewer arguments has the effect of pre-filling some arguments.
The Wikipedia definition is bit more complicated and perhaps there is a lot more to partial application than my simplification, but it will be adequate for our purposes now.
Lets start with an over-simplified example
Consider the following function

1
2
3
function add(a, b){
  return a + b;  
}
It can be invoked like so: add(2, 3) // 5
Suppose you need a functon to increment the given value by 1
1
2
3
function increment(a){
  return add(1, a);
}
Using bind, you can do the above in a more concise manner:
var increment = add.bind(null, 1);
We pass in null as the first argument since we dont care about the context in this example.
increment(4); // 5
increment(7); // 8
Thats all good... Now, suppose we did not have the bind feature, and our requirements were such that we need a incrementByN where N depends on a value of some other computation, how would we achieve this. 
We would need a incrementByN maker.. Lets see what that could look like
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
function makeIncrementByN(n){
  return function(numberToIncrement){
    return add(numberToIncrement, n)
  }
}

var increment = makeIncrementByN(1);
increment(4); // 5
increment(7); // 8

var incrementBy10 = makeIncrementByN(10);
incrementBy10(4); //14
incrementBy10(7); //17
Now, whats the point of the above ? 
Look closely at makeIncrementByN. There is a pattern to it: it takes one of the two needed parameters( of the add function) and returns a function that takes the remaining parameter. This can be generalized as

1
2
3
4
5
6
7
8
var partial = function(fn, param1) {
    return function(param2) {
        return fn(param1, param2);
    };
};

var incrementBy20 = partial (add, 20);
incrementBy20(2); // 22
So, how does all of this relate to Function.prototype.bind ? 
Look at the partial function definition above, This will only work for functions that take 2 parameters. 
If we had the following function
1
2
3
4
5
6
7
var add = function(){
  var sum = 0;
  for(var idx = 0; idx < arguments.length; idx++){
    sum += arguments[idx] ;
  }
  return sum;
}
The function takes any number of arguments and returns the sum. The variable 'arguments' is a special and implicit parameter is available in all functions. It an array-like structure that contains all of the arguments passed to the function. 
(The above type of function is known as variadic function because it can take a variable number of arguments)
If we wanted a function that adds 10 to the sum of the other passed-in arguments, we can do this elegantly using bind like so:
var adderOf10 = add.bind(null, 10);

adderOf10(2, 3, 5); // 22
For completeness sake, I am repeating that the first argument is null because we dont care about passing in the context.
There... isnt that elegant. and we can do this using a native language feature without requiring external libraries. OSS libraries are great, dont get me wrong. As a beginner, I think bind is a great way to get started with Functional programming patterns. 


References

  • http://raganwald.com/2013/03/07/currying-and-partial-application.html
  • bind on MDN 
  • http://jrsinclair.com/articles/2016/gentle-introduction-to-functional-javascript-functions/









Wednesday, February 10, 2016

Object prototypes in JavaScript

In this post we will try to understand how to make use of JavaScript's Object prototypes to achieve code re-use i.e. to do Object (Oriented) programming[1].

It would be very useful read this without thinking of Java's notions of OO.

In JavaScript, we do not need special constructs( such as classes)  to create instances/objects. If we want an object, we just create one like so
1
2
3
4
5
6
7
var myCar = {
 numGears: 4,
 drive: function(){
  console.log('driving');
 }
}
myCar.drive(); // driving
And then another
1
2
3
4
5
6
7
var yourCar = {
 numGears: 5,
 drive: function(){
  console.log('driving');
 }
}
yourCar .drive(); // driving
No classes, no new keyword, no constructor function... plain and simple.
We can do better.. you would have noticed that the drive method(its really just a regular function) is repeated in the objects. It is the exact same code.  As we all know, code duplication is the enemy of the programmer. 
To facilitate sharing this function across the 2 objects, lets first pull this function out into a separate object. Lets call this object CarPrototype
1
2
3
4
5
var CarPrototype = {
 drive: function(){
  console.log('driving');
 }
}
The way to read CarPrototype would be as the object where we would add common functionality of car-type objects. 
Its not accidental that I used the phrase "Prototype" in "CarPrototype". More on that soon.
Now to make use of this shared object among myCar and yourCar objects, we would conceptually need the following.



i.e. more generically stated, we need a way to link objects to other objects[2].

Object.create


There is language support to achieve the above linking using the Object.create[3] function
As the name indicates, its used to create objects. Lets re-create myCar and yourCar using this.
1
2
3
4
5
var myCar = Object.create(CarPrototype);
myCar.numGears = 4;

var yourCar = Object.create(CarPrototype);
yourCar.numGears = 5;
Lines 1 and 4 do the following couple of things:

  1. Create and return a new object just like the humble object literal - { }
  2. And also create the linkage (thats shown as a dotted arrow in the picture above) from myCar and yourCar to CarPrototype

This linkage is the one of the most important concepts in JavaScript. It is known as prototype relationship between objects. Hence the reason for me to name the shared object as CarPrototype

Good-to-know facts about the prototype link
  • It is referred to as [[Prototype]] in the official spec
  • It is available via the __proto__ property (pronounced as dunder-proto) like so: 
    • myCar.__proto__
  • It can also be accessed using the Object.getPrototypeOf function like so:
    • Object.getPrototypeOf(myCar)
  • It is often confused with the prototype property that functions have

Foot-note:

[1] It was tempting to title this post as Object-oriented programming in JavaScript.. but I realized that it would have disappointed the Java developers who would stumble across it in their search to understand how to create classes in JavaScript.
[2] Kyle Simpson has formalized this into what he terms as OLOO (Objects linked to Other Objects) in his excellent You dont know JS series. 
[3] I wanted to link to the MDN doc for this but I refrained from doing so because at the time of this writing, their example highlights a class-style pattern which at best leaves a reader confused and at worst could lead new developers into assuming that its the MDN-recommended way.

Monday, January 11, 2016

Class style programming in JavaScript: Part 2

In Part 1 of this post we explored the class style paradigm for developing modular code. I encourage reading it before continuing. Its ok if you dont want to, here is the tldr; bullet-point version:
  • Classes are not a language construct in JavaScript
  • Class-style programming can be simulated because of the language's flexibility
  • Function names are capital-cased but the upper-casing is convention-only i.e. to make them look like Java's class constructors. 
    • var Car = function() {};
  • Invoking these functions with the new keyword creates objects/instances
    • var myCar = new Car();
  • A prototype property exists on all functions. It is an object.
    • console.log(Car.prototype); // Object {}
  • Code(data/functions) that is meant to be shared across these different instances are added to the prototype property
    • Car.prototype.drive = function() { //do stuff };
All that said, we have to admit that the using the prototype property to achieve class-style programming feels nothing like using Java's classes. But that was the intent when the feature was added to the language i.e. to make it more familiar to Java programmers.
In this post, we will try to understand how we would achieve code re-use similar to Java's Class-based inheritance pattern. 
Continuing with our Car example .. if we needed a specialized version we could call it NextGenCar which essentially built upon the existing features. How would we model these requirements where NextGenCar needs the following:
  1. Its constructor to re-use Car's constructor and initialize additional instance properties
  2. Inherit all of Car's features
  3. to drive more efficiently than the current drive i.e. it needs to extend drive()
  4. to have a completely overhauled braking system i.e. it needs to override stop()
  5. to have a way to switch to driverless mode and back 
The code solution below is annotated with comments on how each of the above requirement is satisfied
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
var NextGenCar = function(numGears, numWheels){
   // #1: Use the call method thats available on functions to mimic super constructor call
   Car.call(this, numGears); 
   // #1 Initialize additional properties
   this.numWheels = numWheels; 
}

// #2: Using Car's prototype as blue-print create a new object 
// and set it as NextGenCar's prototype 
// so that it inherits all methods of Car via Object [[Prototype]] linkage
NextGenCar.prototype = Object.create(Car.prototype);

NextGenCar.prototype.drive = function() {
   //#3: Use the call method to mimix a super call to the method on the "super-class"
   Car.prototype.drive.call(this); 
   console.log('more for the gallon'); 
}

NextGenCar.prototype.stop = function() {
   console.log('you said stop and i stopped before you finished saying'); // #4
}

// #5: New methods
NextGenCar.prototype.switchMode: function(mode){
   console.log('cruising in '+mode+' mode');
}

var myNextGenCar = new NextGenCar(4, 4);
myNextGenCar.switchMode('driverless'); //cruising in driverless mode'
I think the above code is definitely hard to understand and barely represents what we are trying to do.
Lets see if a picture helps..



(the dotted arrows indicate the prototype linkage between objects)

Did the picture help ?
maybe.. a little bit. But I think this exercise helps realize the futility of attempting class-style programming in a class-less world. There are better alternatives - Object Programming using prototypes and/or functional programming. I will explore the former in my next post.

All that said, it is still useful to understand constructor functions and the prototype property on functions because these are deeply entrenched in the language. There is also a class of problems that can be solved elegantly using ES6 classes only  and not using the alternatives mentioned above (and this will be a topic of a blog post for an other day)

References


Wednesday, September 23, 2015

JavaScript's new operator

In a previous post we explored the class-ical programming paradigm in JavaScript
The constructor pattern is a fundamental aspect of the class-ical paradigm
A constructor is code using which objects can be created from a class using the 'new' keyword
.
Under the hood, JavaScript uses it's prototypal mechanism to support this feature. In other posts I explore the prototypal form in depth. For now, lets try to understand how 'new' works:

Lets create a function Person to behave like a Java Class

1
2
3
4
5
function Person(first, last) {
  this.first = first;
  this.last = last;  
}
var s = new Person("Deepak", "Anand");

Here are the things that happened after the last line was executed:

  1. new creates a new object, lets call it this
  2. the (constructor) function Person is called like so: this.Person ("Deepak", "Anand")
  3. this is returned
Using upper-case for function-names that are used as constructors is convention only, not a language construct.

Now, what if you want methods in your "class"

Easy enough....

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
function Person(first, last) {
  this.first = first;
  this.last = last;
  this.getFullName = function() {
    return this.first + ' ' + this.last;
  };
  this.getFullNameReversed = function() {
  return this.last + ', ' + this.first;
  };
}

This works, but is not very efficient. For every Person instance, 2 function objects are created.
The solution is to add methods to the function's prototype property like so:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
function Person(first, last) {
  this.first = first;
  this.last = last;
}
Person.prototype.getFullName = function() {
  return this.first + ' ' + this.last;
};
Person.prototype.getFullNameReversed = function() {
  return this.last + ', ' + this.first;
};

References:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/new
https://developer.mozilla.org/en-US/docs/Web/JavaScript/A_re-introduction_to_JavaScript

Tuesday, September 1, 2015

Web Components - API dilemma

Some time ago, I started looking at Web Components. It sounded promising at a high level.

But as it often is, the devil is in the details.

As I started playing with it, I realized that the APIs of HTML Elements have 2 surface areas
1. Attributes
2. Properties

Quick refresher on what these two are:
Attributes are available on the HTML elements, you use them via the following APIs
getAttribute(attr-name)
setAttribute(attr-name, attr-value)
removeAttribute(attr-name)
hasAttribute(attr-name)
Eg: if it were a <input type= "text" value="foo"> element
one of its important attributes is "value"

Properties are available on the DOM object. you can access them like so:
element.propertyName
i.e. for the input element example, it would be
element.value

For reasons I dont quite understand, with the HTML Form elements,  the behavior of attributes and properties is not consistent. Its a topic of another post. Please read it before continuing if that does not sound familiar to you.

My puzzle is
Should a web component behave similar to the native HTML form elements or should it
allow users to use both attributes and properties to get and set its state.

It was great to find a best practices document on the web components community
Link to Web Component best practices

Items 4 and 10 are of interest. To quote:
4.  Attributes for data in: Use attributes to pass configuration in.
10. Harmonize your declarative and imperative APIs: Attributes form (part of) your declarative API; your prototype defines your imperative API. Try to keep the analogous parts linked whenever possible so a user can modify either with the same effect

# 4 seems reasonable, a different way of saying the first part of #10 "Attributes form (part of) your declarative API"
The second part of #10 is both a reasonable and an inconsistent recommendation
" Try to keep the analogous parts linked whenever possible so a user can modify either with the same effect"
It is inconsistent because the HTML form elements do not behave as described. Attributes are specified for the component initial configuration whereas properties are used to get/set them after they are constructed. So, attributes are not in sync with the properties. This is something that web developers have come to accept and do not expect to use the attributes for programmatic get/set to the component post-construction.
So, this point is not a best practice, on the contrary, a violation of the standard HTML element behavior, from an HTMl purist perspective.
But all that said, if you are developing web components, choose one approach that suits your team best.

Heres an update on the current state of Web Components
http://www.2ality.com/2015/08/web-component-status.html

Monday, March 9, 2015

HTML Form Elements - Differences in attributes and properties

HTML Form elements are the staple widgets that you come across as a web developer. These are your basic button, text-input field, text area, check-box etc.
But the APIs are not as simple as they seem though, if you are seeing them new.

Lets see why..

The HTML Form elements can be updated by updating the Element attributes and the DOM object properties.

Attributes are available directly on the element
Eg:
<input id ='inputfield' type ='text' value ='foo'>
Here id, type and value are attributes

DOM properties are available via the DOM API on the Element
i.e.
var textInput = document.getElementById('inputfield')
textInput.value is a DOM property

Its nice to see that the property names are consistent with the attribute names(for the most part)

But its confusing that the behavior is not consistent.

Attribute values only represent the initial value
i.e. once a user-interaction changes the state, the attribute values are not representative of the visual,
 whereas DOM object properties can be used to update and query the current state of the element
It has always worked this way and per the spec.
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-49531485

Here is a fiddle to help understand better
http://jsfiddle.net/deepakanand/sLd65egb/3/

Related bug reports (that have been marked as not bugs)
https://bugzilla.mozilla.org/show_bug.cgi?id=223003
https://bugzilla.mozilla.org/show_bug.cgi?id=327020

Thursday, March 5, 2015

Class style programming in JavaScript: Part 1

JavaScript does not have language support for classes in the same way that Java does[1]
But, JavaScript is a versatile language. It can be tailored to mimic different programming paradigms. The Java-style class-based programming pattern is quite popular. So much so, that there are dedicated modules in frameworks such as Dojo declare[2], Prototype's Class.create and the list goes on. This pattern is also commonly referred to as Object Oriented programming, which I think is a misnomer because it really is more about classes than objects. 
In JavaScript, functions play the role of..well.. plain old functions and also to create class-like entities.For this post, we are interested in the latter. When a function is invoked with the "new" keyword, it returns an object i.e. it acts as a constructor.
Lets look at an example:
1
2
3
4
5
6
7
8
9
var Car = function(numGears){
 this.numGears = numGears;
 this.drive = function(){
   console.log("driving");
 }
};

var myCar = new Car(4);
myCar.drive() //driving
Whoa.. the above type of Car cannot be stopped, because there is no method/mechanism in the Car function to do that.
Lets add a stop() method to that
1
2
3
myCar.stop = function(){
 console.log("stop");
}
Do you see a problem with this... yes, only myCar can be stopped now, not the rest of the cars coming out of the factory. Lets see if this assumption is true.
1
2
var yourCar = new Car(5);
yourCar.stop();// TypeError: Object [object Object] has no method 'stop'
So, we need this method on all cars that come out of the factory. If the stop() method were defined as part of the Car function definition in the first code snippet, then all new cars would "inherit" this, but how do we install a "stop" method now. The answer lies in the prototype property available on functions:
console.log(Car.prototype);// Object {}
The prototype property is available on all functions, but make sense only for functions that are used as constructors. The reason will be obvious when you understand their role.
The prototype property on functions point to an object which serves as the the blueprint of the objects created using that function. The newly created objects have a secret link to this blueprint.
But why is it empty in the example .. shouldnt we be seeing a drive() method on it ?
No, because we did not leverage this  prototype property to add the method to this blueprint. Look back at the first code snippet, the drive() method is defined like so:
this.drive  = function(){..
This results in every car instance getting its own copy of the drive() method. (Obviously this is not very efficient. We will correct this later.)
To understand how the prototype property works, lets add stopping functionality to the Car.
1
2
3
4
Car.prototype.stop = function(){
  console.log("stop");
}
yourCar.stop(); // stop
Note that unlike the drive() method, we added the stop() method to the prototype property. This has the effect that all instances get this method including the ones that were created before this method was added
So, that worked.  
Lets paint a picture to remember this better


If we were to redo the Car function from scratch, this is how it would look:
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
var Car = function(numGears){
 // per-instance properties
 this.numGears = numGears;
};

// shared code on prototype
Car.prototype.drive= function(){
  console.log("driving");
}
Car.prototype.stop = function(){
  console.log("stop");
}

var myCar = new Car(3)
myCar.drive(); // driving
myCar.stop(); // stop
This is quite strange-looking, very unlike a Java class.  But it is the way you are expected to do class-based programming in this language.
In another post, I will explore how code is shared by inheritance using the class style paradigm

[1] In the next version of the language i.e. in ES2015 / ES6, you can create classes using the class keyword. Here is a link where you you learn more about it:
Classes in JavaScript - My understanding is that it is mostly syntactic sugar that transforms into the above code.
[2] I originally intended to write about the Dojo declare feature, hence the url of this page name reads as "dojo-declare". The declare module in Dojo is used for creating Java-style classes. The widget framework  - Dijit uses this heavily.