-
-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Raise exception when injecting into modules #62
base: main
Are you sure you want to change the base?
Conversation
To me it happened that I accidentally injected my dependencies into a namespace module instead of into a class, like this: module Operations module Articles include Import["repositories.articles"] class Create # ... end end end When I did that, I got a NoMethodError for NilClass somewhere down the line. This led me to believe that I've somehow incorrectly passed parameters to `Import[]`, and it took me a while to realize what was the error. The error occurred because the downstream code assumes the #initialize method will be defined, which is not the case for modules. To improve the developer experience, we detect that we're attempting to inject into a module and raise an explicit exception.
29229f4
to
733d017
Compare
I won't go into details right now, but I want to note that this is strategy-dependent. For example, effect-based DI works with modules or whatever. And I believe we can make built-in strategies to work with modules too. However, this would require some hacking. |
Hmm, you're right, I haven't considered that. I've also often seen people using modules instead of classes for stateless operations, in which case they might want to use auto-inject. I'll keep this open in case you still want to merge it until support for modules is added. |
Here is an overview of what got changed by this pull request: Issues
======
- Added 3
Complexity increasing per file
==============================
- lib/dry/auto_inject/strategies/constructor.rb 2
Clones added
============
- spec/dry/auto_inject_spec.rb 3
See the complete overview on Codacy |
@@ -23,6 +24,8 @@ def initialize(container, *dependency_names) | |||
|
|||
# @api private | |||
def included(klass) | |||
fail Error, "cannot inject dependencies into a module" unless klass.respond_to?(:new) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Issue found: Always use raise
to signal exceptions.
|
||
context 'autoinject in a module' do | ||
it 'raises exception' do | ||
expect { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Issue found: Avoid using {...}
for multi-line blocks.
@@ -23,6 +24,8 @@ def initialize(container, *dependency_names) | |||
|
|||
# @api private | |||
def included(klass) | |||
fail Error, "cannot inject dependencies into a module" unless klass.respond_to?(:new) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To me it happened that I accidentally injected my dependencies into a namespace module instead of into a class, like this:
When I did that, I got an error originating from that line, but happening somewhere in dry-auto_inject's internals (a NoMethodError for NilClass). This led me to believe that I've somehow incorrectly passed parameters to
Import[]
, and it took me a while to realize what was the error.The error occurred because the downstream code assumes the
#initialize
method will be defined, which is not the case for modules. To improve the developer experience, we detect that we're attempting to inject into a module and raise an explicit exception.