What is the viewmodel and its structure in Angularjs from a KnockoutJS user perspective

Question

I have a knockoutjs+requirejs background.

I switch to angularjs.

I do not like that in angularjs every bound propert is just attached to the $scope inside the controller.

From a knockoutjs perspective using angularjs now I just would do this:

create a customerviewmodel.js file.

Inside I create a constructor like:

function CustomerViewModel(dataFromServer)
{
   this.data = dataFromServer;
   // and many more properties
}

In my controller.js I would then just do:

var dataFromServer = service.GetData();
$scope = new CustomerViewModel(dataFromServer);

What I prefer about this approach that I have encapsulated my UI-Logic in separate object which I can easily unit test and I do not have to create a controller to unit test UI-Logic which seems very hard because I have to mock out the service call going to the webserver... Also I can reuse my customerviewmodel.js file at multiple places how is this possible when every property is stitched to a controllers $scope?

Does my approach implies unneeded steps or problems I can not think of now due to my zero experience with angularjs?

Is my approach worse concerning testability/extendability/maintainability vs the common approach people do using angularjs a long time?

Answer 1

Does my approach implies unneeded steps or problems I can not think of now due to my zero experience with angularjs?

I tend to move to a "full" view model when the controller is sufficiently complex. If I have many rules about how to construct the view model that diverges from the data that is returned from the server. Or, as you mention, when the data that you want to present is only a small subset of the data returned by the server.

Is my approach worse concerning testability/extendability/maintainability vs the common approach people do using angularjs a long time?

Separating the UI data concern from the data returned by the server will complicate your code (because you have more moving parts). So, maintainability degrades slightly. Otherwise, testability remains about the same and stability increases. What I mean is that your UI forms etc are not directly bound to the data structure returned by the server. This means you don't need to make changes the the form if your server data contract changes. This can make an application easier to maintain.

As mentioned in my comment. I am tending to use an angular factory instead of "newing-up" a view model. However, I have done it in both ways and they both seem to work. If you look at a larger angular project (like ng-grid), you can see that they define classes than are "newed-up" like you describe.

The only other comment I would make is about this code:

var dataFromServer = service.GetData();
$scope = new CustomerViewModel(dataFromServer);

In angular, scopes are important as they sort of define the hierarchy of the page and therefore what is important to react to when an action occurs. So, I would adjust it by not overwriting the scope, but instead, adding a scoped property named viewModel:

var dataFromServer = service.GetData();
$scope.viewModel = new CustomerViewModel(dataFromServer);