Class Activation process hook about dependency-injection HOT 7 CLOSED

This I can add this week, no problem. Also, the new docs will have some more high level information on architecture.

from dependency-injection.

Rob, this is awesome. This will just leverage more conventions during class activation and adding dynamic metadat.
Can't wait to test this😋

from dependency-injection.

I think we can just provide a hook on the DI container called onActivate that gets called any time a new instance is created. Then you can just configure that with your own custom activation code to inspect object instance and perform custom cross-cutting behavior. I think onActivate should probably return an instance, so that the hook can even have the opportunity to provide alternate instances or Proxies in the future. Any thoughts on what you would need specifically? Can you share a bit about what you want to do so that I have some concrete use cases?

from dependency-injection.

@EisenbergEffect this is awesome news, the point for us is to be able to manipulate the class, one example we are trying to do now is to auto add common decorators to the class, or dynamically add properties or methods( again decorators is good for that).

from dependency-injection.

Ok, adding a class activation hook was quite a bit of trouble. So, I decided not to do it, but to add a lower level hook. There's a new api in the next release on the container: setHandlerCreatedCallback(onHandlerCreated: (handler: InvocationHandler) => InvocationHandler) The container uses an InvocationHandler to invoke the function/constructor. This structure contains the function (fn), its inject array (called dependencies) and an invoker which does the actual invocation. By using this hook, you will be notified each time an InvocationHandler is created. This is once per function that needs to be invoked (cached). Once you have this, you can monkey-patch the invoke method of the handler to add custom activation logic. The nice thing about this is that you can decided whether or not to alter the invoke by examining the dependencies, once, when the handler is created, rather than having to run that decision logic each time the function is invoked.

from dependency-injection.

sounds like a step in the right direction thx @EisenbergEffect

from dependency-injection.

For those interested, here's some sample code that I put together to illustrate what I think Tomasz can now do, based on my discussion with him:

container.setHandlerCreatedCallback(handler => {
  //this callback is called once per type that the container will instantiate
  //so, for Foo, it will be called once during the application lifetime
  //but you can inspect what the container finds, change it and...
  //control how instances of that type are created thereafter

  //so we only have to change the invocation when the type actually has a dependency on Dispatcher

  let index = handler.dependencies.indexOf(Dispatcher);
  if(index !== -1) {
    handler.dependencies[index] = new DispatcherResolver();

    let invoke = handler.invoke;
    handler.invoke = function(container, dynamicDependencies) {
      let instance = invoke.call(handler, container, dynamicDependencies);
      container._lastDispatcher.connect(instance);
      container._lastDispatcher = null;
      return instance;
    };
  }

  return handler
});

//a custom resolver's get is invoked by the container to "resolve" an instance
//we use a special resolver so we can capture the instance for later use in our invoke fixup
@resolver
class DispatcherResolver {
  get(container) {
    //not sure how you want to create it, but do that here
    //and then store it temporarily on the container, so you can grab it later
    return container._lastDispatcher = container.get(InstanceDispatcher); 
  }
}

class InstanceDispatcher {
  connect(instance) {
    //do what you want with the connected instance
  }
}

I noted to Tomasz that he probably doesn't want to use _lastDispatcher but instead may need to push/pop from a stack. And, actually, in that case, it could be a singleton that is shared and then it doesn't need to be stored on the container as an ad hoc variable.

from dependency-injection.