| Age | Commit message (Collapse) | Author |
|
Closes #3759
|
|
How did compiling a templateUrl (async) directive with `replace:true` work before this commit?
1/ apply all directives with higher priority than the templateUrl directive
2/ partially apply the templateUrl directive (create `beforeTemplateNodeLinkFn`)
3/ fetch the template
4/ apply second part of the templateUrl directive on the fetched template
(`afterTemplateNodeLinkFn`)
That is, the templateUrl directive is basically split into two parts (two `nodeLinkFn` functions),
which has to be both applied.
Normally we compose linking functions (`nodeLinkFn`) using continuation - calling the linking
function of a parent element, passing the linking function of the child elements as an argument. The
parent linking function then does:
1/ execute its pre-link functions
2/ call the child elements linking function (traverse)
3/ execute its post-link functions
Now, we have two linking functions for the same DOM element level (because the templateUrl directive
has been split).
There has been multiple issues because of the order of these two linking functions (creating
controller before setting up scope locals, running linking functions before instantiating
controller, etc.). It is easy to fix one use case, but it breaks some other use case. It is hard to
decide what is the "correct" order of these two linking functions as they are essentially on the
same level.
Running them side-by-side screws up pre/post linking functions for the high priority directives
(those executed before the templateUrl directive). It runs post-linking functions before traversing:
```js
beforeTemplateNodeLinkFn(null); // do not travers
afterTemplateNodeLinkFn(afterTemplateChildLinkFn);
```
Composing them (in any order) screws up the order of post-linking functions. We could fix this by
having post-linking functions to execute in reverse order (from the lowest priority to the highest)
which might actually make a sense.
**My solution is to remove this splitting.** This commit removes the `beforeTemplateNodeLinkFn`. The
first run (before we have the template) only schedules fetching the template. The rest (creating
scope locals, instantiating a controller, linking functions, etc) is done when processing the
directive again (in the context of the already fetched template; this is the cloned
`derivedSyncDirective`).
We still need to pass-through the linking functions of the higher priority directives (those
executed before the templateUrl directive), that's why I added `preLinkFns` and `postLinkFns`
arguments to `applyDirectivesToNode`.
This also changes the "$compile transclude should make the result of a transclusion available to the
parent directive in post- linking phase (templateUrl)" unit test. It was testing that a parent
directive can see the content of transclusion in its pre-link function. That is IMHO wrong (as the
`ngTransclude` directive inserts the translusion in its linking function). This test was only passing because of
c173ca412878d537b18df01f39e400ea48a4b398, which changed the behavior of the compiler to traverse
before executing the parent linking function. That was wrong and also caused the #3792 issue, which
this change fixes.
Closes #3792
Closes #3923
Closes #3935
Closes #3927
|
|
Some of node dependencies have much newer versions; one of them is Lo-Dash
that has recently released the 2.0.0 version bringing in new useful methods.
|
|
Previous version stated `replace:false` will append template to element.
Improve description to accurately state that template will _replace_ the
contents of the current element.
Closes #2235, #4166
|
|
Closes #4179
|
|
reloadOnSearch also affects reloads due to $location.hash() changes
|
|
Closes #4186
|
|
Closes #4154
|
|
In the Android browser, the BFCache maintains
the state of JavaScript applications even when
navigating to another app, so that going
forward and back, to and from an application
is very fast.
Unfortunately, this can have undesired side
effects. In this instance, the location
variable was holding a reference to a stale
window.location, and was throwing errors
when going back to an Angular app after
browsing to another site.
This fix makes sure that location.url()
includes a check to make sure that location
is referencing the current window.location.
Closes #4044
|
|
|
|
animations are in use
Closes #3933
|
|
ngDoc did not add default value to template, even though it was present
in the documentation. This change adds the default value to the
description column in the parameters table.
Closes #3950
|
|
Closes #4183
|
|
The original example is by gxlcl.
Closes #4180
|
|
Closes #4188
|
|
Closes #1705
|
|
This is specified for input fields, but not for selects. This change specifies it also for select().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
jqLite previously used `elt.className` to add and remove classes from a DOM Node, but
because the className property is not writable on SVG elements, it doesn't work with
them. This patch replaces accesses to `className` with `get/setAttribute`.
`classList` was also considered as a solution, but because only IE10+ supports it, we
have to wait. :'(
The JqLiteAddClass/JQLiteRemoveClass methods are now also used directly by $animate
to work around the jQuery not being able to handle class modifications on SVG elements.
Closes #3858
|
|
|
|
The problem was in keeping the values of `attrNameStart` and `attrNameEnd` between directive loop iterations which lead to the compiler looking for multi-element ranges for any directives that happened to be in the directive list after one that was applied on a range. For instance, having a ng-repeat-start and ng-class on a single element with ng-repeat being resolved first made the compiler look for an ng-repeat-end for both ng-repeat and ng-class because the `attrNameEnd` was not reset to a falsy value before the second iteration. As the result, an exception saying the block end element could not be found and the second directive was not actually applied.
Closes #4002
|
|
|
|
|
|
Closes #4172, #4170
|
|
closes
Closes #4028
|
|
|
|
|
|
jQuery 1.10.2 does not attach data to comment nodes, which previously broke `$compile`.
This changes how elements with "transclude element" and a controller are compiled to
avoid the issue.
Closes #3764
|
|
Closes #4114
|
|
Closes #4112
|
|
Closes #4106
|
|
Closes #4105
|
|
Closes #4104
|
|
Clean up confusing use of the term URL to refer to $location as well as 'URL in the browser'.
Closes #4103
|
|
Initially, `$httpProvider.defaults.headers.get` is `undefined`, so
`$httpProvider.defaults.headers.get['My-Header']='value'` will throw an
error.
Closes #4101
|
|
Closes #4100
|
|
Closes #4099
|
|
initially undefined
Previously if the collection model was set to undefined on the first digest,
the repeater would get confused and not use the correct tracking function
for associating model with dom elements in the repeater.
Closes #4145
Closes #3964
|
|
|
|
Provides a performance improvement when serializing to JSON strings.
Closes #4093
|
|
Ref: https://github.com/angular/angular.dart/blob/master/test/directives/ng_non_bindable_spec.dart
|
|
Ref: https://github.com/angular/angular.js/pull/4045
I have this sinking feeling that support this use case sort of
encourages binding to function that blindly trust some html. For now,
I'm fixing the issue while I think about the use cases some more.
In the case of a function that performs any non-trivial work before
wrapping the value (e.g. the showdown filter in issue #3980, or the
binding to a simply wrapper function in issue #3932 if it did anything
meaty), this fix makes it "work" - but performance is going to suck -
you should bind to some other thing on scope that watches the actual
source and adjusts itself when that changes (e.g. the showdown filter.)
For the case of the wrapper in #3932, if one isn't performing
sanitization or some such thing - then you the developer has insight
into why that value is safe in that particular context - and it should
be available simply by name and not as a result of a function taking any
arbitrary input to make auditing of security a little saner.
Closes #3932, #3980
|