Trying to wrap my head around the 'right' way to do DI. Say I have a third party library where an object needs to be initialized with some state, like
SomeService::Events::ChangedPlan.new(user_attributes).(plan_name). Would it be appropriate to register it in my container with something like container.register(:notify_changed_plan) { |user_attributes, plan_name| SomeService::Events::ChangedPlan.new(user_attributes).(plan_name) }? Earlier, I was just registering the class name and instantiating the object in my class, but then I need to know the object's instantiation interface and the dependency name was 'changed_plan' which is not so descriptive (verb?) compared to 'notify_changed_plan' and it felt a bit ugly. Is this how I should approach third party code (wrap the interface when I register it, or with a wrapper class)? And should I avoid registering classes directly in my container, or is that okay?
@kj If I was doing this, I’d write my own classes to wrap it
and have the class that I own/control (the wrapper) provide an interface that’s consistent with the rest of my app
@timriley Do you think it's okay to do it the way I've done if it's a simple jigging around of the arguments (to just do it in the register block)?
@kj I guess so ¯_(ツ)_/¯ Hard to know if it’ll ever stay a simple jigging around though, right? So out of principle I like to wrap 3rd party objects with my own.
What I think you’ll lose if you have it registered in the container like that is the ability to auto-inject those objects.
so they can’t easily become collaborators for others
@timriley Because they will be instantiated each time they are called?
@kj No quite, it’s because dry-auto_inject doesn’t let you pass additional args when resolving objects from the container
@timriley Oh, I thought it would resolve to a proc in that case (admittedly I haven't tried it yet)?
@kj oh yeah, maybe, tbh I haven’t tried
@timriley Heh, no worries. But yeah, maybe it's not ideal either way if every time I call it, it will create a new instance of the wrapped class.
I don’t find that aspect a big deal
that’s how dry-container works when it’s populated via dry-system
that’s how it usually works when people manually register things too
returning the exact same instance every time is a rarer thing, usually reserved for special objects
@timriley Oh, yeah that makes sense. Not sure what I was thinking there.
Is it possible to use
Dry::Struct with rails ActiveModel? Ideally, what I’d like to do is have a pure non-rails domain object defined with Dry::Struct and then to decorate that dynamically in my controller, so I can take advantage of rails form helpers. However, I have not been able to make it work that way (extending the already created object breaks rails form_for) and if I include ActiveModel::Model in my Dry::Struct class, I get a ActiveModel::UnknownAttributeError when I try to create objects? Is this whole endeavor misguided or is there a way to make this work and get both a nice decoupled form object and be able to use form helpers?