Open bodograumann opened 5 years ago
Solution 1 - Use the container option skipBaseClassChecks and then no need for the injectable decorator on the base class. Although if you do this you will lose some parameter count checking which you may be relying upon - see inheritance.
Solution 2 - replicate the injectable decorator without the exception :
it('should be ok to decorate twice with safeinjectable',()=>{
function safeinjectable() {
return function(target: any) {
if (Reflect.hasOwnMetadata(METADATA_KEY.PARAM_TYPES, target)) {
}else{
const types = Reflect.getMetadata(METADATA_KEY.DESIGN_PARAM_TYPES, target) || [];
Reflect.defineMetadata(METADATA_KEY.PARAM_TYPES, types, target);
}
return target;
};
}
class Inject{
}
class SafeInject{}
decorate(injectable(),Inject)
expect(()=>decorate(injectable(),Inject)).toThrow();
decorate(safeinjectable(),SafeInject);
expect(()=>decorate(safeinjectable(),SafeInject)).not.toThrow();
})
Solution 3 - safeInjectable to try/catch on injectable - which is probably a better choice than 2 as there is no knowledge of inversify internals.
Personally I agree that decorate should be forgiving.
When using third party classes as base-classes for injectable classes, they need to be decorated with
decorate(injectable(), BaseClass)
. This must happen exactly once. So when multiple independent modules extendBaseClass
, it is not clear which of them should calldecorate
.Consider the following example:
The composition root does not know, the the modules are using the undecorated base class and the two modules don’t know anything about each other.
Furthermore both modules could possibly be used on their own without the other being present. Thus both should decorate the base class with the injectable annotation.
Workaround
Currently I am calling
This works, but the downside is, that all other errors during the decoration are also ignored.
Possible Solution
I can think of two possible solutions:
decorate(injectable(), BaseClass, true)
ordecorateIdem(injectable(), BaseClass)
.Personally I would prefer the first one, but maybe there are good reasons to not ignore this error, which I currently can not think of⁉