Tracking Model State and Complex Model Relationships

[Pedr Browne]

Hello all,

I've recently started using Angular and I've been really impressed by it. However I've found the Model aspect problematic. The decision to not to be over-prescriptive on Models is a wise one, however I'm struggling to see how to deal with more complex Model relationships within Angular. Most of the examples I've seen keep model state on the controllers' $scope object. In many cases - when the state is directly related to the view such as in a form, this kind of View Model makes complete sense. However, with a larger application where model state is not so explicitly related to the view, this approach seems like a bad one. If a model is used throughout the application, storing its state in a single controller does not necessarily allow it to be shared with other controllers (obviously dependent on scope inheritance / DOM hierarchy). I've found that a side effect of using this approach is that model state often needs to be tracked on root Controllers so that other controllers can share via their scope objects. 

I spent a long time working with Flex and a framework called Robotlegs which is very similar to Angular in many respects. This workflow made heavy use of Models wrapping dumb VOs/DTOs, offering mutators and managing state. These data objects at the core of the models were manipulated as needed, with the model storing state that was not encoded in the data (for example selection). This meant the data was never polluted with state that was only relavent to the application, and allowed the rest of the application to share the model, reacting to its state changes through events or bindings.

Now I am in no way suggesting this is the 'correct' way to do things. It worked great for me and it is how my brain is currently wired to think about the model layer. Where I'm stumbling is in seeing the equivalent in Angular. Most Angular applications feature simple models; usually a collection(Eg. ToDos) which are acquired from a Resource. In these situations, using a Singleton service to wrap the model makes sense, and offers a nice place to add mutators and maintain model state. Where things become more complex is in situations where model relationships go deeper; for example if the data was a collection of Themes, each of which has a collection of Galleries, each of which has a collection of Photographs. At this point, a Sington service no longer makes sense and it would seem to me a necessity to distribute the model data amongst a graph of Model classes which can offer mutators and track state, but this is not something that seems to be encouraged or explicitly supported. 

So my question is how should situations with more complex model graphs be handled? For example in my Themes>Galleries>Images example above , if we pretend that we need to track the selected image for each gallery over the course of an apps lifecycle, where should this state be stored?

Hope that makes some kind of sense. I posted a related question on Stack Overflow yesterday: http://stackoverflow.com/questions/16607874/where-should-model-state-be-stored-in-angular-js/16623282?noredirect=1#16623282

Sorry about the verbosity and thanks for reading this far.

[Andy Joslin]

Have you tried a service?

[Pedr Browne]

A Service works fine in simple cases. For example a GalleryService that has many Photos. In this case - where we are certain there will be a single Gallery, a singleton Service makes sense. It can implement mutators and keep state for the Gallery perfectly well. However this is not an option in the example I outlined above; If we need multiple Galleries to exist side-by-side, each maintaining state. In this case it would make sense to me to have each Gallery wrapped by a Service/Model. I haven't seen any Angular examples that deal with deeper nested model graphs. They all seem to use a single collection of objects.

On Saturday, 18 May 2013 17:22:31 UTC+1, Andy Joslin wrote:

Have you tried a service?

[Andy Joslin]

Couldn't you just make a factory service?

angular.factory('Gallery', function() {

  //define gallery prototype/class
  function Gallery() {

  }

  //return constructor

  return Gallery;

});

Then you could have other factories for each gallery, or have a different dynamic collection of galleries.

angular.factory('PizzaGallery', function(Gallery) {
  return new Gallery();

});

angular.factory('DoughnutGallery', function(Gallery) {
  return new Gallery();

});

angular.factory('Galleries', function() {
  var galleries = [];

  return function addGallery(gallery) {

    galleries.push(gallery);
  }

});

[Ron G.]

I too was a fan of RobotLegs framework until I moved away from Flex after Adobe kicked it out their house to go live with the neighbors as a Spoon project. In light of that, I think you might appreciated Joel Hooks' article on this subject. He too comes from a RobotLegs background. 

Granted that his approach goes against some AngularJS recommendations, but it's not a bad approach. 

Still, since I too am just learning AngularJS, I've always been of the opinion that it is not good to step outside a system until you have lived within it. Otherwise, you may never learn why things were done the way they were done. Once you gain mastery, then I think it's OK to experiment. 

In light of that, I decided to go ahead and follow recommendations to store the model at $rootScope level, such as $rootScope.employees. The advantage of this is that, because every controller $scope inherits from $rootScope, you don't even have to inject it ($rootScope) into the controller. You can just inject $scope as normal, and then reference $scope.employees. The only caveat on that is, you can only read the $rootScope models in this manner. If you want a controller to write/update back to it, then you need to go ahead and inject $rootScope as well. 

The thing I didn't like about this was that, if you want a factory/service to watch for a model change, you have to inject $rootScope. But, this seems to me a violation of its intent. As a scope object, which are designed to be binders between controller and view, they (and their ancestor $rootScope) seem terribly out of place inside a service because it then is too tightly bound insomuch that services should only provide reusable code, and not maintaining state, for the controllers. Nor should the services have knowledge of the controllers and their scopes. So, I opted to have the controllers act as brokers for any $rootScope model, which means controllers must pass any $rootScope model to the service function if the function requires it. And, I place my model watches at the controller level as well. 

I'm actually liking how this is turning out as you can have model properties that are accessible to all controllers, and you can attach properties to the model that are only accessible at a specific child controller scope level. So, this goes to your example of storing state in the model without affecting the data. You can store the model data at $rootScope level and access it as such in each controller. but your child controller scope could append a selectedItem or selectedIndex property that only that child controller "sees". This means multiple controllers can use the same model data, but each can store their own view state properties that don't get propagated back up to $rootScope. 

I know this is going long. Sorry. So, finally, by way of example, a controller's reference to $scope.employees is a reference to $rootScope.employees and all employees in the list (assuming some other controller previously called a service function to get the list and then the controller saved it to $rootScope.employees). But, the controller could also read/write to $scope.employees.selectedItem and that 'selectedItem' property that is associated with the employees model is only visible at the child controller level. You haven't corrupted the model for other controllers. 

[Ron G.]

And, if you find that AngularJS just doesn't cut it for you, check out the ZKoss framework. I've been using that for a couple years, and really like its architecture, based on XUL. This may be much more to your liking as it's a Java framework, which pushes out an HTML5/jQuery client. This framework is what I used for much more complex projects. Comparable frameworks of its type are Vaadin, GWT. 

[Arturo Hernandez]

I may be wrong but this issue seems to be related to data persistence. The browser data is quite ephereal. So it is really up to the particular app use case to when persistent data will be stored or if there is even any persistent data to store anyway. I think most applications persist data rather quickly, so the complex model logic is wrapped up in an API. For an application like a text game or a picture editor. The case mey call for the data to remain in the browser for a longer time. In that case the model logic may be more difficult to deal using services. My feeling is that in the great majority of cases you can store data right away on a server, and that is sort of the norm for websites anyway.

It is good to push things further and there may be a way to extend/use angular to deal with more complex models.

[Ron G.]

No, this has nothing to do with persistence. The OP refers to a Flex framework, called RobotLegs. This is entirely a client architecture. I like to think of it as a client MVC within what is usually a larger stateless context. In most cases, Flex apps, which are deployed as SWFs, make asynchronous calls to web services, which the Flex app unmarshalls into client side subsetted entities representing the server side model. To preempt the nitpickers, yes, there are other ways to tie a Flex app to persistent sessions in a stateful context, but I think that approach was less pervasive. But, anyway, RobotLegs provided a client MVC approach, wherein the client model is really an entity subset of the server side model, delivered through mechanisms such as simple web service calls, BlazeDS, etc. And, the controller, of this client MVC, managed the presentation of the client side model to the views. In addition, there would be client side services that handled the interface to server side services. But, we're off topic. 

[Pedr Browne]

@Arturo Hernandez I am talking about persistence within the application, during its lifecycle. Sure there will be data changes that need to be persisted to the server and there will be view-model changes that are unrelated to the application's data model (for example a form) that only persist for the application lifecycle, but there is a third kind of state - state related to the model that doesn't need to be persisted to the server - transient state. This might include things like which item is selected in a collection. Obviously if the list only existed in a single place, this could be handled in a view model, but what if this selection is important to many different parts of the application?

@Ron G That Joel Hooks article is one of the only ones I've found that deals with the subject, or even the subject of more complex data models, however again, in his example, using a Singleton service makes sense as again the model is shallow - a collection containing a set of objects. So much of Angular seems to be geared towards making many discrete requests to an API to acquire data, building up a data model on the fly, but in my experience for reasons of UI, or simply to cut down on the number of calls to a server, I bring down an application's model in its entirety at the beginning of the app's lifecycle. Obviously this isn't always the case and with bigger models isn't an option, but usually I find this to be preferable to continually hitting APIs as data is needed. In this situation a more complex client-side model architecture is needed, and this feels to me to be missing.

As you say 'I've always been of the opinion that it is not good to step outside a system until you have lived within it', and I thoroughly agree. My problem is I can't see how to do the equivalent using Angular, or how Angular expects me to do the equivalent.

I'm also suspicious of using $rootScope in Services. $rootScope feels to me like it can easily end up as a catch-all collection of objects and variables that are there for convenience, not because it's the best place for them (with shades of globals). An obvious way around my problem is to have a model (in the form of a dumb VO) sitting in the $rootScope and having a AppController managing it and keeping state, but again, this feels like the functionality is there for convenience, not because it is the best place for it. It is shame that  the global event bus, is only accessible through $rootScope and not as a separate entity. That way it could be passed into Services without bringing the rest of $rootScope with it. 

I'm actually liking how this is turning out as you can have model properties that are accessible to all controllers, and you can attach properties to the model that are only accessible at a specific child controller scope level. So, this goes to your example of storing state in the model without affecting the data. You can store the model data at $rootScope level and access it as such in each controller. but your child controller scope could append a selectedItem or selectedIndex property that only that child controller "sees". This means multiple controllers can use the same model data, but each can store their own view state properties that don't get propagated back up to $rootScope. 

This is interesting and I'll have to give it some thought. Thanks for  taking the time to answer.

And to anyone about to jump on me and tell me I'm not understanding Angular, I fully agree and the reason I've asked this question is I'm interested in how I should approach this problem in an Angular manner.

[Ron G.]

On Sunday, May 19, 2013 1:07:36 AM UTC-6, Pedr Browne wrote:

@Ron G So much of Angular seems to be geared towards making many discrete requests to an API to acquire data, building up a data model on the fly, but in my experience for reasons of UI, or simply to cut down on the number of calls to a server, I bring down an application's model in its entirety at the beginning of the app's lifecycle. 

OK. So, this is the core of the problem you're having with AngularJS. I would argue against the wisdom of doing the way you've indicated. To bring down the entire model on a single call, instead of several discrete calls, subjects your app to some problems - unless I'm not fully understanding what you're doing. 

First, to bring down the entire model in one call, it seems you would have to violate the separation of concerns principle in your server side service class. For example, were I to do that with my check approval web app, I would have to build a service that gathers vendor model, voucher model, invoice model, approver role model, etc., and then form them into a single hierarchical model that could be downloaded for this single call. While the single call may seem more efficient, I doubt that, in pure terms of total cumulative req/response times, you actually gain anything because you're actually adding a step: server side build of multiple models into a single model. 

Second, though I have not tried deeply complex models, (and I'm not sure what you're using as your server-side language), as a Java developer, I find that Jackson nicely handles the transformation of nested objects into JSON strings, which can then be unmarshalled into a client side model that mirrors your server side model that was JSONified. In fact, I'm doing that with AngularJS now. I take the returned JSON object and just do a single assignment operation to my client model and it maps in beautifully. 

[Pedr Browne]

Sure. In your example it would be a terrible idea. For me, I'm building a gallery app. It contains many galleries which each contain many photos. When the app is first displayed I need to display the names of all the galleries, with thumbs of each photo within the gallery alongside the names. Rolling over a thumb brings up the name of the image and clicking it loads the image. In this situation, I need the model up front. I get no benefit to making multiple discrete calls. I also need the urls of all the images in all the galleries so I can start proactively caching images. 

I've got Rails on the backend. It's fast and gets me a JSON string of my whole model. That isn't my problem. My problem is what to do with it when it arrives. So what form does your client model take? 

[Ron G.]

Then, this should be pretty simple. Your Gallery model, without knowing all the fields, could be as simple as:

Gallery Model

Gallery 

galleryName

galleryTitle

images

[{imageName: "image1", thumbnailURL: "", fullSizeImageURL: "", ...}]

 {imageName: "image2", thumbnailURL: "", fullSizeImageURL: "", ...}

] 

Gallery 

galleryName

galleryTitle

images

[{imageName: "image1", thumbnailURL: "", fullSizeImageURL: "", ...}]

 {imageName: "image2", thumbnailURL: "", fullSizeImageURL: "", ...}

]

I am actually using a similar structure in my AngularJS app that handles hotel reservation and shows an image gallery of the hotel and room shots as well. And, you're right, it can be downloaded in one fell swoop and map into a client object quite nicely. In fact, you don't even need to define the details of the client JS object. Just declare it as var gallery = returnedJSONString and it will map in to reflect the JSON structure. 

 

 

 

 

 

[pedr browne]

That's pretty much where I got to, but my problem is that I need to store state related to individual Galleries and Photos. I don't want to start adding fields to model object that are not part of the data model, but at the same time I need a place to put it. I also need accessors for each gallery. I can't store state for every gallery and image on the rootScope, and I can't store it on more localised controllers, because other controllers that might be above their scope need access to it. So it makes sense to me to centralise model state on a model object that wraps the JSON data. In fact at the moment I have a series of model objects that each wrap a node of the JSON data. The JSON data remains intact, and each of the models - a single GalleriesModel, a GalleryModel for each Gallery and a PhotoModel manage updating the JSON and maintaining any transient state related to it. The GalleriesModel is a Service which creates its GalleryModels, passing their JSON gallery node into the constructor, then they create their PhotoModels, passing a JSON photograph node to each. 

 

 

 

 

 

--
You received this message because you are subscribed to a topic in the Google Groups "AngularJS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/angular/HGM8d9VtHb0/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to angular+u...@googlegroups.com.
To post to this group, send email to ang...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Phone: +44 (0)788 0600 363

Skype: pedr.browne

Twitter: PedrBrowne

–

Github: github.com/1ndivisible

echolocatorapps.com

undistraction.com

unwalked.com

–

Studio 7

Beaconsfield Studios 

25 Ditchling Rise

Brighton 

BN1 4QL

[Ron G.]

On Sunday, May 19, 2013 1:11:35 PM UTC-6, Pedr Browne wrote:

That's pretty much where I got to, but my problem is that I need to store state related to individual Galleries and Photos. I don't want to start adding fields to model object that are not part of the data model, but at the same time I need a place to put it. 

I don't understand your reticence to append state properties to your nested objects. After all, that is an accepted architectural approach. They are called transient properties - properties not intended for persistence.  The problem you will have with storing state properties elsewhere is that then you've created a need for a sort of client side Hashmap so that you can figure out which state properties belong to which gallery and photo. This creates an unnecessary synchronization problem. Obviously, it's up to you, but I would use what I referred to in a previous post of this thread wherein models are stored at $rootScope, but child controllers append model properties that are only visible at the appropriate controller/view level. You are certainly not corrupting your data model.

[westd]

From the sounds of it, you've got a solution pretty well worked out. I'm certainly not an expert in Angular and I could be far from correct, but I think a decent way to handle the types of issues you've brought up is as follows:

1. If "model" state is to be shared between different scopes/contexts, try wrapping the model in a service.

    In doing so, you're making the model available and injectable into any arbitrary scopes (nested, siblings, etc). One method of doing this would be to just export a plain old javascript object from the model's containing service, and on this object you could provide methods to interact with the model, as well as maybe a "data" property referencing the data itself.

2. If your data is interdependent, you can use "watchers" to track changes to external objects/collections.

    To make use of watchers, you need a scope (which services don't naturally have). You could inject $rootScope into each model-wrapper-service, and  call $rootScope.$new() ... or $rootScope.$new(true) if you really want to isolate it. Then (and this is where it gets hack-y) you could attach your data model to that scope, and export the scope itself (e.g. as the exported "data" property) along with any helpful methods to act on the data. Other services/controllers would be able to call <yourInjectedDataService>.data.$watch(watchExpr, watchListener), and update themselves accordingly, thus allowing cascading/observable/centralized changes to each subsection of your overall data layout... Granted, I'm flowing this off the top of my head, and didn't actually test any of it, but based on my limited understanding of Angular it seems a plausible solution.

[westd]

To further clarify what I was suggesting, here's a more detailed example:

someModule

.service('serviceA', function($rootScope) {

// the model:

var data = { ... };

// a watchable isolate scope,

// on which your model is published:

var scope = $rootScope.$new(true);

scope.data = data;

this.data = data;

this.scope = scope;

})

.service('serviceB', function($rootScope) {

// same routine as serviceA

})

.service('serviceC', function(serviceA, serviceB) {

var data = {

a: null,

b: null

};

function aChanged(newval, oldval) {

data.a = newval

}

function bChanged(newval, oldval) {

data.a = newval

}

// $watch(...) returns an unwatch function

var unwatchA = serviceA.scope.$watch('data.a', aChanged);

var unwatchB = serviceB.scope.$watch('data.b', bChanged);

// make sure not to leave dangling listeners:

serviceA.scope.$on('$destroy', function() {

data.a = null;

unwatchA();

});

serviceB.scope.$on('$destroy', function() {

data.b = null;

unwatchB();

});

this.data = data;

})

On Sunday, May 19, 2013 7:06:36 PM UTC-7, westd wrote:

From the sounds of it, you've got a solution pretty well worked out. I'm certainly not an expert in Angular and I could be far from correct, but I think a decent way to handle the types of issues you've brought up is as follows:

...

[Pedr Browne]

@westd Thanks for your example.

1. If "model" state is to be shared between different scopes/contexts, try wrapping the model in a service.

This works fine with a single model, but Angular's lack of support for non-singleton services means this is clunky for cases where multiple versions of the same model exist simultaneously (I know I can return an ExampleServiceProvider from Service.factory and use it to create a new instance of ExampleService, but this feels ugly - the object dependent on the service shouldn't know of care if it's a Singleton. Having to create an instance of it largely negates the advantages of DI).

2. If your data is interdependent, you can use "watchers" to track changes to external objects/collections.

Yep. Having to pass around $rootScope is really nasty. Would be much cleaner if there was a separate event bus that could be injected independently. That way Services could easily send events. (I know binding is preferable in most cases, but sometimes eventing is needed). 

[westd]

If you're looking for a more generic approach to your wrapper services (one which doesn't require the service's consumer to distinguish between singletons and classes that need to be instantiated--assuming that's what you meant), you might try using <yourmodule>.factory()

For example:

yourmodule

.factory('yourservice', function() {

    // model is a singleton or a class or whatever you'd like:

    var model = ... 

    return {

        get: function() {

            // return the singleton, a new instance, whatever

        }

    }

})

...

The consumer can then just inject this service and call get() on it to get a reference whatever it's trying to wrap.

Second, regarding the lack of an event-bus outside of the normal scope hierarchy, I agree... That would be very useful (for me, at least). One way around that would be to wrap https://github.com/daniellmb/MinPubSub or any other small event-bus library (of which there are many) in a service, and inject it wherever it's needed.

[pedr browne]

The problem with that approach is that it does have to distinguish. It needs to call get on the returned object which is not what it would need to do if the Service was a Singleton. More discussion here if you are interested: http://stackoverflow.com/questions/16626075/non-singleton-services-in-angular.

Regarding the event bus, you are right of course. This is definitely an option, but if I'm going to buy into a framework, this is something I would like to be included.

--

You received this message because you are subscribed to a topic in the Google Groups "AngularJS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/angular/HGM8d9VtHb0/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to angular+u...@googlegroups.com.
To post to this group, send email to ang...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Grant Rettke]

On Sat, May 18, 2013 at 9:14 AM, Pedr Browne <pedr....@gmail.com> wrote:
> I've recently started using Angular and I've been really impressed by it.
> However I've found the Model aspect problematic. The decision to not to be
> over-prescriptive on Models is a wise one, however I'm struggling to see how
> to deal with more complex Model relationships within Angular.

Two good options:
1. Use $rootScope. It is in there for a reason because 20% of the time
it makes sense.
2. Put it all in disparate stateful services and enjoy the nightmare
of trying to make sense of your app. Seriously, you should try it
once, and then you will know first hand and that is true knowledge.

[Grant Rettke]

On Sat, May 18, 2013 at 5:11 PM, Ron G. <grime...@gmail.com> wrote:
> I opted to have the controllers act as brokers for any $rootScope model, which means controllers must pass any
> $rootScope model to the service function if the function requires it. And, I place my model watches at the
> controller level as well.

I did, too, it seems to make the most sense and stay true to the spirit of NG.

[Grant Rettke]

On Sun, May 19, 2013 at 2:07 AM, Pedr Browne <pedr....@gmail.com> wrote:
> I'm also suspicious of using $rootScope in Services. $rootScope feels to me
> like it can easily end up as a catch-all collection of objects and variables
> that are there for convenience, not because it's the best place for them
> (with shades of globals).

The NG folks added a place for global data for a reason; sometimes you need it.

May if you look at MVVM and ask yourself "where should data go that
belongs to multiple views?". Then, $rootScope isn't so scary.

[Grant Rettke]

On Mon, May 20, 2013 at 3:54 AM, pedr browne <pedr....@gmail.com> wrote:
> Regarding the event bus, you are right of course. This is definitely an
> option, but if I'm going to buy into a framework, this is something I would
> like to be included.

Using events to synchronize data is really painful.

[Pedr Browne]

I'm not really sure what you're trying to say. You say these are 'two good options', then infer that the 'nightmare' of putting state in 'disparate services' is a good option 80% of the time.

[Pedr Browne]

As I've mentioned numerous times, binding is preferable, however bindings don't make sense in all cases. 

[Grant Rettke]

On Mon, May 20, 2013 at 4:52 PM, Pedr Browne <pedr....@gmail.com> wrote:
> I'm not really sure what you're trying to say. You say these are 'two good
> options', then infer that the 'nightmare' of putting state in 'disparate
> services' is a good option 80% of the time.

It is one of those things where until you try it, it it doesn't like a
bad idea, but then you find out that it can be really tough. It is
good to try it because that first-hand knowledge will trump all of the
Angular users telling you never to use $rootScope (myself included)
:).

[Nicholas Tuck]

Pedr did you ever come up with a good solution for this?  I have a very similar background as yours and I struggle with the same problem. Something we have done is wrapped all of the galleries in their own object where it's basically {transitive: ..., data: ...}.  We chose this because we want to easily update the data from the backend without loosing all the transitive properties.  This entire workflow is ignored heavily in a lot of the suggested practices which is frustrating from a model layer.  It's ignored because usually $scope has those transitive needs but sometimes you need to share that across the app like your example.  So we have the annoying overhead of half the data is in one root object and half in the other.  We don't really like it so we are trying to limit it as much as possible.

I have considering updating data via angular.extend instead of angular.copy and have the transitive properties live in the main object but it's not a perfect solution either.