Share your code. npm Orgs help your team discover, share, and reuse code. Create a free org »

    honk-dipublic

    Honk! DI!

    honk-di is a Guice-like dependency injector for (Java|Coffee)Script.

    The Injector

    The injector creates classes and resolves their dependencies. Take the following.

    class User
      say: (name) -> console.log "hi, #{name}"
     
    injector = new inject.Injector()
    user1 = injector.getInstance(User)
    user2 = injector.getInstance(User)
     
    assert user1 !== user2

    But what if we want only one User? We scope it!

    class User
      @scope: 'singleton'
     
      say: (name) -> console.log "hi, #{name}"
     
    injector = new inject.Injector()
    user1 = injector.getInstance(User)
    user2 = injector.getInstance(User)
     
    assert user1 === user2

    Dependencies

    Making a single class isn't going to save you much. What you want is for it to resolve your dependencies.

    inject = require 'honk-di'
     
    class Sayer
      @scope: 'singleton'
     
      say: (name) -> console.log "hi, #{name}"
     
    class User
      sayer: inject(Sayer)
     
      say: (name) -> @sayer.say(name)
     
    injector = new inject.Injector()
    user     = inject.getInstance(User)
    sayer    = inject.getInstance(Sayer)
     
    user.say('Jimmy')
    > Hijimmy
    user.sayer === sayer
    > True

    Note how DI's managed the singleton scope of the sayer for us. If we pulled out another User from the injector, it would be a new instance with the same instance to Sayer

    Binders

    A binder is analogous to a Guice Module. But, seeing how "module" means something in the ol' Node.js world, they're called binders here.

    Sometimes your dependencies get more complicated. Like, you may have a MapView that's just an in-memory mock for your test, but uses Google Maps in the UI, and you're working on porting them to Leaflet. You can control this kind of malarkey with DI pretty well.

    inject = require 'honk-di'
     
    class ProductionEnv extends inject.Binder
      configure: ->
        @bind(MapView).to(GoogleMapView)
        @bind(UserStore).to(MemUserStore).inScope('singleton')
        @bindConstant('api.root').to('/api/v1')

    Now, the injector may consult some number of Binders before creating an instance. Say we have a controller as follows:

    class Sayer
      @scope: 'singleton'
     
      say: (name) -> console.log "hi, #{name}"
     
    class MapController
      view:     inject(MapView)
      users:    inject(UserStore)
      apiRoot:  inject('api.root')
     
      render: ->
        $.get("#{apiRoot}/users")
          .then((users) -> @users.reset(user))
          .done((users) -> @view.render(users))

    What's missing

    Providers, complex scopes. I'm sure plenty of other small weird things.

    Good Ideas

    The best DI apps have one call to injector.getInstance. Passing the injector around or pulling many instances out of it is likely a bad sign. Try to express hairy sections as classes that have some number of dependencies and let DI figure it out for you.

    Keywords

    none

    install

    npm i honk-di

    Downloadsweekly downloads

    24

    version

    1.0.0

    license

    none

    last publish

    collaborators

    • avatar
    • avatar