Hi Steward, > Keep in mind too that the DOM will be changing every time the collection > changes, so you will have to destroy/recreate stuff every time that happens. > your `coolCustomDirectiveThatFiresAfterNgRepeatIsDone` will work, but why > would you like to do something like that? I know the DOM changes, but the > underlying data is readily available in your models. The only reason I see > for a thing like that, is that you have to do DOM manipulation on the > created result. That might be needed, but wouldn't it be a better solution > to fix whatever there is inside the repeat, so this isn't needed at all? > Now you are adding ate least the row-count of extra watchers to your view. > To take your example, if for instance you want to sum the oranges, just > use a function to sum the data. > I updated your plunk <http://plnkr.co/edit/EECAGr514FsaftZfAlij?p=preview> a > bit to showcase this. > Can you show me an actual use of a > `coolCustomDirectiveThatFiresAfterNgRepeatIsDone` construct that isn't > patching up misbehavior of repeated elements or doing calculations on data > that already exists in your controller? > Regards
I provided the directive as an example of a way to notify the controller ( which is using a 3rd party library ) that the ng-repeat has completed rendering the elements of it's collection. I don't know why OP wanted that or what exactly it is doing, but that's why I posted it. It can be useful if the 3rd party JS is written in jQuery and thus has no access to your scope or data. I think he is using a 3rd party lib that fits that exact description. Otherwise I would agree with what you say, generally speaking you could address whatever you needed via directives/templating and good controller design. Now you are adding ate least the row-count of extra watchers to your view. That's a good point, but this was a quick example that I made in 5 minutes. You could also examine $scope.$last in $link, which would not add watchers and complicate your digest cycle unnecessarily. On Wed, Aug 5, 2015 at 10:07 PM, Sander Elias <[email protected]> wrote: > Hi Steward, > > > Keep in mind too that the DOM will be changing every time the collection >> changes, so you will have to destroy/recreate stuff every time that happens. >> > > your `coolCustomDirectiveThatFiresAfterNgRepeatIsDone` will work, but why > would you like to do something like that? I know the DOM changes, but the > underlying data is readily available in your models. The only reason I see > for a thing like that, is that you have to do DOM manipulation on the > created result. That might be needed, but wouldn't it be a better solution > to fix whatever there is inside the repeat, so this isn't needed at all? > Now you are adding ate least the row-count of extra watchers to your view. > To take your example, if for instance you want to sum the oranges, just > use a function to sum the data. > I updated your plunk <http://plnkr.co/edit/EECAGr514FsaftZfAlij?p=preview> > a bit to showcase this. > > Can you show me an actual use of a > `coolCustomDirectiveThatFiresAfterNgRepeatIsDone` construct that isn't > patching up misbehavior of repeated elements or doing calculations on data > that already exists in your controller? > > Regards > Sander > > > -- > You received this message because you are subscribed to the Google Groups > "AngularJS" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/angular. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
