rangle.ioThe Web Inverted

FUTURE PROOF ANGULARJS

CEO, rangle.io

Nick Van Weerdenburg

ARCHITECTURE

CTO, rangle.io

Yuri Takhteyev

Technology Evolution and Durable Code

• The future is always different then expected.

• Migrations are challenging.

• Standards-based solutions work best.

• Strong core, flexible edges.

J2EE, Rails, Python 3.0, ActionScript 3.0KEY POINT

Plain JavaScript is the starting point for

reusable code across frameworks or across time

As more of your code runsin the browser, this becomes

essential- legacy servertechniques don’t work

(yet)

Three Year Plans – Good or Bad?

• complex requirements

• competing, conflicting requirements

• configurable

• long-lived

• cross-system

Enterprise/Large/Complex Software

The Future-Proof Solution?

Standardize on IE6!

Alternate Solutions?

Future-Proofish Architectures

With a Solid Pragmatic Cost-Benefit Approach

Does Angular Pass This Test?

•D.R.Y

•Structure

•Testability

Soul of Angular (any version)

• Dependency Injection

• Data binding

• Direectives

• Router

• Filters

• Animations

Features That Don’t Change• Forms

• Expressions

• Protractor

• Karma

• Mocks

• Mobile

• Material Design shipping with 2.0

• Improved Router

• Performance and Scale

• Standards (ES6)

• Components (merge controllers and directives)

What’s New

• Well Validated

• Lot’s of prototyping (DI, templates, etc.)

• Lot’s of new ideas testing in AngularDart (used in several internal AngularJS projects)

• External design docs and discussions

• Strong focus on scalability and large project support…this is a benefit that’s gained by migrating from 1.3 when needed

Current Angular 2.0 Status

Migration EffortFEATURE CHANGE TYPE NOTES VALUE RISK EFFORT

DI Decl ES6, true dependency management, Query HIGH LOW LOW

Modules Decl new syntax, declare dependencies. HIGH LOW LOW

Directives Decl Components, DDO->Classes, Leverage DI HIGH LOW MED

Scope Decl Similar to controller As syntax HIGH LOW* MED*

Controllers Decl Now in components (classes) HIGH MED* MED*

Messaging Imp New model is easier, but different (DI) HIGH MED LOW*

Router Decl 3rd party router can still be used MED LOW* LOW*

Angular 2 Value-Risk Matrix

But What About Angular 3.0 And Other Future

Innovations?

Best Practices for TodayThings you should be doing regardless of

your time horizon.

• Won’t cut it as your “model”

• Lead to entangled code

• Complicate testing

• Can hurt performance

Angular’s Nested Scopes

� Use sparingly.

Code that can be written without referring to a controller’s scope should be written this way and should be placed in a service.

“

• Easy to reason about

• Easy to test

• Avoid entanglement

• Dependency injection (DI) is great

Services

� Use aggressively.

• Use “controller as”

• Use isolated directives

When Not Using Services

But what about

Will those methods future-proof your application?

Angular 2.0?

• Your entangled controllers might be a write-off (though, more on this later)

• “Controller as” controllers might be ok

• You should be able to reuse your services (with a bit of work)

If You Ever Migrate from Angular 1.x

• Angular-style DI is easy to stub out

• You can then use Angular services without Angular

• You will need to supply the dependencies, though

Services Are Just Modules with DI

• Allows you to stub out Angular code

• You still get the benefit of DI

Nebular

https://github.com/rangle/nebular

� Treat as a proof of concept

Converting a Service

var angular = require('nebular');

angular.module('koast-logger', []) .factory('_koastLogger', [ function () {

Loading a Service

require('./src/core/koast-logger/koast-logger-service');

var nebular = require('nebular');

nebular.instantiateService('_koastLogger');

var logger = nebular.getService('_koastLogger');var log = logger.makeLogger('foo');

log.info('Hello');

Faking Dependencies

nebular.setService('$q', Q);

More ModularityEnforcing more modularity will make your life simpler. It also has some immediate

architectural benefits.

• Write your code as plain JavaScript modules

• Export them an AngularJS services

• Inject AngularJS dependencies if needed

• But: you might reinvent Angular's DI!

Consider Using Plain JavaScript

• Build a package of "Nebular" services

• Inject actual Angular dependencies

• Export as a single Angular service

• Enjoy more isolation

• Use with or without Angular 1.x

Alternative: Wrapped Services

Example

require('./src/koast');var nebular = require('nebular');

angular.module('koast') .factory('koast', function($q, $http, $log, $window, $location, $timeout) { nebular.setService('$q', $q); nebular.setService('$http', $http); nebular.setService('$log', $log); nebular.setService('$window', $window); nebular.setService('$location', $location); nebular.setService('$timeout', $timeout); nebular.setService('_', require('lodash')); nebular.setAngularUtils(angular); nebular.instantiateService('koast'); return nebular.getService('koast'); });

Multi-Framework Applications

We need to be able to build applications mixing Angular 1.2, Angular 2.0, and

NextBigThingJS

• Encapsulation

• Confinement

Isolation

• Separate JavaScript contexts

• Components communicate via postMessage()

• Usually used for including 3rd party content

• But could be used for building components

• Requires some plumbing

Sandboxed iFrames and WebWorkers

Demo

https://github.com/rangle/multi-framework-app

• iFrame an Angular component

• Represent it as a directive in the parent context

• Or as a web component

Proxy Interfaces

• Shadow DOM helps with encapsulation, somewhat

• Combine with iFrames for true isolation

• Useful for smaller units

• Can provide a nice wrapper for iFramed widgets

Web Components

What’s Your Time Horizon?

rangle.ioThe Web Inverted

CEO, ranale.ioNick Van Weerdenburg

THANK YOU!

@n1cholasv

n1cholasv

CTO, ranale.ioYuri Takhteyev

@qaramazov

yuri

Image Credits

by tromal by Orange County Archives by NASA Blueshift by gazeronly

by theilr by Bart Everson by David Evers