0

For debugging and developing I use an area outside of the ng-view showing what I just want to see. It works fine1, but I had to create both a service and a controller for it. My problem is that dividing the work between them is pretty confusing, so I'd like to get rid of one of them.

I don't mind putting the DebugCtrl in the $rootScope or letting the DebugSvc control a $scope (it's hacky, but it's just for hacking, so what?), but for the former, I'd need to make the controller to a singleton and concerning the latter, I have no idea how to get the $scope.

I'm aware about controllers not being singletons. They can't be, as there may be many independent areas controlled by different instances of the same controller. But in my case, I know I need only a single instance. Given the comments, I guess, I need both, but I also need a clear criteria how to divide the work between them.

1 Of course I use the debugger and logging to console, too, but such a debugging playground complements them nicely. It also has buttons for filling forms by debug data, periodical css reloading, etc.

maaartinus
  • 44,714
  • 32
  • 161
  • 320
  • 1
    Possible duplicate of [What is the lifecycle of an AngularJS Controller?](http://stackoverflow.com/questions/16094940/what-is-the-lifecycle-of-an-angularjs-controller) – Makoto Apr 12 '16 at 15:06
  • 1
    IMO that's not really a good reason to merge the responsibilities of 2 types. In fact, just the opposite. If responsibilities are not clear then it often indicates more division of responsibilities is necessary. To answer your question though, controllers were not intended to be created as singletons so I would not try it if I were you. If you have shared state best keep it in a service. – Igor Apr 12 '16 at 15:06
  • 1
    The above link answers the question if a controller can be a singleton. It isn't. – Makoto Apr 12 '16 at 15:06
  • @Igor I guess, you're right, but I can't see how to divide those responsibilities. I need the thing to be available everywhere (service), but all it does is to control the debugging scope (controller). This confuses me. – maaartinus Apr 12 '16 at 15:12
  • @Makoto It is not, and my question is how to achieve it. Or maybe how to deal with the responsibilities. I found myself dividing the work between the two without any clear logic. That's my primary problem, making the controller to a singleton is just the way how I thought I could solve it. Maybe not the best one. – maaartinus Apr 12 '16 at 15:14
  • @maaartinus - Maybe it would be clearer if you provided what behavior you are trying to reuse and how you want to access it. – Igor Apr 12 '16 at 15:16
  • @Igor As stated in the footnote, there are buttons for filling forms by debug data, periodical css reloading, etc. It allows me to register or log in with a single click. Now, I'm adding the possibility to show an entity displayed in a table row as json-tree. Tomorrow, something else will come - anything not needed in production qualifies. – maaartinus Apr 12 '16 at 15:26
  • @maaartinus - I read that but it does not provide technical detail as to why you would consider wanting to use a singleton or merging a service type with a controller type. – Igor Apr 12 '16 at 15:30
  • @Igor I need to be able to access the thing from everywhere => service. It's needed only once => singleton. It has some controls ("fillForm", "register", "dismiss") => controller. It shows things => controller. – maaartinus Apr 12 '16 at 15:38
  • `It's needed only once` - not necessarily. This could still be a factory or just in a controller. The only real reason to use a singleton is if you have shared state across various instances. If that is the case keep your logic in the controller itself but persist the state to the service. Then you can create multiple instances of this controller across your views but always build on/work with the existing state persisted in the service. – Igor Apr 12 '16 at 15:40

1 Answers1

1
app.factory('controllerSingleton', function () {
  return { ... };
});

app.controller('SomeController', function (controllerSingleton) {
  return controllerSingleton;
});

While the controller is used with controllerAs syntax in this manner, controller instance is a singleton:

<p ng-controller="SomeController as some"><input ng-model="some.value"></p>
<p ng-controller="SomeController as awesome">{{ awesome.value }}</p>

Obviously, this won't work when scope properties are assigned directly to $scope object, which is unique for each ng-controller directive, and this behaviour shouldn't be changed.

Estus Flask
  • 206,104
  • 70
  • 425
  • 565