You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered: