Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I must admit, the first time I read your question and saw your example I thought to myself <em>"this is just wrong"</em>, however, after looking into it again I realized it wasn't so bad as I thought it would be. </p> <p>Let's face the facts, the <code>$rootScope</code> is there to be used, if you want to share anything application-wide, that's the perfect place to put it. Of course you will need to careful, it's something that's being shared between all the scopes so you don't want to inadvertently change it. But let's face it, that's not the real problem, you already have to be careful when using nested controllers (because child scopes inherit parent scope properties) and non-isolated scope directives. The 'problem' is already there and we shouldn't use it as an excuse not follow this approach.</p> <p>Using <code>$watch</code> also seems to be a good idea. It's something that the framework already provides you for free and does exactly what you need. So, why reinventing the wheel? The idea is basically the same as an 'change' event approach.</p> <p>On a performance level, your approach can be in fact 'heavy', however it will always depend on the frequency you update the <code>a</code> and <code>b</code> properties. For example, if you set <code>a</code> or <code>b</code> as the <code>ng-model</code> of an input box (like on your jsbin example), <code>c</code> will be re-calculated every time the user types something... that's clearly over-processing. If you use a soft approach and update <code>a</code> and/or <code>b</code> solely when necessary, then you shouldn't have performance problems. It would be the same as re-calculate <code>c</code> using 'change' events or a setter&amp;getter approach. However, if you really need to re-calculate <code>c</code> on real-time (i.e: while the user is typing) the performance problem will always be there and is not the fact that you are using <code>$rootScope</code> or <code>$watch</code> that will help improve it.</p> <p>Resuming, <strong>in my opinion</strong>, your approach is not bad (at all!), just be careful with the <code>$rootScope</code> properties and avoid ´real-time´ processing.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload