Fix merging of two ngIfs in replace mode.

[kubawalinski]

I noticed an error while working with ngIf in my project. It is reproduced here: http://codepen.io/kubawalinski/pen/EaWjxe?editors=101. In short, when 2 ngIfs need to be merged the merge is done incorrectly (it just concatenates the conditions with a space character). This is an attempt to fix this by concatenating with the ' && ' string, so that both conditions are checked and both need to be true for the ngIf to kick in.

[lgalfaso]

I do not know if I want to go this route... if we start adding special rules for every directive, then sooner or later we will end up with too many rules on how attributes should be merged

[kubawalinski]

Do you have any other idea for fixing this issue?

[kubawalinski]

The way I see it ngIf is a special directive when it comes to merging its conditions and as such it should be treated differently in the code. How else can we get this working correctly?

[realityking]

Wouldn't the same be true for ngHide and ngShow?

[kubawalinski]

@realityking You're absolutely right, ngShow, ngHide and also ngDisabled, ngOpen. Probably some others too, but this is what I gather from a quick look at the list of built-in directives. Basically it would affect any directive with a boolean condition. Anybody recalls other such directives apart from the ones already mentioned above?

I would be happy to add all identified directives to the fix, but first I would like the community to help me find the best solution to this problem.

[btford]

Agree with @lgalfaso. Also it should be noted that we recommend against using the replace option.

[lgalfaso]

Angular has its limitations whenever there are multiple directives in the
same element, and the use of replace: true makes these limitations easy to
spot. In this specific case, we cannot merge the ngif statements as that is
not the right behavior. If you only keep the outer ngif, then every time
the expression turns to true, then a new controller for the custom
directive is created. If you only keep the inner ngif, then even when the
expression changes, the same controller is kept. The reason being very
simple, the outer ngif controls the creations of the custom directive and
the inner ngif only exists when the custom directive is present. This makes
it easy to understand that merging is not the right solution.

There are other directives that also have issues getting merged, an
example that very hard to know what to do is ng-class.

These are some of the reasons why replace: true is deprecated (and its use
discouraged).

I am sorry that you are running into this issue, but there is currently no
way to make it work both ways (this is one expression controlling the
creation of the custom directive controller and not the other). To make
this compile, you will have to think what behavior you want, and expose the
outer expression inside the directive or the inner expression outside of it.

[kubawalinski]

@lgalfaso Thanks for this in-depth explanation. I did not know that replace was deprecated. This decision makes a lot of sense now that you have laid it out so clearly.

My example (http://codepen.io/kubawalinski/pen/EaWjxe?editors=101) was deliberately simplified, but in real life the situation that I encountered was that I was using somebody else's directive from npm and I wanted to use ngIf on it, but it failed due to the fact that there was an inner ngIf on a root element inside that directive.

I guess the way forward in such situations is to use ngShow if a directive uses ngIf and vice versa. It's not ideal, as I know some developers like to control their resulting markup pretty tightly. However, I see no other way around such an issue at this time. Would you guys agree?

[lgalfaso]

The use of ngIf and ngShow combination is a solution. BTW (and I know you
are using a third party component), using an ngIf outside and ngShow inside
works best.

[gkalpak]

BTW, (if your usecase allows it), you could wrap the directive in a parent element and put ngIf on that.

[lgalfaso]

BTW, (if your usecase allows it), you could wrap the directive in a parent element and put ngIf on that.

Please do not do this. If this in fact works, then it is an oversight and may break in the future.

I am closing this issue now

[gkalpak]

Hm...it does indeed work, but why is it an oversight ? Why do you say it shouldn't work ?

Just to make sure we are on the same page, I am talking about something like this:

HTML

<div ng-if="expr1">
  <test show="expr2"></test>
<div>

JS

.directive('test', function testDirective() {
  return {
    template: '<span ng-if="show">Hello, world !</span>',
    scope: {show: '='},
    replace: true
  };
}

Demo fiddle

So, @lgalfaso, are you saying the above shouldn't be done (and might break in the future) ? Why is that ?
(There is a good chance I am missing something, so thx for any insights into this :))

[lgalfaso]

@gkalpak I thought you meant that if in the outer element you have an attribute named ngIf (not ng-if, but ngIf) then the ngIf directive would get called anyhow and the attributes not merged

[gkalpak]

I always refer to directives by their normalized named 😃
Sorry, for the confusion :)