Study and notes on "Angular for Large Scale Applications"
We're building a large scale angular app at twixt.it. So Angular for Large Scale Applications is very interesting to me.
Thanks to the presenters for sharing all this information, some good ideas here.
Below are my notes & thoughts on each presentation (still working through all).
Many DCM controllers have thousands of lines of code
Avoid long controllers. Increase complexity. not Dry, not single responsibility
Shows example of a Controller with over 3500 lines of code after moving "a ton of code out"..probably had 7k lines of code before reducing.
Identified 5 patterns for reuse
Regular Javascript
1. Inheritance - good for shared behavior but easy for hierarchy to become too deep and hard to share common code;
How? a. use injector below in child controller and then
$injector.invoke(ParentController, this, {$scope, $scope})
b. ChildController.prototype = Object.create(ParentController.prototype)
2. Composition with Mixins
to share methods on scope or controller; very specific to override but hard to know where code comes from and makes tight coupling
How?
angular.extend($scope, new SortMixin()); /// here mixin code right onto scope
3. Composition with Javascript objects
move code into JS objects and use them on controller, can be faster slightly than angular controller/service BUT can't use Angular dependency injection
Angular Specific
4. use angular services; a singleton function; works well if don't need to deal with state can be injected
5. composition with "helper controllers"
like an object but written as a controller and you instantiate in your code; can have multiple instances and save state
How?
a. define as js contructor fn: function MyService() { this.do = functon() {} }
b. then instantiate in your controller: $scope.aMgr = $controller(MyService);
They preferred the Angular Specific approaches #4 and #5.
Learning: Prefer composition over inheritance. Minimize mixins.
Denis thoughts: hmmm...7k lines of code in a controller...3.5k lines after cleanup! Even at 1k lines I would say a controller is too large because its too difficult to understand and maintain. I once read that "MVC is architecture in the small", that is little widgets with view controller and model code backing them. Thats what we as developers should strive for. Not big monolithic controllers. I agree Angular Services are the best approach. The posts re thin controllers and fat services are what we should be building. Keep your controllers thin and small.
FYI Angular Services are singletons but we define some Angular services to be instantiated by the code using them by returning a constructor function from the Service. I think thats also a valid approach when you need multiple instances.
Goal: reduce boilerplate, easier to reuse apis
They wrapped $resource and $httpBackend in a custom api service
Configuration api is exposed as a provided service. You configure each api call including defaults and model to construct
They wanted to work with logical entities instead of raw server data
They define models as JS constructor functions and their api service will return these objects
They also added methods on model objects afterLoad() and beforeSave() to include code to manipulate data on way in and out. Automatically called.
Denis thoughts: this is very interesting to me. I have concerns about propagating json structure all over the app from api to ui (brittleness) and you also have the question of where to put model logic. I like the way the api wrapper is readable and hides endpoint details too.
I think having Angular service "service models" would work well with this api wrapper.
We implement a service layer which provides atomic methods that wrap http calls and there are cases where the json data is propagated as is up to the ui.
Thanks to the presenters for sharing all this information, some good ideas here.
Below are my notes & thoughts on each presentation (still working through all).
Code Organization Patterns
Important for scaleability because Controllers grow as size of app growsMany DCM controllers have thousands of lines of code
Avoid long controllers. Increase complexity. not Dry, not single responsibility
Shows example of a Controller with over 3500 lines of code after moving "a ton of code out"..probably had 7k lines of code before reducing.
Identified 5 patterns for reuse
Regular Javascript
1. Inheritance - good for shared behavior but easy for hierarchy to become too deep and hard to share common code;
How? a. use injector below in child controller and then
$injector.invoke(ParentController, this, {$scope, $scope})
b. ChildController.prototype = Object.create(ParentController.prototype)
2. Composition with Mixins
to share methods on scope or controller; very specific to override but hard to know where code comes from and makes tight coupling
How?
angular.extend($scope, new SortMixin()); /// here mixin code right onto scope
3. Composition with Javascript objects
move code into JS objects and use them on controller, can be faster slightly than angular controller/service BUT can't use Angular dependency injection
Angular Specific
4. use angular services; a singleton function; works well if don't need to deal with state can be injected
5. composition with "helper controllers"
like an object but written as a controller and you instantiate in your code; can have multiple instances and save state
How?
a. define as js contructor fn: function MyService() { this.do = functon() {} }
b. then instantiate in your controller: $scope.aMgr = $controller(MyService);
They preferred the Angular Specific approaches #4 and #5.
Learning: Prefer composition over inheritance. Minimize mixins.
Denis thoughts: hmmm...7k lines of code in a controller...3.5k lines after cleanup! Even at 1k lines I would say a controller is too large because its too difficult to understand and maintain. I once read that "MVC is architecture in the small", that is little widgets with view controller and model code backing them. Thats what we as developers should strive for. Not big monolithic controllers. I agree Angular Services are the best approach. The posts re thin controllers and fat services are what we should be building. Keep your controllers thin and small.
FYI Angular Services are singletons but we define some Angular services to be instantiated by the code using them by returning a constructor function from the Service. I think thats also a valid approach when you need multiple instances.
Going beyond Angulars Built-in Services
Their app has over 30 endpoints, each page request has on average 7 different types of entities with different business logic and validation rules.Goal: reduce boilerplate, easier to reuse apis
They wrapped $resource and $httpBackend in a custom api service
Configuration api is exposed as a provided service. You configure each api call including defaults and model to construct
They wanted to work with logical entities instead of raw server data
They define models as JS constructor functions and their api service will return these objects
They also added methods on model objects afterLoad() and beforeSave() to include code to manipulate data on way in and out. Automatically called.
Denis thoughts: this is very interesting to me. I have concerns about propagating json structure all over the app from api to ui (brittleness) and you also have the question of where to put model logic. I like the way the api wrapper is readable and hides endpoint details too.
I think having Angular service "service models" would work well with this api wrapper.
We implement a service layer which provides atomic methods that wrap http calls and there are cases where the json data is propagated as is up to the ui.
Comments
Post a Comment