feat(ngDefer): new ngDefer directive to defer compilation until condition is met

[wyrfel]

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
feature

What is the current behavior? (You can also link to an open issue here)
ngNonBindable can halt Angular compilation altogether at a certain point in the
tree. This is a useful optimisation feature.
But even more useful is to delay compilation until a certain condition is met
so that parts of the tree can be compiled only when needed. E.g. content of
pre-loaded popups or complex navigation dropdowns can be compiled only when
they become visible.
There is currently no builtin way to do just that.

What is the new behavior (if this is a feature change)?
This new ngDefer directive halts compilation similar to ngNonBindable, but
registers a watcher on the condition provided to the ngDefer attribute and
will continue compilation once the condition returns a trueish value.

Does this PR introduce a breaking change?
no

Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Fix/Feature: Docs have been added/updated
• Fix/Feature: Tests have been added; existing tests pass

[Narretz]

Hi, interesting PR - but I don't see how this is different from ngIf?

[gkalpak]

Note that since #12078 transluded content is lazily compiled only if/when needed.

[wyrfel]

You're right, after stripping most of our custom stuff for submission here the directives functionality as submitted here is very close to ngIf.

There are however, a few differences:

• ngIf removes and then re-attaches the DOM element from the tree, ngDefer simply stops compilation
• ngIf keeps a persistent watcher whereas ngDefer removes the watcher once the condition is fulfilled
• ngIf creates a new scope, ngDefer doesn't

All of these make for better performance, in particular not modifying the DOM means there is no re-layout event triggered in the browser, which is crucial for fast initial page rendering (in progressive enhancement use-cases).

But looking at it again, it might make more sense to implement this as an extension to ngNonBindable (as in supporting an ngNonBindable attribute value) than as a separate directive?

[Narretz]

1. and 3) are valid points - I think point 2) can be achieved with a one-time binding on the ngIf condition. Even so, we won't add it to core, as I think it's still quite similar to ngIf, which does a fine job in most cases. Progressive enhancement is also not something AngularJS is especially good at, so I assume it's a bit of a rare / power user use case. I still think this could be a nice 3rd party module / directive, though. Actually, it wouldn't surprise me if something like this exists in user-land.