anchor.diff:    detaches it from DOM events (the attachments that it made) and destroys the component.
     The component can be garbage-collected (we hope) and free up memory.
   
  -
  +  而`ngIf`不同。
  +  把`ngIf`设置为假**将会**影响到组件的资源消耗。
  +  Angular会从DOM中移除该元素，停止相关组件的变更检测，把它从DOM事件中摘掉(事件是组件造成的附加项)，并销毁组件。
  +  组件会被垃圾回收(希望如此)并释放内存。
   
     Components often have child components which themselves have children.
     All of them are destroyed when `ngIf` destroys the common ancestor.
     This cleanup effort is usually a good thing.
   
  +  组件通常还有子组件，子组件还有自己的子组件。
  +  当`ngIf`销毁这个祖先组件时，它们全都会被销毁。
  +  这种清理工作通常会是好事。
  +
     Of course it isn't *always* a good thing.
     It might be a bad thing if we need that particular component again soon.
  +
  +  当然，它也并不*总是*好事。
  +  如果我们很快就会再次需要这个组件，它就变成坏事了。
   
     The component's state might be expensive to re-construct.
     When `ngIf` becomes `true` again, Angular recreates the component and its subtree.
     Angular runs every component's initialization logic again. That could be expensive ... as when
     a component re-fetches data that had been in memory just moments ago.
  +
  +  重建组件的状态可能是昂贵的。
  +  当`ngIf`重新变为`true`的时候，Angular会重新创建该组件及其子树。
  +  Angular会重新运行每个组件的初始化逻辑。那可能会很昂贵……比如当组件需要重新获取刚刚还在内存中的数据时。
   .l-sub-section
     :marked
       *Design thought*: minimize initialization effort and consider caching state in a
       companion service.
  +
  +    *设计思路*：要最小化初始化的成本，并考虑把状态缓存在一个伴生的服务中。
   :marked
     Although there are pros and cons to each approach,
     in general it is best to use `ngIf` to remove unwanted components rather than
     hide them.
   
  +  虽然每种方法都有各自的优点和缺点，但使用`ngIf`来移除不需要的组件通常都会比隐藏它们更好一些。
  +
     **These same considerations apply to every structural directive, whether built-in or custom.**
     We should ask ourselves &mdash; and the users of our directives &mdash; to think carefully
     about the consequences of adding and removing elements and of creating and destroying components.
   
  +  **同样的考量也适用于每一个结构型指令，无论是内建的还是自定义的。**
  +  我们应该让自己以及指令的使用者仔细考虑下添加元素、移除元素以及创建和销毁组件的后果。
  +
     Let's see these dynamics at work. For fun, we'll stack the deck *against*
     our recommendation and consider a component called `heavy-loader` that
     ***pretends*** to load a ton of data when initialized.
   
  +  让我们在实践中看看这些变化。为了好玩儿，我们设想在甲板上有个叫`heavy-loader`（重型起重机）的组件，它会***假装***在初始化时装载一吨数据。
  +
     We'll display two instances of the component.  We toggle the visibility of the first one with CSS.
     We toggle the second into and out of the DOM with `ngIf`.
  +
  +  我们将显示该组件的两个实例。我们使用CSS切换第一个实例的可见性，用`ngIf`把第二个实例添加到DOM和将其移除。
   
   +makeTabs(
       `structural-directives/ts/app/structural-directives.component.html,
  
positive.code:   First we toggle the component's visibility repeatedly. The component never leaves the DOM.
    When visible it's always the same instance and the log is quiet.
  
    Then we toggle the second component with `ngIf`.
    We create a new instance every time and the log shows that we're paying
    a heavy price to create and destroy it.
  
    If we really expected to "wink" the component like this, toggling visibility would be the better choice.
    In most UIs, when we "close" a component we're unlikely see it again for a long time, if ever.
    The `ngIf` would be preferred in that case.
  
  <a id="template"></a>
  .l-main-section
  :marked
    ## The *&lt;template>* tag
  
    Structural directives, like `ngIf`, do their magic by using the
    [HTML 5 template tag](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/template).
  
    Outside of an Angular app, the `<template>` tag's default CSS `display` property is `none`.
    It's contents are ***invisible*** within
    a hidden [document fragment](https://developer.mozilla.org/en/docs/Web/API/DocumentFragment).
  
    Inside of an app, Angular ***removes*** the`<template>` tags and their children.
    The contents are gone &mdash; but not forgotten as we'll see soon.
  
    We can confirm these effects by wrapping the middle "hip" of the phrase "Hip! Hip! Hooray!" within a `<template>` tag.
  +makeExample('structural-directives/ts/app/structural-directives.component.html', 'template-tag')(format=".")
  :marked
    The display is a 'Hip! Hooray!', short of perfect enthusiasm. The DOM effects are different when Angular is in control.
  figure.image-display
    img(src='/resources/images/devguide/structural-directives/template-in-out-of-a2.png' alt="template outside angular")
  
  :marked
    Evidently Angular replaces the `<template>` tag and its contents with empty `<script>` tags.
    That's just its default behavior.
    It can do something different as we saw when applying a variety of `ngSwitch` directives to `<template>` tags:
  
  +makeExample('structural-directives/ts/app/structural-directives.component.html', 'ngSwitch')(format=".")
  :marked
    When one of those `ngSwitch` conditions is true, Angular inserts the template's content into the DOM.
  
    What does this have to do with `ngIf` and `ngFor`?  We didn't use a `<template>` tag with those directives.
  
  <a id="asterisk"></a>
  .l-main-section
  :marked
    ## The asterisk (\*) effect
    Here are those directives again. See the difference?
  
  +makeExample('structural-directives/ts/app/structural-directives.component.html', 'asterisk')(format=".")
  :marked
    We're prefixing these directive names with an asterisk (\*).
  
    The asterisk is "syntactic sugar". It simplifies `ngIf` and `ngFor` for both the writer and the reader.
    Under the hood, Angular replaces the asterisk version with a more verbose `<template>` form.
  
    The next two `ngIf` examples are effectively the same and we may write in either style:
  
  +makeExample('structural-directives/ts/app/structural-directives.component.html', 'ngIf-template')(format=".")
  
  :marked
    Most of us would rather write in style (A).
  
    It's worth knowing that Angular expands style (A) into style (B).
    It moves the paragraph and its contents inside a `<template>` tag.
    It moves the directive up to the `<template>` tag where it becomes a property binding,
    surrounded in square brackets. The boolean value of the host component's `condition` property
    determines whether the templated content is displayed or not.
  
    Angular transforms `*ngFor` in a similar manner:
  
  +makeExample('structural-directives/ts/app/structural-directives.component.html', 'ngFor-template')(format=".")
  :marked
    The basic pattern is the same:&nbsp; create a `<template>`, relocate the content,
    and move the directive onto the `<template>`.
  
    There are extra nuances stemming from
    Angular's [ngFor micro-syntax](template-syntax.html#ngForMicrosyntax) which expands
    into an additional `ngForOf` property binding (the iterable) and
    the `hero` template input variable (the current item in each iteration).
  
  <a id="unless"></a>
  .l-main-section
  :marked
    ## Make a structural directive
    Let's write our own structural directive, an `Unless` directive, the not-so-evil twin of `ngIf`.
  
    Unlike `ngIf` which displays the template content when `true`,
    our directive displays the content when the condition is ***false***.
  
  block unless-intro
    :marked
      Creating a directive is similar to creating a component.
      * import the `Directive` decorator.
  
      * add a CSS **attribute selector** (in brackets) that identifies our directive.
  
      * specify the name of the public `input` property for binding
      (typically the name of the directive itself).
  
      * apply the decorator to our implementation class.
  
      Here is how we begin:
  
  +makeExample('structural-directives/ts/app/unless.directive.ts', 'unless-declaration', 'unless.directive.ts (excerpt)')(format=".")
  .l-sub-section
    :marked
      ### Selector brackets [&nbsp;]
      The CSS syntax for selecting an attribute is a name in square brackets.
      We surround our directive name in square brackets. See *Directive configuration* on the
      [cheatsheet](cheatsheet.html).
  
      ### Selector name prefixes
  
      We recommend picking a selector name with a prefix to ensure
      that it cannot conflict with any standard HTML attribute, now or in the future.
  
      We do **not** prefix our `unless` directive name with **`ng`**.
      That prefix belongs to Angular and
      we don't want to confuse our directives with their directives.
  
      Our prefix is `my`.
  :marked
    We'll need access to the template *and* something that can render its contents.
    We access the template with a `TemplateRef`.  The renderer is a `ViewContainerRef`.
    We inject both into our constructor as private variables.
  
  +makeExample('structural-directives/ts/app/unless.directive.ts', 'unless-constructor')(format=".")
  
  :marked
    The consumer of our directive will bind a boolean value to our directive's `myUnless` input property.
    The directive adds or removes the template based on that value.
  
    Let's add the `myUnless` property now as a setter-only property.
  
  +makeExample('structural-directives/ts/app/unless.directive.ts', 'unless-set')(format=".")
  .l-sub-section
    :marked
      The `@Input()` annotation marks this property as an input for the directive.
  :marked
    Nothing fancy here: if the condition is false,
    we render the template, otherwise we clear the element content.
  
    The end result should look like this:
  
  +makeExample('structural-directives/ts/app/unless.directive.ts', null, 'unless.directive.ts')
  
  
negative.code:   structural directives like `ngFor` and `ngIf` and we
    wrote our own structural directive, `myUnless`, to do something similar.
  
    我们学会了通过像`ngFor`和`ngIf`这样的结构型指令来操纵HTML的布局。我们还写出了我们的第一个结构型指令`myUnless`来做类似的事情。
  
    Angular offers more sophisticated techniques for managing layout
    such as *structural components* that can take external content
    and incorporate that content within their own templates.
    Tab and tab pane controls are good examples.
  
    Angular提供了更多成熟的技术来管理布局，比如*结构性组件*可以接受外部内容，并把这些内容合并到组件自己的模板中。
    多页标签及其面板控件就是很好的例子。
  
    We'll learn about structural components in a future chapter.
  
    我们将在未来的章节中学到结构型指令。
  