AngularJS The correct way of binding to a service properties

Question

I   m looking for the best practice of how to bind to a service property in AngularJS   I have worked through multiple examples to understand how to bind to properties in a service that is created using AngularJS     Below I have two examples of how to bind to properties in a service  they both work   The first example uses basic bindings and the second example used  scope  watch to bind to the service properties  Are either of these example preferred when binding to properties in a service or is there another option that I   m not aware of that would be recommended   The premise of these examples is that the service should updated its properties    lastUpdated    and    calls    every 5 seconds   Once the service properties are updated the view should reflect these changes   Both these example work successfully  I wonder if there is a better way of doing it   Basic Binding  The following code can be view and ran here  http   plnkr co edit d3c16z   lt html gt   lt body ng-app  ServiceNotification   gt        lt div ng-controller  TimerCtrl1  style  border-style dotted  gt           TimerCtrl1  lt br  gt          Last Updated    timerData lastUpdated   lt br  gt          Last Updated    timerData calls   lt br  gt       lt  div gt        lt script src  https   ajax googleapis com ajax libs angularjs 1 0 5 angular js  gt  lt  script gt       lt script type  text javascript  gt          var app   angular module  ServiceNotification                 function TimerCtrl1  scope  Timer                 scope timerData   Timer data                      app factory  Timer   function   timeout                var data     lastUpdated  new Date    calls  0                 var updateTimer   function                      data lastUpdated   new Date                    data calls    1                  console log  updateTimer      data lastUpdated                     timeout updateTimer  5000                              updateTimer                 return                   data  data                                 lt  script gt   lt  body gt   lt  html gt    The other way I solved binding to service properties is to use  scope  watch in the controller    scope  watch  The following code can be view and ran here  http   plnkr co edit dSBlC9   lt html gt   lt body ng-app  ServiceNotification  gt       lt div style  border-style dotted  ng-controller  TimerCtrl1  gt          TimerCtrl1 lt br  gt          Last Updated    lastUpdated   lt br  gt          Last Updated    calls   lt br  gt       lt  div gt        lt script src  https   ajax googleapis com ajax libs angularjs 1 0 5 angular js  gt  lt  script gt       lt script type  text javascript  gt          var app   angular module  ServiceNotification                 function TimerCtrl1  scope  Timer                 scope  watch function      return Timer data lastUpdated                     function  value                        console log  In  watch - lastUpdated     value                        scope lastUpdated   value                                                 scope  watch function      return Timer data calls                     function  value                        console log  In  watch - calls     value                        scope calls   value                                                       app factory  Timer   function   timeout                var data     lastUpdated  new Date    calls  0                 var updateTimer   function                      data lastUpdated   new Date                    data calls    1                  console log  updateTimer      data lastUpdated                     timeout updateTimer  5000                              updateTimer                 return                   data  data                                 lt  script gt   lt  body gt   lt  html gt    I   m aware that I can use  rootscope  broadcast in the service and  root  on in the controller  but in other examples that I   ve created that use  broadcast  on the first broadcast is not captured by the controller  but additional calls that are broadcasted are triggered in the controller   If you are aware of a way to solve  rootscope  broadcast problem  please provide an answer   But to restate what I mentioned earlier  I would like to know the best practice of how to bind to a service properties    Update  This question was originally asked and answered in April 2013  In May 2014  Gil Birman provided a new answer  which I changed as the correct answer  Since Gil Birman answer has very few up-votes  my concern is that people reading this question will disregard his answer in favor of other answers with many more votes   Before you make a decision on what s the best answer  I highly recommend Gil Birman s answer

User · Answer

To bind any data which sends service is not a good idea  architecture  but if you need it anymore I suggest you 2 ways to do that  1  you can get the data not inside you service You can get data inside your controller directive and you will not have a problem to bind it anywhere  2  you can use angularjs events Whenever you want you can send a signal from  rootScope  and catch it wherever you want You can even send a data on that eventName   Maybe this can help you  If you need more with examples here is the link  http   www w3docs com snippets angularjs bind-value-between-service-and-controller-directive html

User · Answer

Late to the party  but for future Googlers - don t use the provided answer   JavaScript has a mechanism of passing objects by reference  while it only passes a shallow copy for values  numbers  strings etc    In above example  instead of binding attributes of a service  why don t we expose the service to the scope    scope hello   HelloService    This simple approach will make angular able to do two-way binding and all the magical things you need  Don t hack your controller with watchers or unneeded markup   And if you are worried about your view accidentally overwriting your service attributes  use defineProperty to make it readable  enumerable  configurable  or define getters and setters  You can gain lots of control by making your service more solid   Final tip  if you spend your time working on your controller more than your services then you are doing it wrong      In that particular demo code you supplied I would recommend you do    function TimerCtrl1  scope  Timer        scope timer   Timer        Inside view    timer time updated       timer other property    etc      Edit    As I mentioned above  you can control the behaviour of your service attributes using defineProperty   Example      Lets expose a property named  propertyWithSetter  on our service    and hook a setter function that automatically saves new value to db   Object defineProperty self   propertyWithSetter       get  function     return self data variable       set  function newValue              self data variable   newValue               let s update the database too to reflect changes in data-model            self updateDatabaseWithNewData data               enumerable  true    configurable  true       Now in our controller if we do   scope hello   HelloService   scope hello propertyWithSetter    NEW VALUE     our service will change the value of propertyWithSetter and also post the new value to database somehow   Or we can take any approach we want   Refer to the MDN documentation for defineProperty

User · Answer

I think this question has a contextual component   If you re simply pulling data from a service  amp  radiating that information to it s view  I think binding directly to the service property is just fine  I don t want to write a lot of boilerplate code to simply map service properties to model properties to consume in my view    Further  performance in angular is based on two things  The first is how many bindings are on a page  The second is how expensive getter functions are  Misko talks about this here  If you need to perform instance specific logic on the service data  as opposed to data massaging applied within the service itself   and the outcome of this impacts the data model exposed to the view  then I would say a  watcher is appropriate  as long as the function isn t terribly expensive  In the case of an expensive function  I would suggest caching the results in a local  to controller  variable  performing your complex operations outside of the  watcher function  and then binding your scope to the result of that    As a caveat  you shouldn t be hanging any properties directly off your  scope  The  scope variable is NOT your model  It has references to your model   In my mind   best practice  for simply radiating information from service down to view    function TimerCtrl1  scope  Timer       scope model    timerData  Timer data        And then your view would contain   model timerData lastupdated

User · Answer

From my perspective   watch would be the best practice way   You can actually simplify your example a bit   function TimerCtrl1  scope  Timer       scope  watch  function      return Timer data     function  data         scope lastUpdated   data lastUpdated       scope calls   data calls       true       That s all you need   Since the properties are updated simultaneously  you only need one watch  Also  since they come from a single  rather small object  I changed it to just watch the Timer data property  The last parameter passed to  watch tells it to check for deep equality rather than just ensuring that the reference is the same     To provide a little context  the reason I would prefer this method to placing the service value directly on the scope is to ensure proper separation of concerns  Your view shouldn t need to know anything about your services in order to operate  The job of the controller is to glue everything together  its job is to get the data from your services and process them in whatever way necessary and then to provide your view with whatever specifics it needs  But I don t think its job is to just pass the service right along to the view  Otherwise  what s the controller even doing there  The AngularJS developers followed the same reasoning when they chose not to include any  logic  in the templates  e g  if statements    To be fair  there are probably multiple perspectives here and I look forward to other answers

User · Answer

I think it s a better way to bind on the service itself instead of the attributes on it   Here s why    lt script src  https   ajax googleapis com ajax libs angularjs 1 3 7 angular min js  gt  lt  script gt   lt body ng-app  BindToService  gt      lt div ng-controller  BindToServiceCtrl as ctrl  gt      ArrService arrOne   lt span ng-repeat  v in ArrService arrOne  gt   v   lt  span gt       lt br   gt      ArrService arrTwo   lt span ng-repeat  v in ArrService arrTwo  gt   v   lt  span gt       lt br   gt       lt br   gt       lt  -- This is empty since  scope arrOne never changes -- gt      arrOne   lt span ng-repeat  v in arrOne  gt   v   lt  span gt       lt br   gt       lt  -- This is not empty since  scope arrTwo     ArrService arrTwo -- gt       lt  -- Both of them point the memory space modified by the  push  function below -- gt      arrTwo   lt span ng-repeat  v in arrTwo  gt   v   lt  span gt     lt  div gt      lt script type  text javascript  gt      var app   angular module  BindToService             app controller  BindToServiceCtrl   function   scope  ArrService           scope ArrService   ArrService         scope arrOne   ArrService arrOne         scope arrTwo   ArrService arrTwo               app service  ArrService   function   interval          var that   this            i   0        this arrOne             that arrTwo               interval function                 This will change arrOne  the pointer              However   scope arrOne is still same as the original arrOne          that arrOne   that arrOne concat  i                This line changes the memory block pointed by arrTwo             And arrTwo  the pointer  itself never changes          that arrTwo push i           i    1           1000               lt  script gt   lt  body gt     You can play it on this plunker

User · Answer

What about   scope     extend scope  ParentScope     Where ParentScope is an injected service

User · Answer

I would rather keep my watchers a less as possible  My reason is based on my experiences and one might argue it theoretically  The issue with using watchers is that you can use any property on scope to call any of the methods in any component or service you like  In a real world project  pretty soon you ll end up with a non-tracable  better said hard to trace  chain of methods being called and values being changed which specially makes the on-boarding process tragic

User · Answer

The Most Elegant Solutions    app service  svc   function    this attr       return this      app controller  ctrl   function  scope  svc        scope attr   svc attr             scope  watch  attr   function neo  old      if necessary            app run function  rootScope  svc        rootScope svc   svc       rootScope  watch  svc   function neo  old      change the world             Also  I write EDAs  Event-Driven Architectures  so I tend to do something like the following  oversimplified version   var Service   function Service  rootScope        var  scope    rootScope  new this        scope that            scope  watch  that   thatObserver  true       function thatObserver what             scope  broadcast  that changed   what             Then  I put a listener in my controller on the desired channel and just keep my local scope up to date this way  In conclusion  there s not much of a  quot Best Practice quot  -- rather  its mostly preference -- as long as you re keeping things SOLID and employing weak coupling  The reason I would advocate the latter code is because EDAs have the lowest coupling feasible by nature  And if you aren t too concerned about this fact  let us avoid working on the same project together  Hope this helps

User · Answer

Building on the examples above I thought I d throw in a way of transparently binding a controller variable to a service variable   In the example below changes to the Controller  scope count variable will automatically be reflected in the Service count variable   In production we re actually using the this binding to update an id on a service which then asynchronously fetches data and updates its service vars  Further binding that means that controllers automagically get updated when the service updates itself   The code below can be seen working at http   jsfiddle net xuUHS 163   View     lt div ng-controller  ServiceCtrl  gt       lt p gt  This is my countService variable     count   lt  p gt       lt input type  number  ng-model  count  gt       lt p gt  This is my updated after click variable     countS   lt  p gt        lt button ng-click  clickC     gt Controller     lt  button gt       lt button ng-click  chkC     gt Check Controller Count lt  button gt       lt  br gt        lt button ng-click  clickS     gt Service     lt  button gt       lt button ng-click  chkS     gt Check Service Count lt  button gt   lt  div gt    Service Controller    var app   angular module  myApp         app service  testService   function        var count   10       function incrementCount           count          return count              function getCount     return count         return           get count     return count            set count val                count   val                     getCount  getCount          incrementCount  incrementCount             function ServiceCtrl  scope  testService         Object defineProperty  scope   count             get  function     return testService count             set  function val    testService count   val                   scope clickC   function              scope count                scope chkC   function              alert  scope count                scope clickS   function               testService count              scope chkS   function              alert testService count

User · Answer

Consider some pros and cons of the second approach    0    lastUpdated   instead of   timerData lastUpdated    which could just as easily be   timer lastUpdated    which I might argue is more readable  but let s not argue    I m giving this point a neutral rating so you decide for yourself   1 It may be convenient that the controller acts as a sort of API for the markup such that if somehow the structure of the data model changes you can  in theory  update the controller s API mappings without touching the html partial   -1 However  theory isn t always practice and I usually find myself having to modify markup and controller logic when changes are called for  anyway  So the extra effort of writing the API negates it s advantage  -1 Furthermore  this approach isn t very DRY  -1 If you want to bind the data to ng-model your code become even less DRY as you have to re-package the  scope scalar values in the controller to make a new REST call  -0 1 There s a tiny performance hit creating extra watcher s   Also  if data properties are attached to the model that don t need to be watched in a particular controller they will create additional overhead for the deep watchers  -1 What if multiple controllers need the same data models  That means that you have multiple API s to update with every model change      scope timerData   Timer data  is starting to sound mighty tempting right about now     Let s dive a little deeper into that last point    What kind of model changes were we talking about  A model on the back-end  server   Or a model which is created and lives only in the front-end  In either case  what is essentially the data mapping API belongs in the front-end service layer   an angular factory or service    Note that your first example--my preference-- doesn t have such an API in the service layer  which is fine because it s simple enough it doesn t need it    In conclusion  everything does not have to be decoupled  And as far as decoupling the markup entirely from the data model  the drawbacks outweigh the advantages     Controllers  in general shouldn t be littered with  scope   injectable data scalar s  Rather  they should be sprinkled with  scope   injectable data s  promise then     s  and  scope complexClickAction   function        s  As an alternative approach to achieve data-decoupling and thus view-encapsulation  the only place that it really makes sense to decouple the view from the model is with a directive  But even there  don t  watch scalar values in the controller or link functions  That won t save time or make the code any more maintainable nor readable  It won t even make testing easier since robust tests in angular usually test the resulting DOM anyway  Rather  in a directive demand your data API in object form  and favor using just the  watchers created by ng-bind     Example http   plnkr co edit MVeU1GKRTN4bqA3h9Yio   lt body ng-app  ServiceNotification  gt       lt div style  border-style dotted  ng-controller  TimerCtrl1  gt          TimerCtrl1 lt br  gt          Bad  lt br  gt          Last Updated    lastUpdated   lt br  gt          Last Updated    calls   lt br  gt          Good  lt br  gt          Last Updated    data lastUpdated   lt br  gt          Last Updated    data calls   lt br  gt       lt  div gt        lt script src  https   ajax googleapis com ajax libs angularjs 1 0 5 angular js  gt  lt  script gt       lt script type  text javascript  gt          var app   angular module  ServiceNotification                 function TimerCtrl1  scope  Timer                 scope data   Timer data               scope lastUpdated   Timer data lastUpdated               scope calls   Timer data calls                      app factory  Timer   function   timeout                var data     lastUpdated  new Date    calls  0                 var updateTimer   function                      data lastUpdated   new Date                    data calls    1                  console log  updateTimer      data lastUpdated                     timeout updateTimer  500                              updateTimer                 return                   data  data                                 lt  script gt   lt  body gt      UPDATE  I ve finally come back to this question to add that I don t think that either approach is  wrong   Originally I had written that Josh David Miller s answer was incorrect  but in retrospect his points are completely valid  especially his point about separation of concerns   Separation of concerns aside  but tangentially related   there s another reason for defensive copying that I failed to consider  This question mostly deals with reading data directly from a service  But what if a developer on your team decides that the controller needs to transform the data in some trivial way before the view displays it   Whether controllers should transform data at all is another discussion   If she doesn t make a copy of the object first she might unwittingly cause regressions in another view component which consumes the same data   What this question really highlights are architectural shortcomings of the typical angular application  and really any JavaScript application   tight coupling of concerns  and object mutability  I have recently become enamored with architecting application with React and immutable data structures  Doing so solves the following two problems wonderfully    Separation of concerns  A component consumes all of it s data via props and has little-to-no reliance on global singletons  such as Angular services   and knows nothing about what happened above it in the view hierarchy  Mutability  All props are immutable which eliminates the risk of unwitting data mutation    Angular 2 0 is now on track to borrow heavily from React to achieve the two points above

[angularjs] AngularJS : The correct way of binding to a service properties

Examples related to angularjs

Examples related to data-binding

Examples related to angularjs-service

Examples related to angularjs-controller