anchor.diff:    ## Break circularities with a forward class reference (*forwardRef*)
   
     The order of class declaration matters in TypeScript.
  -  We can't refer directly to a class until it's been defined.
  -
  -  This isn't usually a problem, especially if we adhere to the recommended *one class per file* rule.
  +  You can't refer directly to a class until it's been defined.
  +
  +  This isn't usually a problem, especially if you adhere to the recommended *one class per file* rule.
     But sometimes circular references are unavoidable.
  -  We're in a bind when class 'A refers to class 'B' and 'B' refers to 'A'.
  +  You're in a bind when class 'A' refers to class 'B' and 'B' refers to 'A'.
     One of them has to be defined first.
   
  -  The Angular `forwardRef` function creates an *indirect* reference that Angular can resolve later.
  +  The Angular `forwardRef()` function creates an *indirect* reference that Angular can resolve later.
   
     The *Parent Finder* sample is full of circular class references that are impossible to break.
   
   :marked
  -  We face this dilemma when a class makes *a reference to itself*
  +  You face this dilemma when a class makes *a reference to itself*
     as does the `AlexComponent` in its `providers` array.
     The `providers` array is a property of the `@Component` decorator function which must
     appear *above* the class definition.
   
  -  We break the circularity with `forwardRef`:
  +  Break the circularity with `forwardRef`:
   +makeExample('cb-dependency-injection/ts/src/app/parent-finder.component.ts','alex-providers','parent-finder.component.ts (AlexComponent providers)')(format='.')
   :marked
  
positive.code: +makeExample('cb-dependency-injection/ts/src/app/hero-bio.component.ts','component','src/app/hero-bio.component.ts')
  :marked
    The parent `HeroBiosComponent` binds a value to the `heroId`.
    The `ngOnInit` pass that `id` to the service which fetches and caches the hero.
    The getter for the `hero` property pulls the cached hero from the service.
    And the template displays this data-bound property.
  
  
negative.code: :marked
    That decorator makes it possible for Angular to identify the types of its two dependencies, `LoggerService` and `UserService`.
  
    Technically, the `@Injectable()`decorator is only required for a service class that has _its own dependencies_.
    The `LoggerService` doesn't depend on anything. The logger would work if you omitted `@Injectable()`
    and the generated code would be slightly smaller.
  
    But the service would break the moment you gave it a dependency and you'd have to go back
    and add `@Injectable()` to fix it. Add `@Injectable()` from the start for the sake
    of consistency and to avoid future pain.
  
  .alert.is-helpful
    :marked
      Although this site recommends applying `@Injectable()` to all service classes, don't feel bound by it.
      Some developers prefer to add it only where needed and that's a reasonable policy too.
  
  .l-sub-section
    :marked
      The `AppComponent` class had two dependencies as well but no `@Injectable()`.
      It didn't need `@Injectable()` because that component class has the `@Component` decorator.
      In Angular with TypeScript, a *single* decorator&mdash;*any* decorator&mdash;is sufficient to identify dependency types.
  
  
  <a id="service-scope"></a>
  