0

I am finding this pattern to be quite convenient, but I am wondering if it will come around to bite me later:

app.controller('MyController', function($scope, $stateParams, MyPageService){

   var foo = MyPageService.foo($scope);

   scope.bar = function(opts){
      return foo(opts);
   };

   $scope.baz = MyPageService.baz($scope, $stateParams);


});

where MyPageService looks like:

app.factory('MyPageService', function(MySharedService){

  return {

      foo: function($scope){
         return function(opts){
             return MySharedService.xyz(opts.v);
          }
      },

      baz: function($scope, $stateParams){
         return function(opts){
             return MySharedService.ijk(opts.z);
          }
      }

  } 

});

this is Angular, but again, this is also just JavaScript, so this should work and has been working in my brief testing of this pattern.

Is there anything that someone might see as "wrong" with this pattern? Any future pitfalls that might go otherwise unforeseen?

I have to say, this pattern is working very well as it stands now. The motivation to do this of course, is because our controller code was becoming massive and it was becoming very necessary to break things out in to pieces. This seemed like the most natural way to do it.

Mistalis
  • 17,793
  • 13
  • 73
  • 97
Alexander Mills
  • 90,741
  • 139
  • 482
  • 817
  • 4
    Why are we still using $scope in 1.6? Bind variables to the controller instance. – Phix Mar 15 '17 at 06:08
  • 1
    *Common logic should be placed in services*. Since you are passing the `$scope` to service it is depending on the scope eventually making it reusable will be an issue. – Gangadhar Jannu Mar 15 '17 at 06:09
  • You would reuse the code, but with a new $scope, whatever $scope was passed to it. A new controller would pass a different $scope to the functions. – Alexander Mills Mar 15 '17 at 06:11
  • @Phix I am relatively new to Angular, working on refactoring an older Angular 1.6 project - can you please show an example of what you're talking about? Feel free to add an answer. – Alexander Mills Mar 15 '17 at 06:11
  • 3
    If you enrich scope in service no problem, Like adding general crud promises. But if you keep reference to scope can cause memory leakage after scope destroy – hvojdani Mar 15 '17 at 06:15
  • @tomcater great point, I am not sure how to dereference $scope in the services, in that case. However, I think once the controller is destroyed the service functions will get destroyed as well, because those are only referenced in the controller, so it should be ok. – Alexander Mills Mar 15 '17 at 06:20
  • @Phix think I found what you were talking about - https://toddmotto.com/no-scope-soup-bind-to-controller-angularjs/ – Alexander Mills Mar 15 '17 at 06:29
  • 1
    @Alexander Mills "refactoring an old 1.6 project". It's the latest 1.x branch. But yea, Todd motto is a good resource. $scope is rarely if ever used post 1.3 or so. – Phix Mar 15 '17 at 07:45
  • I am not sure I truly understand why $scope fell out of favor. Just because "this" is more convenient? – Alexander Mills Mar 15 '17 at 07:54
  • Assume you have a business service named dataservice and your service has a method named enrich. Enrich assigin method and properties to input scope parameter. And call it from controller it something like this: dataService.enrich(scope); inside enrich method do not keep any reference to scope. Codes like this are ok-> scope.prototype.saveForm = function() ... – hvojdani Mar 16 '17 at 19:23

1 Answers1

0

This totally worked for us in a big application, in terms of short-term performance, no problem. Haven't checked for memory leaks, however, but I don't think that will be a problem.

Alexander Mills
  • 90,741
  • 139
  • 482
  • 817