III - Better angularjs

< w e b / F>
Better Angular.js
Misnomer, myth and Angular.js goliath

< w e b / F><web/F>
TDD
Test driven development

< w e b / F><web/F>
TDD is a game of chess
A best practice could be:
“Never lose a piece without winning a piece of equal or
greater value.”

< w e b / F><web/F>
• In reality, there are no rules/best practices
• Thereare always situations, responses to those situations and
observations recordedfor future reference.

< w e b / F><web/F>
TDD
Does Test Driven Developmentmeans – write tests first and then code
later to pass those tests?
Probably not…

< w e b / F><web/F>
Idea of TDD
• TDD is about testability.
• TDD is about writing testable code.
• It is not about writing unit test first.

< w e b / F><web/F>
Testable code
• Probably the most important aspect of TDD is readability.
• We spend more time on reading a code than writing it. And the goal
of TDD is to generate a testable code that is easy to read while not
sacrificing its performance.
• Can we call readable code as maintainablecode?

< w e b / F><web/F>
Testable code
• On the surface, testable code is
• Efficient
• As simple as possible
• DRY – Doesn’t repeat
• Modular

< w e b / F><web/F>
Testable code
• Inside, testable code has
• Encapsulation
• Loose coupling
• Separation of concern
• Zero to fewer global objects
• Optimized design patterns

< w e b / F><web/F>
TDD on front-end
Does TDD ideology holds true for front-end

< w e b / F><web/F>
What happens when we move to front-end?

< w e b / F><web/F>
But on front-end
• Testability is problematic,
• Because, though HTML, CSS and JS are three pieces of same stack,
each of them is a stack in itself.

< w e b / F><web/F>
On front-end
• The problem is
• We mix HTML, CSS and JS at will
• Concept of encapsulation is very vague

< w e b / F><web/F>
function implementSomeBusinessLogic() {
// Some business logic
var data = getLatestData();
var $div = $("<div></div>");
// Mixing HTML with JavaScript
$div.text("Data: " + data);
// Mixing CSS with JavaScript
$div.css("color", "red");
// DOM Manipulation mixed with Business Logic
$(body).append($div);
}
Mixing
Presentation, DOM
& Business logic at
will.

< w e b / F><web/F>
function UserList(items) {
this._items = items;
}
UserList.prototype.render = function () {
var $list = $("#userList");
this._items.forEach(function (item) {
$("<li>").text(item.name).appendTo(list);
});
}
UserList.prototype.search = function () { }
Is this a good
encapsulation?

< w e b / F><web/F>
Angular to rescue
Core design and philosophy of Angular.js

< w e b / F><web/F>
Here comes the Angular
• That is exactly whereAngular ratifies & embraces these problems
• Threepillars of Angular

< w e b / F><web/F>
Three Pillars of Angular
• Updating view (HTML/DOM)
should be very trivial
• And that is the first pillar of
Angular.js– Data Binding
DRY – Do not RepeatYourself
DB – Two wayData Binding

< w e b / F><web/F>
• There should be proper separation
of concern and for that you need
structure.
• That is the second pillar of
Angular.js – Directives
• Then there are controllers, services,
routers, etc.
Structure
Directives

< w e b / F><web/F>
• It is not enough to use
framework which is thoroughly
tested. Code on top of it should
also be readily testable.
• That is the third pillar –
Dependency Injection

< w e b / F><web/F>
TDD & Angular
How does Angular helps write testable code?

< w e b / F><web/F>
Angular is solving many trivial front-end
problems.

< w e b / F><web/F>
Problem 1
Modules
Testable design is always modular. There is no exception.

< w e b / F><web/F>
Code organization - Modules
• Any large scale apps needs modules to organize and group related
components.
• Modules help create logical boundarieswithin system.
• Angular.jsmodules existed long before ES6 or Common.js modules

< w e b / F><web/F>
Organizing angular app into modules

< w e b / F><web/F>
But angular modules are yin and yang
There is beast and then there is beauty.

< w e b / F><web/F>
Angular.js Modules – beasts
• No support for namespace
• Probably most criticized aspect of Angular.js modules
• No support for lazy loading
• Practically useless for any other libraries
• Not very intuitiveto encapsulateCSS

< w e b / F><web/F>
The idea is to use modules for what they are
supposed to be used for.
Angular.js module is like a bag that holds one or more recipes.

< w e b / F><web/F>
Angular.js Modules – Beauty
• Logical separation
• Provide better abstractions
• Lazy instantiation
• Module is not instantiateduntil required
• Dependencyorganization
• Small modules makes for a bigger modules

< w e b / F><web/F>
Angular.js Modules – Why
• Code reuse
• Module can be replaced and developed in parallel.
• Better separation of concern
• Config and Run blocks
• Config and run blocks respect dependency tree.
• Code decoration

< w e b / F><web/F>
Two controllers with same name
(function () {
var app = angular.module("HigherModule", []);
app.controller("ControllerSameName", function () {
this.title = "Defined once (1)";
});
this.title = "Defined twice (2)";
});
})();

< w e b / F><web/F>
Two controllers with same name in different modules
(function () {
var lowerModule = angular.module("LowerModule", []);
var app = angular.module("HigherModule", ["LowerModule"]);
this.title = "Defined at Higher Module (2)";
});
lowerModule.controller("ControllerSameName", function () {
this.title = "Defined at Lower Module (1)";
});
})();

< w e b / F><web/F>
Modules – name spacing
• Often misused approach
• Dot notation approach
• Typically observed when backend programmer do Angular without JavaScript
understanding

< w e b / F><web/F>
Two controllers with same name in different modules
app.controller("HM.ControllerSameName", function () {});
lowerModule.filter("LM.customFilter", function () {});

< w e b / F><web/F>
Ideal name spacing technique for handling collisions
app.controller("hmControllerSameName", function () { });
lowerModule.filter("lmCustomFilter", function () { });

< w e b / F><web/F>
Problem 2
Separation of Concern
(Directives, controllers and services)
Testable design adheres to high cohesion along with well defined separation of concern.

< w e b / F><web/F>
Separation of concern – Directives
• Directive are heart of Angular.js
• Separation of concern
• DOM manipulations are abstracted away inside directives.
• Services abstract away server side communication.
• Promoting ideal component encapsulation

< w e b / F><web/F>
What is directivein Angular.js?
Directive is something that extends the meaning
of HTML.

< w e b / F><web/F>
More than one directive with same name?
(function () {
app.directive("mySimpleDir", function () {
return { /* DDO */};
});
});
})();

< w e b / F><web/F>
Idea of extending HTML
• Extension in software programming roughly translates to
• Inheritance
• New meaning
• Overriding existing meaning
• Polymorphism
• Extending the meaning of existing items

< w e b / F><web/F>
Directives – Idea of extension
Thus directives are allowed to extend the meaning… Period.

< w e b / F><web/F>
Overriding default browser behavior
(function () {
// Extending browser autofocus attribute
app.directive("autofocus", function () {
});
})();

< w e b / F><web/F>
Problem 3
Loose Coupling
(Dependency Injection and Angular Bootstrapping)
Software design without loose coupling is never testable.

< w e b / F><web/F>
Loose coupling
• Loose coupling– IoC (Inversion of Control)
• Don’t call me; I will call you
• It is always Angular that initiates the call
• Example,
• Angular decides when to instantiatecontroller
• Angular is responsible for loading templates

< w e b / F><web/F>
Idea of IoC – Inversion of Control
Main
Traditional jQuery style

< w e b / F><web/F>
Idea of IoC – Inversion of Control
Main Main Dependency
Injector
Traditional jQuery style
This is how Angular does it

< w e b / F><web/F>
Dependency injection
• Angular implementsIoC using DI
• DI internallyuses Service Locator pattern
• To understandDI, we have to understand Angular bootstrapping

< w e b / F><web/F>
Angular bootstrap process
Diagram does not illustratethe broader
picture. So let’stry to drill down further…

< w e b / F><web/F>
Angular composition
This is whatAngularis madeup of

< w e b / F><web/F>
Angular composition
Theseboxes areobjects communicatingwith each other. That’s theneed forDI.

< w e b / F><web/F>
Angular composition
Theseobjects areangularcomponents
Filters
Controllers
Services
Constants
ProvidersDirectives
Factories
Values

< w e b / F><web/F>
Angular composition
Special Objects
Controllers
Directives
Filters
Animations
Custom objects
Services
The world of Angularcan be categorized into
The only catch is they
should be singleton.
Angularcalls these
customer objects as
services.

< w e b / F><web/F>
Creating various angular objects
• To create Angular.js objects (custom objects or special objects),
use providers:
• $controllerProvider
• $compileProvider
• $filterProvider
• $provide (service Provider)
• Beware of Internet/Google/Angular.js docs
https://docs.angularjs.org/api/auto/service/$provide

< w e b / F><web/F>
ANGULAR TWO DISTINCT PHASES
Configuration Phase Run Phase

< w e b / F><web/F>
Use different providers toregister your
components/classes/objects with Angular
modules. Angular calls it recipes for
object creation;
Configuration Phase
module.config();

< w e b / F><web/F>
Instantiate objects from the
components/classes registered during
configuration phase. Run Phase
module.run();

< w e b / F><web/F>
BrowserHTML page
Wait for DOM ready
Search ng-app=“module”
Initialize $injector
.config()
.run()
Start playingwith DOM
IoC – Inversion of Control

< w e b / F><web/F>
Code sample with config block
(function () {
app.config(function ($controllerProvider) {
$controllerProvider.register("MyCtrl", function () {
var vm = this;
vm.title = "My Title";
});
});
})();

< w e b / F><web/F>
Reduced boilerplate code
app.controller("MyCtrl", function () {
var vm = this;
vm.title = "My Title";
});

< w e b / F><web/F>
Creating a directive
app.config(function ($compileProvider) {
$compileProvider.directive("mySimpleDir", function () {
// DDO - Directive Definition Object
});
});
// DDO - Directive Definition Object
});

< w e b / F><web/F>
Built in objects in Angular
• Angular understands:
• Controllers
• Filters
• Directives
• Animation
Built in object Correspondingproviders
Controller $controllerProvider
Filter $filterProvider
Directive $compileProvider
Animation $animationProvider

< w e b / F><web/F>
Can we call providers as Classes in plain old
JavaScript?

< w e b / F><web/F>
Creating custom objects
• Remember, Customer objects are called services in Angular
• To create any object in Angular you need provider
• To create custom object, custom provider is necessary
• For that purpose, we need a provider that can create new provider
which is sort of meta provider

< w e b / F><web/F>
About custom objects
• One condition by Angular.js
• Custom Objects (services) should be Singletons
• It is enforced at Framework level by Angular
• One assumption by Angular.js
• Custom Objects should hold your data

< w e b / F><web/F>
Comes $provide
app.config(function ($provide) {
$provide.provider("calculator", function () {
this.$get = function () {
return {
add: function () { },
subtract: function () { }
};
};
});
});

< w e b / F><web/F>
Using custom object
app.controller("MyCtrl", function (calculator) {
calculator.add();
calculator.subtract();
});

< w e b / F><web/F>
Reducing boilerplate – Why so verbose?
app.provider("calculator", function () {
return {
};
};
});

< w e b / F><web/F>
Providers are still verbose
&
weird way to create objects

< w e b / F><web/F>
How we do it in plain old JavaScript?
(function () {
function Calculator() {
this.add = function () { };
this.substract = function () { };
}
var calculator = new Calculator();
})();

< w e b / F><web/F>
Comparing plain JS and Angular
(function () {
function Calculator() {
}
var calculator = new Calculator();
})();
app.provider("calculator", function
() {
return {
};
};
});

< w e b / F><web/F>
So Angular is creating syntactic sugar
app.service("calculator", function () {
});

< w e b / F><web/F>
Comparing two syntax
});
app.provider("calculator", function
() {
return {
};
};
});

< w e b / F><web/F>
What angular is doing internally
});
app.service = function (name, Class) {
app.provider(name, function () {
this.$get = function ($injector) {
return
$injector.instantiate(Class);
};
});
}

< w e b / F><web/F>
Some are not comfortable with new
function calculatorFactory() {
var obj = {};
obj.add = function () { };
obj.substract = function () { };
return obj;
}
var calculator = calculatorFactory();
Enter the
factory pattern

< w e b / F><web/F>
Angular has solution for that
function calculatorFactory() {
var obj = {};
obj.add = function () { };
obj.substract = function () { };
return obj;
}
var calculator = calculatorFactory();
app.factory("calculator", function ()
{
return {
substract: function () { }
};
});

< w e b / F><web/F>
Angular factory pattern
app.factory("calculator", function ()
{
return {
substract: function () { }
};
});
app.factory = function (name, factory) {
app.provide(name, function () {
this.$get = function ($injector) {
return $injector.invoke(factory);
};
});
}

< w e b / F><web/F>
Then there are other recipes
app.constant("STATES", {
DASHBOARD: "dashboard",
LIST: "projectList"
});
app.value("calculator", function
() { });
app.value("PI", 3.1422);
app.value("welcome", "Hi,
Harsh");

< w e b / F><web/F>
But, yes providers are powerful
app.provider("greeting", function () {
var text = "Hello, ";
this.setText = function (value) {
text = value;
};
return function (name) {
alert(text + name);
};
}; });
app.config(function (greetingProvider) {
greetingProvider
.setText("Howdy there, ");
});
app.run(function (greeting) {
greeting("Harsh Patil");
});

< w e b / F><web/F>
Angular core - $injector
• So far, we have just seen how to bootstrap angular. But how does
Angular executes in run phase?

< w e b / F><web/F>
$injector internals
app.value("val", "");
app.constant("CON", 123);
app.controller("MyCtrl",
function () { });
app.factory(“myFactory",
function () { });
Instance
Factory
Instance
Cache
Service Locator
$injector
$injector.get("myFactory");

< w e b / F><web/F>
Problem 4
Using optimized design patterns
Testable software design implements well thought design patterns

< w e b / F><web/F>
Typical Ajax Request example
var http = new XMLHttpRequest(),
url = "/example/new",
params = encodeURIComponent(data);
http.open("POST", url, true);

< w e b / F><web/F>
http.setRequestHeader("Content-type",
"application/x-www-form-urlencoded");
http.setRequestHeader("Content-length", params.length);
http.setRequestHeader("Connection", "close");

< w e b / F><web/F>
http.onreadystatechange = function () {
if (http.readyState == 4 && http.status == 200) {
alert(http.responseText);
}
}
http.send(params);

< w e b / F><web/F>
Same thing with Angular
$http({
method: "POST",
url: "/example/new",
data: data
})
.then(function (response) { alert(response); });

< w e b / F><web/F>
Problem 5
Data Binding
DOM updates should be very trivial. This is the magic of angular.

< w e b / F><web/F>
Plain JS code
// HTML
<button id="myButton"></button>
// JavaScript
var button = document.getElementById("myButton");
button.addEventListener("click", function () {
// Do something
}, false);

< w e b / F><web/F>
How we do it in Angular
// HTML
<button ng-click="doSomething()"></button>
// JavaScript
app.controller("MyCtrl", function ($scope) {
$scope.doSomething = function () {
// Do something
};
});

< w e b / F><web/F>
Creating function in JavaScript
// Technique 1
function test() {
// Do something
}
// Technique 2
var test = function () { };

< w e b / F><web/F>
There is something more to JS
// Technique 3
var test = new Function(arguments, body);
Functions in JavaScriptare objects.
They can be createdjust like any other objects.

< w e b / F><web/F>
// HTML
<button ng-click="doSomething()"></button>
This is a directive

< w e b / F><web/F>
link: function ($scope, iElement, iAttr) {
iElement.addEventListener("click", function () {
var ngClick = iAttr.ngClick;
var func = new Function([], ngClick);
// Setup Angular watcher ...
func();
// Execute watchers & bindings ...
// Run $scope.digest();
}, false);
}

< w e b / F><web/F>
Angular digest function
$scope.prototype.$digest = function () {
var self = this;
_.forEach(this.$$watchers, function (watch) {
var newValue = watch.watchFn(self);
var oldValue = watch.last;
if (newValue !== oldValue) {
watch.listenerFn(newValue, oldValue, self);
watch.last = newValue;
}
});
};

< w e b / F><web/F>
Modern Enterprise Web
Apps

< w e b / F><web/F>
Modern enterprise web application

< w e b / F><web/F>
Then they evolve

< w e b / F><web/F>
• Thereis nothing permanent except change.

< w e b / F><web/F>
Then it becomes all together different

< w e b / F><web/F>
Modern enterprise applications
• API
• Third party integrations
• Packages
• Libraries
• Modules
• Legacies
• Versioning
• Limited eye site for individual
developer & tester
• Nearly impossible to test everything
through leaky abstractions
Abstractions leak when you have to understand the lower level concept
to use the higher level concept.

< w e b / F><web/F>
So how do you write testable code?
• One sure shot way is to write Unit Tests.

< w e b / F><web/F>
When you write unit tests
• When you start for unit testing, you disintegrateor more accurately
isolate different components of the system.
• That is where you can see system as a set of interconnected
components.
• And so goes for the couplingsbetween components.

< w e b / F><web/F>
But most unit testing is not proper
• If you do any of this
• Database
• Any kind of server
• File/network I/O or file system
• Another application
• Console
• Logging
• Other classes

< w e b / F><web/F>
So when do you write unit tests?
• Never do it. Let QA do it
• After some amount of code
• After writing all the code
• Before any code* (Test first)
• At the same time as I write the code

< w e b / F><web/F>
Unit testing in day to day life
1. Describe the behavior of function
in plain English in some readme file.
2. Create a test that is
mostly just a copy/paste
from the readme code.
3. Write the actual function
until it passes the first test.
4. Write a few more tests
for any edge cases I can
think of.
5. Get the function to pass
again
6. Encounter another
edge case, go to 4.

< w e b / F><web/F>
But I find writing unit tests hard
• Because the reality check says unit testing is hard

< w e b / F><web/F>
To simplify
Categorize unit tests as:
• Level 1 – Isolated classes
• Level 2 – State management
• Level 3 – Internal dependency
• Level 4 – State management, internal dependency & DOM

< w e b / F><web/F>
Level 1
Isolated Classes/Components

< w e b / F><web/F>
app.factory("utilsFactory", function () {
return {
constructUrl: function (url, urlParams) {
urlParams = urlParams || {};
Object.keys(urlParams).forEach(function (param) {
url = url.replace(":" + param, urlParams[param]);
});
return url;
}
};
});
No Dependency
No state management

< w e b / F><web/F>
it("utilsFactory should construct url correctly", function () {
var url, params, url;
// Setup data
url = "/api/projects/:projectId"; params = { projectId: 1 };
// Exercise SUT
url = utilsFactory.constructUrl(url, params);
// Verify result (behavior)
expect(url).to.equal("/api/projects/1");
});

< w e b / F><web/F>
We need supporting code as well
beforeEach(function () {
module("myModule");
inject(function (_utilsFactory_) {
utilsFactory = _utilsFactory_;
});
});

< w e b / F><web/F>
Level 2
State Management

< w e b / F><web/F>
app.factory("utilsFactory", function () {
return {
_count: 0,
constructUrl: function (url, urlParams) {
urlParams = urlParams || {};
// ...
this._count++;
return url;
},
};
});

< w e b / F><web/F>
it("utilsFactory should update _count", function () {
var url, params, url;
// Setup data
url = "/api/projects/:projectId";
params = { projectId: 1 };
// Exercise SUT
// Verify result (state)
expect(utilsFactory._count).to.equal(2);
});

< w e b / F><web/F>
Level 3
Internal dependency

< w e b / F><web/F>
app.factory("projectFactory", function projectFactory($http, urlFactory) {
function _getProjects() {
var request = angular.copy({
method: "GET",
url: urlFactory.get("projects")
});
return $http(request).then(function (response) {
return response.data;
});
}
return { getProjects: _getProjects };
});

< w e b / F><web/F>
it("projectFactory should return promise", function () {
var promise;
// Setup data
// Exercise SUT
promise = projectFactory.getProject();
expect(promise).to.have.key("then");
});

< w e b / F><web/F>
it("projectFactory should make call to urlFactory", function () {
var promise;
// Setup data
// Exercise SUT
promise = projectFactory.getProjects();
expect(urlFactory.get).to.have.been.called.once();
});

< w e b / F><web/F>
it("projectFactory should make call to $http", function () {
var url, promise;
// Setup data
// Setup expectation
$httpBackend.expectGET("/api/users/").respond(200, {});
// Exercise SUT
promise = projectFactory.getProjects();
$httpBackend.verifyNoOutstandingExpectation();
$httpBackend.verifyNoOutstandingRequest();
});

< w e b / F><web/F>
beforeEach(function () {
module("myModule");
inject(function (_projectFactory_, _$httpBackend_, _urlFactory_) {
projectFactory = _projectFactory_;
$httpBackend = _$httpBackend_;
urlFactory = _urlFactory_;
// Mocking
urlMock = sinon.mock(urlFactory);
urlMock.stub("get").when("/api/project").returns("/api/projects");
});
});

< w e b / F><web/F>
it(“description", function () {
// Setup data
// Setup expectation
// Exercise SUT
// Teardown
});

< w e b / F><web/F>
What do I need to write unit tests?
• Test runner
• Runtime
• Testing suite
• Assertion library
• Mocking library

< w e b / F><web/F>
Quality of unit tests
A management stake (code coverage)
“I expect a high level of coverage. Sometimes managers
require one. There's a subtle difference.”
“you can't go into production with less than 80% coverage.”

< w e b / F><web/F>
True use of code coverage
Just like this 

< w e b / F><web/F>

< w e b / F><web/F>
80%, 90% is good but 100%
“It would smell of someone writing tests to make the coverage
numbers happy, but not thinking about what they are doing.”

< w e b / F><web/F>
There are lot many things
• URL design
• Quality matrix
• Verification strategies
• Test doubles

< w e b / F><web/F>
Thank You
Any more questions

< w e b / F><web/F>
By
Harshal Patil
@mistyharsh

III - Better angularjs

More Related Content

What's hot (20)

Viewers also liked (10)

Similar to III - Better angularjs (20)

Recently uploaded (20)

III - Better angularjs