Feel free to reject and close this if you disagree.
I think that the inversify-inject-decorators package should reconsider the design of its API.
Specifically, I think that a Container instance should not be required to create the decorators. This feels like a code-smell to me. It introduces the constraint that you need to create the Container instance during import-time, so that the decorators may be used.
Rarely, if ever, in my Inversify applications, is the Container instance created at import time.
I suggest reworking things so that not only are the decorators returned, but also a function for applying their effects to a given Container instance:
let { lazyInject, applyDecorators } = createDecorators();
// later...
applyDecorators(container);
This is eminently more flexible. Especially once you start generating child containers at runtime, etc.
Thanks for hearing me out. Great work on everything.
Feel free to reject and close this if you disagree.
I think that the
inversify-inject-decorators
package should reconsider the design of its API.Specifically, I think that a Container instance should not be required to create the decorators. This feels like a code-smell to me. It introduces the constraint that you need to create the Container instance during import-time, so that the decorators may be used.
Rarely, if ever, in my Inversify applications, is the Container instance created at import time.
I suggest reworking things so that not only are the decorators returned, but also a function for applying their effects to a given Container instance:
This is eminently more flexible. Especially once you start generating child containers at runtime, etc.
Thanks for hearing me out. Great work on everything.