Understanding Angular (from XAML perspective)

After working with Angular for a bit on a project, I wanted to write something to help me solidify in my head the principles and patterns behind Angular JS.

At a high level, Angular is an MVC or MV* pattern implementation.  Of course, I am talking about Model-View-Controller or in more general terms Model-View-Some_Other_Component_That_Puts_View_And_Model_Together.  Coming  from XAML application development side, this pattern is very familiar to me.  In a typical XAML app, I always use MVVM pattern all the time.  For example, I have used Prism on a number of projects.  In those cases I have my domain model (Model) and a view (XAML file) and a ViewModel, a separate class that view is bound to.  Typically, my VIewModel would have a single property that exposes the domain model.  How does this map to Angular you ask?  Angular has a similar structure.  My domain models are just plain old JavaScript objects.  View Model role in Angular is played by $scope object.  Views of course are just HTML views.  Controller’s role in Angular is more subtle.  It is supposed to do only a few things.  It is supposed to build out $scope (View Model) with data and methods.  This is typically done in a constructor function of a controller, where $scope is injected into.  Outside of that, controller should provide the glue between View Model ($scope) and services and may contain business logic.  Service components are very important in Angular.  They should provide interaction with a server or other generic functionality that involves talking to other systems that are parts of the app, maybe calling some remote server to perform CRUD operations.  You want to keep your services separate from controllers, typically also injecting services into a controller through constructor functions, just like scope.  It is a bit harder to pinpoint what component in XAML world Angular controller will map to.  The way I think about it is as follows.  In all XAML apps there usually exists a component responsible for putting views and view models together.  Sometimes it is called controller.  Angular controller’s purpose is slightly different, but main role is still the same: expose view model to the view.  So, the flow of an Angular app as I understand it is as follows.

Once you navigate to a url, routing component finds a view and a controller, both usually configured in a module configuration method.  As part of controller creation new scope object is passed into its constructor.  Controller is responsible for manipulating the scope by using its own logic and any services it depends on.  Services are injected into controller’s constructor as well.  So, key components of the typical screen creation are: view, controller, scope and any services.  It is important to understand that if you navigate to a different view, then back to the original view, new instance of a controller will be created along with a new scope.  However, service is implemented as a singleton in Angular, so the same instance of the service will be passed in.  Hence, if you want to retain the state of a screen through navigation, you can persist some small amounts of data in the service.  Alternatively, you could use rootScope object that is exposed in Angular.  My preference now is  to use a service, primarily because of my aversion to global variables.

It is also important to keep UI manipulation out of controller, as UI manipulation will break testability aspects of the controller.  If you would like to manipulate HTML DOM, you should use directives.  They offer functionality needed to create powerful and reusable UI manipulation components.  if you need to manipulate the data itself in order to present it to the user, you should use filters, not controllers.  They again offer a reusable way to create custom presentation of your data.

If you would like to see a  mapping between Angular and XAML components, here is how I see that.


Component and its role XAML Angular
View XAML control HTML view
Model CLR objects, likely implementing INotifyPropertyChanged JavaScript objects
ViewModel ViewModel class, exposing methods and properties, including one property for the model.  It will need to implement INotifyPropertyChanged as well. Scope ($scope) object
Controller Puts view and view model together.  Likely called from the menu navigation or custom navigation Controller is responsible for populating the scope (view model) with properties and methods and wiring services to provide the data layer.  Also usually called from navigation.
UI manipulation ViewModel through data binding, behaviors, and Visual State Manager Directives
UI formatting Converters Filters

Let me know what you think.


Leave a Reply

Your email address will not be published. Required fields are marked *