Skip to content

Instantly share code, notes, and snippets.

@timruffles

timruffles/di-taste.md

Last active June 2, 2016 11:53
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save timruffles/555f874ce256b02878307957f946599c to your computer and use it in GitHub Desktop.
Save timruffles/555f874ce256b02878307957f946599c to your computer and use it in GitHub Desktop.
Download ZIP
DI taste question
Raw
di-taste.md

In the DI DOCs the 'why' given for the component injector tree is to get multiple instances of a dependency. The editor component explicitly provides RestoreService to ensure it gets its own instance.

                                 providers                   instance of `RestoreService`
rootInjector                     [provide(RestoreService)]   instance A
 - heroEditorComponentInjector   [provide(RestoreService)]   instance B
   - childOfHero                 []                          instance B
 - someOtherEditor               []                          instance A

Is this the best use-case for demoing the component injector tree?

Further - is it actually a bad idea?

  • It seems to be implementing application logic (a restore service with multiple instances) via DI.
    • Since the RestoreService is not involved in instantiation, it can't, for instance, be changed later to keep a registry of instances etc.
  • Using DI in this way makes the flow of data implicit
    • not clear that childOfHero's dep is a logical 'instance' not a service/singleton. Not at all clear that it came from a parent, grand-parent, the root, etc.
    • in contrast, if the components got their isntance via @Input("restore") it'd be clear
  • It reminds me of the implicit way people implemented data flow with NG1 scopes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment