Feature request: a way to detect if Angular finished rendering of HTML DOM

[kstep]

We often need to do some operations on DOM nodes, e.g. bind custom events to them (like "mouseover", "click" or "dblclick"), but Angular changes DOM eventually at the end of digest cycle.

What we need is a way to bind some handler upon DOM modification by Angular is finished and it's safe to handle DOM elements (so they won't disappear next moment). From what I understand ng:init runs only once per node on first document rendering and doesn't guarantee any surrounding nodes are rendered.

Is there a way to set a hook to run on end of digest cycle after all DOM nodes are rendered, so it's safe to go on with DOM operations?

[IgorMinar]

Why isn't creating directives sufficient to bind these events? The thing is that the compilation is a continuous process in angular, if you don't use directives, you are bypassing the compiler and then you run the issue of not knowing when things are ready.

If I'm missing something (which I may be!), can you create a simple jsfiddle demonstrating your use case?

[mhevery]

I think you are looking for this:
http://docs-next.angularjs.org/api/angular.module.ng.$rootScope.Scope#$evalAsync

2012/1/25 Konstantin Stepanov <
reply@reply.github.com

We often need to do some operations on DOM nodes, e.g. bind custom events
to them (like "mouseover", "click" or "dblclick"), but Angular changes DOM
eventually at the end of digest cycle.

What we need is a way to bind some handler upon DOM modification by
Angular is finished and it's safe to handle DOM elements (so they won't
disappear next moment). From what I understand ng:init runs only once per
node on first document rendering and doesn't guarantee any surrounding
nodes are rendered.

Is there a way to set a hook to run on end of digest cycle after all DOM
nodes are rendered, so it's safe to go on with DOM operations?

---

Reply to this email directly or view it on GitHub:
#734

[kstep]

$evalAsync looks interesting, but not exactly what we want. According to docs it evaluates expression before any DOM rendering is done and after a digest cycle is finished. What we want is to run some code after both digest cycle is finished and DOM rendering is done.

Either I or my colleague will provide you an example tomorrow, I'm too tired for today and my colleague is not available at the moment either.

[kstep]

Quick example: we load some partial with <ng:view/>, then this partial is rendered (e.g. a lot of ng:repeat's and other ng:bind stuff is evaluated), and as the result of this (potentially long) process DOM becomes stable (I guess after the end of digest cycle), so it's safe to apply some special effects to it, like drag-n-drop handling, fading in/out, custom event handlers binding, applying some jQuery plugins effects like Masonry, LazyLoad (to load images in a lazy fashion), or run Facebook handlers (it's a real problem for us, as Facebook XFBML parser requires already existing fb:* DOM nodes, which is difficult to guarantee with asynchronous DOM rendering).

For now we use $browser.defer() here and there, but it's a very bad thing, we'd prefer more robust and correct way to do it.

[mhevery]

The asyncEval is after the DOM construction but before the browser renders.
I believe that is the time you want to attach the jquery plugins. otherwise
you will have flicker. if you really want to do after the browser render
you can do $defer(fn, 0);

2012/1/25 Konstantin Stepanov <
reply@reply.github.com

Quick example: we load some partial with ng:view/, then this partial is
rendered (e.g. a lot of ng:repeat's and other ng:bind stuff is evaluated),
and as the result of these (potentially long) process DOM becomes stable (I
guess after the end of digest cycle), so it's same to apply some special
effects to it, like drag-n-drop handling, fading in/out, custom event
handlers binding, applying some jQuery plugins effects like Masonry,
LazyLoad (to load images in a lazy fashion), or run Facebook handlers (it's
a real problem for us, as Facebook XFBML parser requires already existing
fb:* DOM nodes, which is difficult to guarantee with asynchronous DOM
rendering).

For now we use $browser.defer() here and there, but it's a very bad thing,
we'd prefer more robust and correct way to do it.

---

Reply to this email directly or view it on GitHub:
#734 (comment)

[kstep]

Hmm... I looked through code and what I found out, $evalAsync just queues code for execution, and then it's executed in $digest, but there in $digest first execution queue (filled with $evalAsync) is run, and then watchers are evaluated. And all widgets/directives use $watch to update DOM nodes. So if I get it correctly, my $evalAsync()ed code run before DOM manipulations, and thus I have no guarantee my DOM tree won't be modified just after my $evalAsync()ed function executed.

Am I missing something?

I feel like I need something like additional execution queue to run after the main $digest loop is done it's work. Of cause I will have to guarantee my code in the queue won't change DOM lest $digest must be run again.

[mhevery]

if you enqueue from controller then it will be before, but if you enqueue
from directive then it will be after.

The issue is that most frameworks have a string template which then gets
rendered into a string which then gets innerHTML. In such a world it is
very clear where the beggining and end of render is.

With angular that is not the case. Since angular has concept of directives,
a directive may unroll a loop, which can the instantiate a controller,
which can than modify the model which then causes more DOM updates. This
makes it hard to have clear line in a send as to where the DOM update
begins and ends.

So in order for us to help you, what is the specific problem which you are
trying to solve? If you just want to apply special animations to do, then
those animations need to be triggered from within directives, in which case
the $asyncEval is exactly what you want as the current DOM update has
become stable.

-- Misko

2012/1/26 Konstantin Stepanov <
reply@reply.github.com

Hmm... I looked through code and what I found out, $evalAsync just queues
code for execution, and then it's executed in $digest, but there in $digest
first execution queue (filled with $evalAsync) is run, and then watchers
are evaluated. And all widgets/directives use $watch to update DOM nodes.
So if I get it correctly, my $evalAsync()ed code run before DOM
manipulations, and thus I have no guarantee my DOM tree won't be modified
just after my $evalAsync()ed function executed.

---

Reply to this email directly or view it on GitHub:
#734 (comment)

[IgorMinar]

we now have $viewContentLoaded and $includeContentLoaded events that are emitted in ng-view and ng-include respectively. I think this is as close as one can get to knowing when we are done with the compilation.

[eprouver]

I think I have the same problem. When using a directive that contains another directive (ng-repeat) the higher level doesn't seem to wait until the entire DOM is created, and the async eval is evaluated before all of the DOM is present.

Could you suggest a good time to bind jQuery events? In the example I'm using jQuery UI draggable.

http://jsfiddle.net/eprouver/WpZZE/4/

[paramburu]

I'm also having problems to detect when the ngView has ended rendering. The task need to get the ngView "container"s height but when the event $viewContentLoaded triggers, height is still 0. What should I do? I'll appreciate a little help.

[kstep]

Have you tried using $timeout() to schedule your code execution in $viewContentLoaded event handler? Or evalAsync()?

[kstep]

@eprouver try this out http://jsfiddle.net/WpZZE/5/

[eprouver]

Thanks for responding: With local data $timeout seemed to work. I believe I started running into this problem when loading outside content. Here is a simple example that fails similarly: http://jsfiddle.net/eprouver/WpZZE/6/

[kstep]

@eprouver
How about creating my-draggable directive instead?
http://jsfiddle.net/gXSLb/1/
I consider this is most clean and angularish way of doing what you want.