These are chat archives for dry-rb/chat
include Container[:component](pseudo code) on the class, that's called auto-inject, right? what's it called when you only allow the
:componentto be injected via the constructor, explicitly?
include Import[:foobar]it's just builds some ruby code for you which will be invoked later, at runtime
include Import[:foobar]checks if something registered under
:foobar, but it doesn't extracts/unwraps/whatevers it
include ..[..]could also generate a getter method for you which simply instantiates the object from the container, so why is it called auto-inject?
MyClassWithFooDependency.new(foo: my_dep)instead of
MyClassWithFooDependency.new, this way the container won't be touched
include ...does provide that logic automatically?
initialize, and instance readers/getters.
newlazily extracts dependencies from the container (as I said you can pass your own) and passes them to the constructor,
initializeassigns obtained values to instance variables, ... oh, that's all. There is some stuff for dealing with inheritance but it's not relevant
callrather than constructor
Op.new(auto: 1, inject: 2, current_user: 3)?
current_userwould always have to present, but if that’s the case then yeah, it’s gonna work
:paramsobject for the "dynamic" options
.newand call super :)
include Import[:foo, :bar]and then
new(baz: ‘haha’)will work?
intializeto invoke auto-inject's assignments
optionsbut we might be able to simply use
optionsif we could make it compatible
class_macroscould be moved back to rom core
constrained?predicate in dry-t?
limitetc. that just use array’s API
ROM::Memory::Datasetdecorates an array, and when you call
#selecton it, it will still return
Datasetobject rather than an Array
dry-systemif I'm inheriting from class which has initialise with some arguments?
From what I understood yesterday, it is in case super method doesnt have parameters:
But I was mainly checking
args strategy. And it looks like this line should cover my case:
So I was wondering maybe I'm doing something wrong
new, auto-inject supports other strategies, but it's tricky. Using kwargs, ie one hash, is more predictable, otherwise passing sequential arguments as dependencies is cumbersome, believe me. And yes, you cannot mix args + kwargs
includeat all, tbh
new. what's the strategy to change that method, again? because we want 2 args, not just one (for now), and i can't override it in every single operation. what's the suggested strategy?
include MyGem.inject[:stuff]will be called with a
const_set, etc. is a good idea for dependency sharing? i am happy someone works on this, but i am a bit skeptical how this works out in projects with unexperienced devs... what's your opinions on that?
include Inject[:some_dep]as a hard-coded constant, yes, I'm confident that it's better than the alternatives in Ruby
new(our_stuff, kws)is hard to implement? can i help?
class Operation include Dry::AutoInject::MultipleArgs
newand call super, couldn't i?
new, it's injected via a separate module, you can add a method on top of it, but this won't help. It's hard to explain, just try it :)
new, i've avoided it so far
newis because that's where you access the container and inject? @flash-gordon
initialize(container)is the "problem"
attribute :foo, Types::DateTime.optionalbut when I send in a hash with either foo empty or foo blank, it fails with either "must be filled" or "is missing", what am I missing here?
# In the gem module Trailblazer class Operation attr_reader :policy attr_reader :something_else def initialize(policy:, something_else:) @policy = policy @something_else = something_else end def some_other_base_method(input) # do something with `policy` # do something with `something_else` end end end # In the application, where the developer has chosen to use dry-system module MyApp class Container < Dry::System::Container end Inject = Container.injector class MyOperation < Trailblazer::Operation include MyApp::Inject[ policy: "my_policy", something_else: "foo.bar.my_other_thing" ] end end