Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

not parsing expressions in attributes, select with ng-options Angular 1.2.0.rc3 #4511

Closed
ygorcardoso opened this Issue · 7 comments

5 participants

@ygorcardoso

Hi guys,

I had a few dropdows that were working fine in my project until rc2, but rc3 broke them.

Some dynamic attributes I have are not being parsed at all, like for example, id="something{{$index}}; the same attributes in other input types or dropdowns without ng-options are parsed just fine.

Here's a fiddle exemplifying the problem: http://jsfiddle.net/S6vz7/1/, you can notice the difference when you hover selects or inputs.

Regards,
Ygor

@heikki

I noticed the same thing with select & id attribute.

@ygorcardoso

It seems to be related to 31f190d, but not sure what's the best way to get around it.

@ygorcardoso ygorcardoso referenced this issue from a commit
@IgorMinar IgorMinar fix($compile): fix (reverse) directive postLink fn execution order
previously the compile/link fns executed in this order controlled via priority:

- CompilePriorityHigh, CompilePriorityMedium, CompilePriorityLow
- PreLinkPriorityHigh, PreLinkPriorityMedium, PreLinkPriorityLow
- link children
- PostLinkPriorityHigh, PostLinkPriorityMedium, PostLinkPriorityLow

This was changed to:

- CompilePriorityHigh, CompilePriorityMedium, CompilePriorityLow
- PreLinkPriorityHigh, PreLinkPriorityMedium, PreLinkPriorityLow
- link children
- PostLinkPriorityLow, PostLinkPriorityMedium , PostLinkPriorityHigh

Using this order the child transclusion directive that gets replaced
onto the current element get executed correctly (see issue #3558),
and more generally, the order of execution of post linking function
makes more sense. The incorrect order was an oversight that has
gone unnoticed for many suns and moons.

(FYI: postLink functions are the default linking functions)

BREAKING CHANGE: the order of postLink fn is now mirror opposite of
the order in which corresponding preLinking and compile functions
execute.

Very few directives in practice rely on order of postLinking function
(unlike on the order of compile functions), so in the rare case
of this change affecting an existing directive, it might be necessary
to convert it to a preLinking function or give it negative priority
(look at the diff of this commit to see how an internal attribute
interpolation directive was adjusted).

Closes #3558
31f190d
@astik

Here are some results of what I have found :

Suppose that "directive" is our own directive which access attribute that needs to be interpolated.
Its priority is default (0).

Here is a sample HTML :

<select
    data-ng-model="woot"
    data-ng-options="str as str for str in awesomeThings"
    data-directive1
    data-my-param="{{testObject.param1}}"
></select>

We have 4 declared directives : select, ngModel, ngOptions, directive1.
Angular add an implicit directive : interpolation directive.

Directives are loaded from highest priority to lower.

In RC2 :

function applyDirectivesToNode(directives, compileNode, templateAttrs, transcludeFn, jqCollection, originalReplaceDirective) {

directives contains those 5 objects :

0   Object { priority=100, compile=function()}                     - interpolation directive
1   Object { restrict="E", require=[2], controller=[4], more...}   - select directive
2   Object { restrict="A", priority=0, name="directive1", more...} - directive1 directive
3   Object { terminal=true, priority=0, name="ngOptions", more...} - ngOptions directive
4   Object { require=[2], controller=[6], priority=0, more...}     - ngModel directive

In RC3 :

function applyDirectivesToNode(directives, compileNode, templateAttrs, transcludeFn, jqCollection, originalReplaceDirective, preLinkFns, postLinkFns, previousCompileContext) {

directives contains those 5 objects :

0   Object { restrict="A", priority=0, index=0, more...}         - directive1 directive
1   Object { require=[2], controller=[6], priority=0, more...}   - ngModel directive
2   Object { terminal=true, priority=0, index=0, more...}        - ngOptions        terminal:true
3   Object { restrict="E", require=[2], controller=[4], more...} - select directive
4   Object { priority=-100, compile=function()}                  - interpolation directive

The interpolation directive has its priority changed from 100 (in RC2) to -100 (in RC3).
It used to be first in line, now it is last.

The terminal property does not mean that the directive is the final one, it means that its priority will be the lowest possible one for the current element.

if (terminalPriority > directive.priority) {
    break; // prevent further processing of directives
}

As the ngOptions directive is terminal, the lowest priority possible is set to 0.
The "interpolation directive" has a priority of -100 and is not loaded.
So that, attrInterpolateLinkFn is not available into postLinkFns and is not triggered.

@jamie-pate

so.. select directive priority should be -101.. :)

@rodyhaddad
Collaborator

Test your jsfiddle (it's already using the latest snapshot). It works now :)

Gotta thank 79223ea

@ygorcardoso

Yeah, noticed it too, nice to see the problem is not forgotten :)

@ygorcardoso ygorcardoso closed this
@ygorcardoso

Closed the issue as it's working in 1.2 release.

@darul75 darul75 referenced this issue in darul75/angular-awesome-slider
Closed

Dynamic ID #21

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.