All promise resolves (e.g., then() and catch()) end up getting resolved asynchronously. Even promises that don't themselves do anything asynchronous (as in, they return a value rather than a promise to a value) end up executing asynchronously, as I understand the code.
However, angular is already pretty good at two-way data binding. You can do a $scope.$watch in the child controller to look for updates on the data if it's in a known location. So if the child has a $watch on the data itself, it'll get notified when the data changes. On the other hand, if the directives actually displaying the data are correctly angularized, they should re-flow themselves if the data that drives their layout changes (e.g., you don't have to broadcast events at all to add rows to a table if you're using ng-repeat). On Sun Nov 23 2014 at 10:12:10 AM Al J <[email protected]> wrote: > ok, >> > > I learned how to write a promise to make this work > > but that promise has an embedded setTimeout() since it doesn't depend on > any .ajax or something else that generates a promise > > is setTimeout the only way (for now) to yield() ? > > I understand that when EC6 gets here we'll have a yield keyword > > does that mean that _all_ promises, at some level, do a setTimeout ? > > > -- > 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.
