Next-gen ruby libs! » github.com/dry-rb » website: https://dry-rb.org » forum: https://discourse.dry-rb.org
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?
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 (extend
ing 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?