5

Been reading the Angular.js' Controller docs and stumbled across:

Sharing stateless or stateful code across Controllers — Use angular services instead.

But this leaves me uncertain. How do one can share a stateless/stateful code between controllers? Or what does the "code" mean here? A model? Besides, controllers do not refer to each other, as far as I understood. Can anyone clear things out for me(others) please? Thanks.

Aleksandr Makov
  • 2,820
  • 3
  • 37
  • 62
  • See here http://stackoverflow.com/questions/13180293/angularjs-multiple-uses-of-controller-and-rootscope/13181133#13181133 how a service can be used to keep a state (in this case a menu) across multiple instance of the same controller (but it could be 2 or more different controllers as well). – David Riccitelli Nov 22 '13 at 12:41

2 Answers2

3

I think what they are referring to might be one of the methods to "persist" data, sharing it between controllers or between route-changes. One way to do that is to put it in your rootScope, another is to use a service. If you define a service like this:

.factory("MyDataObject", function() {
    return {};
})

Then MyDataObject will be the same object anywhere you call it, allowing you to save things into it in order to share data, functions and states between controllers (or directives, or other services, etc).

You never know with the Angular documentation, but I would guess that is what they are talking about :)

See for example this answer: Angularjs, passing scope between routes

Community
  • 1
  • 1
Erik Honn
  • 7,576
  • 5
  • 33
  • 42
  • Thanks marking as accepted answer. Since it first came. But yeas, it looks like they actually meant "data" sharing instead of "code" sharing. – Aleksandr Makov Nov 25 '13 at 08:33
2

Here is my view on subject. As angular guys have always tried to explain, scope is not your model. Angular "services" are way to do it, but word service is such and overloaded term. Coming from DDD background, I cannot reconcile word service with a state or statefulness, it just does not make sense to me. What makes more sense is ViewModel or whatever you want to call it. Since I've worked with Silverlight using MVVM pattern, I call them ViewModel. As it is a job of a "Controller" to provide Scope for a View, my controllers have been so far very lean. Bulk of logic is in a ViewModels that get associated with a View through a $scope that controller creates. Does that make sense? So my controller might take a dependency of let's say mySearchViewModel, bulk of the logic is in there and can be shared between controllers, and to associate it with a view you would do something like $scope.vm = mySearchViewModel in mySearchController.

epitka
  • 17,275
  • 20
  • 88
  • 141
  • Thanks, it does make sense. However, I don't quite agree that controller should assign itself a view — i think that it's a duty of a view instead. Because view is alway associated with a controller and it won't work with controller it does not support. Likewise view can have only 1 controller, but controller can have different views. – Aleksandr Makov Nov 25 '13 at 08:32
  • @Makov: I never said that controller assigns view to itself. Controller provides scope for the View. Also, I would stay away from 1 controller being associated with multiple views. – epitka Nov 25 '13 at 13:20
  • sorry I got you wrong. But still, it's quite standard to reuse a controller with multiple views. That's why it's decoupled in the first part. – Aleksandr Makov Nov 25 '13 at 17:56