onload for ng:view

[vojtajina]

Same as ng:include - execute after content is compiled...

[IgorMinar]

We need a better solution than onload. The onload fn often needs to access
the element and do dom manipulation. This is the kind of stuff that that
doesn't belong to the container where ng-include's onload fn is typically
defined.

It would be great if we could somehow move this responsibility to a
directive, but for that the directive would have to be notified about the
state changes in ng-view and ng-include. The notification could be done via
scope or dom events. Thoughts?

[vojtajina]

With new compiler, we have pre/post link, right ? So if understand it correctly, a directive can registers a post link fn...

[IgorMinar]

Post link fn is good for directives with a single template. Both ng-view
and ng-include are special in that they compile templates dynamically
whenever the source url changes. So post link fn won't help here.

[vojtajina]

Yep. Well then, we ng:include/ng:view might fire and event on scope...

[ThomasBurleson]

May I participate here ? :-)

@igor,
RE> the onload fn often needs access to do DOM manipulation.
I am guilty of that exact usage. The improvement was to move that load DOM action to a generic ng:onLoad directive.

So [PostLink] fn would be great, I think.

Why not use the pre/post link fn whenever the source url changes?
Why not also support the onLoad for ng-view AND ng-include (as easy fallback method)?

[IgorMinar]

On Mon, Feb 6, 2012 at 4:21 AM, Thomas Burleson <
reply@reply.github.com

wrote:

May I participate here ? :-)

absolutely!

@igor,
RE> the onload fn often needs access to do DOM manipulation.
I am guilty of that exact usage. The improvement was to move it to a
generic ng:onLoad directive.

are you referring to this: https://gist.github.com/1751792 ?

I see two problems there:

1. you still force the developer to do dom manipulation from the controller
2. this will not work with the new compiler that we have because the
   ng-include and ng-view directives will trigger the linking fn only once,
   when the template is first compiled. In other words, the linking fn won't
   be called when the template changes.

So [PostLink] fn would be great, I think.

Why not use the pre/post link fn whenever the source url changes?

the post link fn Vojta mention is part of the api of the new html compiler
that has not been released yet. the post link fn or the compiler doesn't
know anything about when/how the ng-view or ng-include template changes so
I don't think that it could be used for this purpose.

Why not also support the onLoad for ng-view AND ng-include (as easy
fallback method)?

as I originally stated, this forces the developers to do dom manipulation
from the controller which is inherently untestable. I think that adding
support for ng-include's onload was a mistake. We must come up with a
better solution.

[ThomasBurleson]

I understand (and agree) with the axiom that "Controllers should not directly manipulate views... except via databinding and expressions". The issue here is that the views should not be considered static or CRUD GUIs. Views are [usually] much more dynamic. Some layer is needed to transform static layout to rich layout while conformant to MVVM and delegation solutions.

This same issue, btw, exists in Flex and Flash architectures.

What the Flex dev team created was a concepts of "state, state management, and transitions". State was a representative of layout and content. Custom states extend base states with element modifications/adds/deletes, skin changes, layout changes, interaction changes. Transitions could be attached to changes of state. Really powerful.

This is what needs to be added to Angular: state management overlayed on partials. State changes could be triggered via Controller values/expressions. Transitions could be programmatic or CSS3.

I have been thinking about this a lot lately... once I am more acclimated to AngularJS, I would be interested in implementing this for the AngularJS team.

[vojtajina]

@IgorMinar I got it and agree.
So the best solution I can think of now is ng:view and ng:include fire scope events (after the content is compiled and linked). Then, both controllers/directives can listen on this event.
For example implementation of onload directive would be just simply listening on scope event and evaluating the expression...
Better ideas ?

@ThomasBurleson I'm not that much familiar with Flex, but it sounds like you might have a "state" object on scope (this object would hold multiple information for template) and you could exchange the whole state object.
Very trivial example: http://jsfiddle.net/vojtajina/n4Bpa/