ngShowIf (Feature Request)

[Izhaki]

Abstract

If is often desirable to insert a directive's content upon first usage, and show/hide thereafter.

That is, have an ngIf behaviour once, and ngShow behaviour thereafter.

Current state of affairs

The two directives in question are:

• ngIf - the directive inserts/removes the contents from the DOM. The directive also creates a new child scope upon each insertion (unfavourable behaviour at times, as it forces outside/inside communication to be based on objects, rather than primitives).
• ngShow - the directive simply shows or hides the contents. It does not affect the scope.

The request

It would be useful to have a directive that inserts the contents first time its value turns true, and following that simply hides and show it.

Example

Consider a typeahead directive on an input field:

<input typeahead="...">

The directive reveals a dropdown with options and search matches, like so:

The initiation of the dropdown may be time-consuming and its existence on the DOM performance-consuming. The dropdown may:

• Require an AJAX call to obtain the options (in case of remote search).
• Involve watches.
• Have to sort the returned options.
• Each item (and depending on the programmer, there may be hundreds of them):
  • Require DOM listeners (eg, mousedown).
  • Involve a watch (eg, selected).

On a single form, there may be 10 fields with such typeahead directives. And the user may or may not open the dropdowns. When the form represents a new entry, the dropdowns are likely to be opened; but when editing/reviewing an entry, very few (if any) dropdowns will be open.

And so if one chooses:

• ngIf - quite a bit of work will have to be done every time a dropdown opens (think AJAX requests); and due to the child scope, one has to take some extra step to ensure state preservation (eg, the query that was entered).
• ngShow - we do a lot of work (10 typeaheds X 10 AJAX calls and many listeners and watches), which may not be needed at all.

A directive that inserts on the first show but show/hide thereafter would solve this.

Code

ngIfShow

Here's a code for and ngIfShow directive, essentially a slimed-down marrige between ngIf and ngShow. As it uses transclude the inside scope is a sibling scope (which quite a few people aren't happy with).

.directive( 'ngIfShow', ['$animate', function($animate) {
  return {
    multiElement: true,
    transclude: 'element',
    priority: 600,
    terminal: true,
    restrict: 'A',
    link: function (scope, element, attr, ctrl, transclude) {
        var rendered = false,
            iClone;
        scope.$watch(attr.ngIfShow, function ngIfShowWatchAction(value) {

          if (!rendered){
            if (value) {
              transclude(function (clone, newScope) {
                iClone = clone;
                clone[clone.length++] = document.createComment(' end ngIfShow: ' + attr.ngIfShow + ' ');

                $animate.enter(clone, element.parent(), element);
                rendered = true;
              });
            }
          } else {
            $animate[value ? 'removeClass' : 'addClass'](iClone, 'ng-hide');
          }
        });
    }
  };
}])

ngShowIf

The following directive does the same thing, but behaves more like ngShow in that it does not affect the scope:

.directive( 'ngShowIf', [ '$compile', '$animate', function( $compile, $animate ) {
    return {
        priority: 600,
        terminal: true,
        restrict: 'A',

        compile: function compile( tElement, tAttributes ) {
            var iContents = tElement.html();
            tElement.empty();

            return function postLink( scope, element, attrs, controller ) {
                var iClone = false;

                scope.$watch( attrs.ngShowIf, function ngShowIfWatchAction( doShow ) {
                    if ( !iClone ) {
                        if ( doShow ) {
                            iClone = $compile( iContents )( scope );
                            $animate.enter( iClone, element );
                        }
                    } else {
                        $animate[ doShow ? 'removeClass' : 'addClass']( iClone, 'ng-hide' );
                    }

                });
            };

        }
    };
}])

[thinkingmedia]

I think you could achieve something like this already.

For example;

 <div ng-if="(rule && !foo && foo = rule) || foo" ng-class="{show:rule}">...</div>

rule is the condition, and foo is an undefined variable. As soon as rule becomes true then foo is assigned true and remains true. A CSS class show is used to toggle display.

[lgalfaso]

In the 1.3 branch, it can be done using one-time binding

<!-- untested code -->
<div ng-if=":: foo ? true : undefined" ng-show="foo">...</div>

[Izhaki]

Thank you both!

Indeed, both suggestions will work. A few things to consider though:

• Neither solves ngIfs scope behaviour.
• Both involve some less-than-straight-forward, somewhat verbose syntax.
• Although probably a matter of style, I'm not a great fan of including anything other than the most elementary logic within the HTML markup. I believe logic should be encapsulated within a directive's javascript code.

I honestly don't know how popular a directive such as ngShowIf will be, and I assume it would to directive writers more than to directive users. But I have a hunch that many directives do carry some performance/initiation overhead and the behaviour proposed will help many.

[lgalfaso]

@Izhaki I do not want to disappoint you, but as posted the directive would not work as expected. The first implementation is not aware of -start, -end. The second implementation does not behave as an ng-if and ng-show as what it is manipulating is the content of the element and not the element itself and is not aware of the fact that iClone may create multiple clones of itself and not all of them will be hidden when needed (e.g., if the content is an ng-repeat)

Directives that do DOM manipulation are hard, this is why reusing the existing building blocks works best

[Izhaki]

@lgalfaso I wasn't suggesting the code is ready to be integrated into the Angular framework. Obviously much more work will have to be done to account for the various possible scenarios - some of which you have mentioned.

It was just for the sake of an example (and there might be others like me who only need this to work in the context of a particular case of showing a dropdown).

[caitp]

it would be pretty cool if we had a way for directives to optionally create a new child scope (from the POV of debugging applications using ng-inspector or batarang, and for perf in 1.x), but it would be pretty uncool from the POV of users writing code without wanting to think about what a scope is or how scopes work in angular.

but as cool (and uncool) as it would be, I don't think it's likely to happen, other solutions to these problems have been proposed and prototyped for 2.0 instead

[Izhaki]

If I'm honest, I can't see anyone using Angular without thinking about what a scope is or how scopes work.

If I had to give an introduction class to Angular to a group of developers, scopes would be there as one of the first 3 topics.

Other than that, all you say is well understood.

[caitp]

You'd have a hard time getting anything done with Angular 1.x without understanding Scopes (but many people don't actually thoroughly understand scopes or even prototypical inheritance and still manage to build angular apps), but this is really one of the problems with 1.x, it's not really a "feature"

[Narretz]

I think the discussion has shown that there's not much chance this will be included into 1.x. Regarding the initial performance of many ngIf's, #12078 seems to address this in a more general way.