Controllers vs. Models for storing non-persisted state

1

There seem to be some varying opinions as to where to store non-persisted state: model or controller. I’ve collected some of the opinions below:

@ebryn (in Intro to Ember @ LinkedIn):

Models represent persisted state on the server … strictly server-persisted state

vs…

@toranb (in should a computed property be declared in a model or controller?):

I imagine a property like “fullName” could be used in more than one place across your application (and having this in the controller would force you to duplicate the effort across different parts of the app)

and @kingpin2k (in Ember ArrayController cannot be sorted by property defined in itemController):

the place where you draw the line on controller and model is wishy washy. If the property needs to persist across controllers then you should add it to the model, especially if the controller isn’t a singleton controller. If it’s a singleton controller and the model never changes underneath it, then the property can live on the controller.

With @ebryn’s approach—using models exclusively for persisted-state—I found it tricky to ensure that each view context was backed by the same controller instance (particularly when using {{render}} and itemController in various parts*). So I’m beginning to feel that it may make sense to use the model for some non-persisted properties, as @toranb and @kingpin2k have suggested. Are there any arguments against using the model in this way?

*(FWIW: I had an isActive property on a controller that needed to be displayed in various views.)

1 Like
2

Uh oh, I got dragged in to something based on something I wrote 6 months ago, that’s like 6 years in Ember time… I think it’s still true, Eric’s statement is the general rule of thumb, yet Toran and my statements are the exception. And your example of using isActive is a great example, especially if the model is being displayed in multiple places in the app.

1 Like
3

Is there not some way to do needs: ['thingController'] in all of the various contexts where you need to know whether a thing has isActive or not?

I’m pretty cavalier about putting extra logic on a model instead of a controller if it is only depending on the data or other models, but even I would look long and hard to keep something as state-specific as isActive off of the model and on the controller.

4

Thanks for your reply. I guess it could be done with needs but it would result in some pretty dirty code (by having to access the property via controllers), and you’d have to be sure that you’re only dealing with the singleton instance.

For example:

App.ItemController = Ember.ObjectController.extend({
  isActive: false
});

App.AnotherController = Ember.ObjectController.extend({
  needs: 'item'
});

App.AnotherController gets the singleton instance, whereas the following gets its own unique instance:

{{render 'item' itemInstance}}
5

The problem with the needs approach is 1 it won’t work for non-singleton controllers, as domchristie pointed out, (itemControllers) and 2 it requires one of the controllers to be the owner of the property requiring it to actually be in the page. At that point you’re essentially saying I always need to access this model as if it were wrapped with that controller. Then you start thinking, hey, I can just create a mixin and have the model extend the mixin, oh wait, same thing as just putting the property on the model.

6

I’ve just discovered another issue with storing state in controllers: it appears that item controllers get torn down when sort properties on the parent controller change: JS Bin - Collaborative JavaScript Debugging

1 Like