Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <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>
    singulars
    1. This table or related slice is empty.
    1. POIs binding objects to angular's $rootScope in a service bad?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USbmleite
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COI have to disagree. You said "if you want to share anything application-wide, [`$rootScope` is] the perfect place to put it". No, that's what *services* are for. Not all scopes inherit from each other, but all inherit from `$rootScope`. The "problem" may already be there, but it's certainly not *amplified* to the degree to which you and the OP are suggesting. Further, calculating "c" every time "a" or "b" changes is totally unnecessary - some views may need that (in which case it can easily occur) but most only need to recalculate "c" when they need it. Bad architecture, bad performance.
      singulars
      1. PO
      1. USJosh David Miller
    2. CO@JoshDavidMiller I understand your point of view, but all solutions have their own drawbacks. For example, your solution is based on the fact that `a` and `b` will be changing lots of times, but have you though on the opposite scenario? Imagine that you don't change `a` and `b` at all but you access `c` 30 times in 30 different places of the app, in that case you will be calculating `c` 29 times more than necessary. And why do you assume that everything that goes into the `$rootScope` is bad? If it's a model (despite being hold by a service) why don't share it on the scope?
      singulars
      1. PO
      1. USbmleite
    3. COLet me just clarify 2 other things. Fist, child scopes do inherit properties from their parent scopes (and all the way up to the `$rootScope`). That's the all idea of prototypical inheritance (as explained [here](http://docs.angularjs.org/guide/scope)). Second, I'm not saying that one approach is better than the other, I'm just showing what @latentflip should be aware of when choosing any of the approaches.
      singulars
      1. PO
      1. USbmleite
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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