Le Guide Angular | Marmicode
  • Le Guide Angular par Marmicode
  • Pourquoi Angular ?
  • ECMAScript 6+
    • Un Peu d'Histoire
    • Propriétés du Langage
    • "Single-Threaded" donc Asynchrone
    • Event Loop
    • Classes
    • Hoisting is Dead: var vs. let vs. const
    • this & "binding"
    • Arrow Functions
    • Template Strings
    • Syntactic Sugar
      • Spread
      • Destructuring
      • Rest
      • Object Literal Property Value Shorthand
    • Named Parameters
    • Compatibilité
  • TypeScript
    • Pourquoi TypeScript ?
    • De l'ECMAScript au TypeScript
    • Visibilité des Propriétés
    • Typing des Propriétés
    • Types
    • Interfaces
    • Inference
    • Duck Typing
    • Duck Typing Patterns
      • Compatibilité de Librairies
      • Entity Constructor
    • Décorateurs
      • Décorateurs de Propriété
      • Décorateurs de Classe
      • Décorateurs de Méthode & Paramètres
    • Quelques Liens
  • Tools
    • Clavier mécanique
    • Git
    • Command Line
    • NodeJS
    • NPM
    • Yarn
      • Pourquoi Yarn ?
      • Définition et Installation des Dépendances
      • Scripts
      • Mise à Jour et Automatisation
    • Chrome
    • IntelliJ / WebStorm / VSCode
      • Raccourcis clavier IntelliJ / WebStorm
    • Floobits
    • Angular CLI
    • StackBlitz
    • Compodoc
  • Angular
    • Bootstrap
    • Composants
      • Root Component
      • Template Interpolation
      • Property Binding
      • Class & Style Binding
      • Event Binding
      • *ngIf
      • *ngFor
      • L'approche MVC
      • Création de Composants
      • Exemple
    • Container vs. Presentational Components
    • Interaction entre Composants
      • Input
      • Output
      • Exemple
    • Change Detection
      • Les Approches Possibles
      • Fonctionnement de la Change Detection
      • Optimisation de la Change Detection
      • Immutabilité
      • Quelques Liens
    • Project Structure & Modules
      • Entry Point
      • Définition d'un Module
      • Root Module
      • Feature Module
      • Shared Module
      • Exemple
    • Dependency Injection
      • Qu'est-ce que la "Dependency Injection" ?
      • Injection d'un Service Angular
      • Services & Providers
      • Portée des Services
      • Tree-Shakable Services
      • Class vs Injection Token
      • Exemple
    • Callback Hell vs. Promise vs. Async / Await
      • Callback Hell
      • Promise
      • Async / Await
    • Observables
      • Reactive Programming
      • Promise vs Observable
      • Subscribe
      • Unsubscribe ⚠️
      • Création d'un Observable
      • Opérateurs
        • Définition d'un Opérateur
        • Lettable Operators vs Legacy Methods
        • map
        • filter
        • mergeMap & switchMap
        • shareReplay
        • buffer
        • debounceTime
        • distinctUntilChanged
        • retry
      • Quelques Liens
      • Talks
    • Http
      • Pourquoi HttpClient ?
      • Utilisation de HttpClient
      • Utilisation dans un Service
      • Gestion de la Subscription ⚠️
    • State Management
      • Quelques Liens
      • Talks
    • GraphQL
    • Formulaires
      • Template-driven Forms 🤢
      • Reactive Forms 👍
        • Avantages des "Reactive Forms"
        • La boite à outils des "Reactive Forms"
        • Validation
        • Observation des Changements
    • Directives
      • Attribute Directive
      • Structural Directive
    • Pipes
    • Routing
      • Mise en Place du Routing
      • Lazy Loading
      • Project Structure
      • Route Guards
    • Testing
      • Unit-Testing
        • 📺Introduction au Test-Driven Development
        • Jasmine
        • Unit-Test Synchrone
        • Test-Driven Development
        • Unit-Test Asynchrone
        • TestBed
        • Unit-Test d'un Service
        • Unit-Test d'un Composant
        • Unit-Test et Spies
        • Unit-Test et HttpClient
      • End-to-End
      • Talks
    • Sécurité
      • Quelques Liens
    • Animation
    • Internationalisation
    • Quelques Liens
  • Cookbook
    • Authentification et Autorisation
    • Remplacement Dynamique de Composants
    • Lazy Loading without Router
    • Project Structure
    • SCAM Modules
    • Setup a Mock ReSTful API
  • Autres Ressources
  • Stay Tuned
    • 🎁-20% sur nos workshops avec le code GUIDEANGULAR
    • 🐦Suivez-moi !
    • 📺Cours Vidéo
    • 📬Newsletter
    • 📝Blog
  • Nos Services
    • Formation Angular
    • Atelier Unit-Testing Angular
    • Atelier Architecture Angular
    • Consultation à Distance & Code Review
  • Nos Guides
    • Guide Agile
    • Guide API ReST
    • Guide NodeJS
Propulsé par GitBook
Sur cette page
  • Injector Tree
  • Root Injector
  • Component Injector
  • Lazy Loading
  • Feature Service Module
  • Module.forRoot
  1. Angular
  2. Dependency Injection

Portée des Services

PrécédentServices & ProvidersSuivantTree-Shakable Services

Dernière mise à jour il y a 5 ans

Injector Tree

Angular ne dispose pas que d'un seul "injector" mais d'un arbre d'"injectors".

Root Injector

Tous les "providers" définis par les modules importés directement ou indirectement par l'AppModule sont injectés par le "root injector" et sont donc accessibles dans toute l'application.

Component Injector

Chaque composant dispose d'un "injector" et peut définir des "providers" via la propriété providers de sa configuration.

Ces "providers" vont écraser les "providers" parents (ceux des composants parents ou du "root injector") et définir de nouvelles instances des services associés pour chaque instance du composant.

@Component({
    providers: [
        BookRepository
    ]
})
export class BookPreviewComponent {
}

Lazy Loading

Le danger dans ce cas est de réimporter un module définissant des "providers" et on se retrouve alors avec plusieurs instances du même "service".

Cela pose particulièrement problème pour les "stateful services".

Feature Service Module

@NgModule({
    providers: [
        BookRepository
    ]
})
export class BookCoreModule {
}
@NgModule({
    imports: [
        BookCoreModule
    ]
})
export class AppModule {
}

Cette approche reste fragile car à la moindre inattention, le module BookCoreModule peut se retrouver importé (directement ou indirectement) par d'autres modules "lazy loaded" et le même problème se reproduira.

Module.forRoot

La bonne pratique est de ne pas définir les "providers" de "stateful services" dans le module mais plutôt via une méthode statique conventionnellement nommée forRoot dont le résultat est importé par le "root module" AppModule.

@NgModule({
})
export class BookCoreModule {

    static forRoot(): ModuleWithProviders {
        return {
            ngModule: BookCoreModule,
            providers: [
                BookRepository
            ]
        };
    }

}
@NgModule({
    imports: [
        BookCoreModule.forRoot()
    ]
})
export class AppModule {
}

Les modules "lazy loaded" qui importent le module BookCoreModule ne produiront alors pas de doublon.

Cette approche est malheureusement encore loin d'être parfaite :

  • la syntaxe forRoot est overkill ;

  • rien n'empêche l'import BookCoreModule.forRoot() de dans un module autre que le "root module" ;

  • tous les "stateful services" sont importés par le "root module" dès le chargement de l'application et peut-être inutilement.

Il est préférable d'éviter cette approche et d'utiliser des . Autrement, les composants auront des comportements différents et parfois imprédictibles en fonction de l'endroit où ils sont utilisés.

Dans le cas du , les modules Angular sont chargés de façon asynchrone et afin d'éviter de perturber le "root injector", ces derniers créent des "child injectors".

Pour éviter le problème de double instanciation de "stateful services" décrit , la bonne pratique la plus commune est de créer des modules dédiés à la définition des "providers" de "stateful services" qui seront ensuite importés uniquement par le "root module" AppModule.

C'est pour ces raisons qu'Angular 6 a introduit la notion de .

Inputs / Outputs pour interagir avec les "child components"
Lazy Loading
Tree-Shakable Services
ci-dessous
Angular Services Scope