Angularjs framework

Infrastructure concerns

Every application has various concerns. One classification of these concerns is application infrastructure concerns and business concerns. The business concerns are specific to an application and differ with each one of them. On the other hand infrastructure concerns are somewhat similar and with right parameterization we can reuse them across applications.

Various libraries and frameworks exist in any technology space to help us with the infrastructure concerns. Writing infrastructure code is (when it is solved by someone else already) is stealing from your employer / client (http://codebetter.com/jeremymiller/2008/11/07/how-to-design-your-data-connectivity-strategy/)

A sample list of such infrastructure concerns in a modern JavaScript application

• Routing, Navigation & History
• Template Engines
• Data-binding
• Communicate with the server to read / update the model
• Responsive Web-design
• DOM manipulation
• Asynchronous Programming
• UI Widgets
• Feature detection
• AJAX

Code Organization

Another level of reuse is the reuse at the conceptual level / design level / idea level. Frameworks excel in this form of reuse. Frameworks are opinionated. They enforce or provide some default architecture / structure to your application. Frameworks have inversion of control. That means frameworks may enforce a life-cycle and typically the framework calls your application code and not vice versa.

UI Architectural patterns are all about Separation of Concerns and having more maintainable code – Divide and Conquer. Frameworks may typically follow (an) UI Architectural pattern(s)

Let us now see how angularjs helps in Code Organization and Infrastructure concerns

What is AngularJS?

I will use and elaborate a slightly modified version of  Amit’s answer to What is AngularJS? When is it needed? on Quora http://www.quora.com/What-is-AngularJS-When-is-it-needed/answer/Amit-Asthana

AngularJS is a JavaScript MVW (Model View Whatever – A term from http://coding.smashingmagazine.com/2012/07/27/journey-through-the-javascript-mvc-jungle/) framework developed by Google that lets you build well structured, easily testable, declarative and maintainable front-end applications which provides solutions to standard infrastructure concerns.

Let us see each one of these

Structure

Angularjs code you write typically falls into one of these buckets

Services –

If you are talking to the outside world, this is a perfect use case for a service – from (http://nathanleclaire.com/blog/2014/03/15/angularjs-isnt-mvc-its-sdc/)

Directives –

Directives are a declarative (Some call this functional, but i believe this is declarative) way of manipulating / working with the DOM. The Web standards too are polarizing in this direction – Example: Web Components. Directives are one of the key aspects of angular (often misunderstood and under used)

Directives are either completely new HTML elements, or attributes that you can throw on existing elements, to perform some kind of DOM manipulation. They can have their own scope and they can be reused, which is one of their most useful properties. – from http://nathanleclaire.com/blog/2014/03/15/angularjs-isnt-mvc-its-sdc/

Views –

The html templates written using angularjs directives and standard html elements

Model –

Angular lets you write non intrusive POJO model objects. Angularjs implements its own dirty checking http://stackoverflow.com/questions/9682092/databinding-in-angularjs/9693933#9693933 which means you can write your models as POJO objects, but it does come with a performance hit.

Controllers –

“glue” of your application. Controllers use model (methods and data) provided by the services and provide them to the directives. – adapted from http://nathanleclaire.com/blog/2014/03/15/angularjs-isnt-mvc-its-sdc/

Testable

Angularjs is designed for ease of unit testing. It is made easier by

• Dependency Injection
• Standard Mock Service Providers

The whole of Angular is linked together by Dependency Injection (DI). It’s what it uses to manage your controllers and scopes. Because all your controllers depend on DI to pass it information, Angular’s unit tests are able to usurp DI to perform unit testing by injecting mock data into your controller and measuring the output and behavior. In fact, Angular already has a mock HTTP provider to inject fake server responses into controllers. – from http://www.sitepoint.com/10-reasons-use-angularjs/

Declarative

See the discussion on directives above.

Infrastructure Concerns

In addition to these angular provides solutions to these infrastructure concerns

• Template Engine – Angular provides a DOM based template engine.
• Data-binding – Bidirectional reactive data-binding
• Routing
• A context aware pub-sub system
• GUI widgets

It will be interesting to see Polymer custom elements and angularjs directives against each other.

References:

http://martinfowler.com/eaaDev/uiArchs.html

http://www.quora.com/What-is-AngularJS-When-is-it-needed/answer/Amit-Asthana

http://nathanleclaire.com/blog/2014/03/15/angularjs-isnt-mvc-its-sdc/

http://www.sitepoint.com/10-reasons-use-angularjs/

http://stackoverflow.com/questions/9682092/databinding-in-angularjs/9693933#9693933

In search of a client-side templating solution

After a long time I am posting a technical entry. I am in search of non intrusive client-side templating solution. The following are the requirements

• Non intrusive Should not require something like

ko.observable, ko.mapping and then tableMetadataViewModel.name(), tableMetadataViewModel.name(‘Employees’)

Ember.Object.create, tableMetadataModel.get(‘name’), tableMetadataModel.set(‘name’, ‘Employees’)

The problem with these kind of solutions is that these solutions are no longer Plain Old JavaScript Objects. They introduce a tight coupling with the templating library / framework which is implicit.

• Is reactive / supports ‘Live Templates’ To Quote from Wikipedia

For example, in an imperative programming setting, would mean that is being assigned the result of in the instant the expression is evaluated. Later, the values of and can be changed with no effect on the value of .

In reactive programming, the value of would be automatically updated based on the new values.

A modern spreadsheet program is an example of reactive programming. Spreadsheet cells can contain literal values, or formulas such as "=B1+C1" that are evaluated based on other cells. Whenever the value of the other cells change, the value of the formula is automatically updated.

In this specific context, when I update the name of the table object by setting an alias like

table.alias = ‘e’

It should automatically update in the UI.

• Two-way data-binding

when I update the name of the table object by setting an alias like

table.alias = ‘e’

It should automatically update in the UI.

And when I update the alias in the UI, it should update the object model.

• Model as the single-source source of truth In this specific context, when I update the name of the table object by setting an alias like

table.alias = ‘e’

All the places in the UI where table is rendered as a view should be updated.

Reactivity and Two-way data-binding go a long way in helping Model as the single source of truth.

• Modular

Supports defining templates in external files and plays nice with requirejs text plugin.

• Performs efficiently

Supports r.js optimizer & requirejs text plugin

For example splitting the application into small modules that have a single responsibility requires writing many modular templates. But i may result in poor performance if we make many calls to load them from the browser. Bundling them with the r.js optimizer for example can reduce this performance hit.

Granular re-rendering

Reactive templates should not mean the whole template is re-rendered every time model changes.

For example modifying an item, adding an item or deleting an item in a list should not re-render the whole template and instead just re-render / add / delete the concerned item nodes and the whole list or worse the whole template.

No dirty checking

For example angularjs uses dirty checking that impacts the performance negatively.

Read this to see what I mean http://stackoverflow.com/a/18381836

• Plays nice with other legacy frameworks / libraries

Recently I tried my hand with Polymer Web Components Stack. I ran into a hard to identify issue. Finally the issue was joint.js(+jquery) which I was using in conjunction with polymer was walking the DOM tree and made an assumption that the root node is the document node. Which is not true when it comes to shadow dom.

• Fits well with Nicholas Zakas’s Scalable Application Architecture

Can I find the templating solution that fits well with Nicholas Zakas’s Scalable Application Architecture? Time has to tell.

http://www.youtube.com/watch?v=vXjVFPosQHw

object.observe, web components based?

Some sort of a dom based templating solution based on object.observe on the modern browsers and an object.observe polyfill in other browsers which do not support object.observe should be good. But looks like knockout, ember etc are not taking up the object.observe route yet. May be I will end up forking knockout and implement one myself.

A build-time two-step transform view?

http://martinfowler.com/eaaCatalog/twoStepView.html with one of the transforms / templating running at build-time may help support multiple template engines from a single template. But it will be really hard to build such a library.

Taking a hard dependency on a single templating solution, esp. for a product does not seem right.

Are there any adapters / abstractions available that help one switch templating solutions over the same Model?

Any suggestions comments would be welcome.