Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Piotr Solnica
@solnic
this would be super useful
Andy Holland
@AMHOL
Yeah, still not sure of the best way to go about it
Piotr Solnica
@solnic
we won’t know until we try
I can tell you I have use cases for local-per-test stubs and global
global in the sense that I have a dep that I want to stub completely for all tests
it’s my thing, there are separate tests for it so I’m safe, but for all the tests that use objects which rely on it, I want to use a stubbed version
Andy Holland
@AMHOL
Create something like dry-container-rspec or something?
Piotr Solnica
@solnic
no, this doesn’t feel needed
it could be an internal thing, non-test-framework-specific
Andy Holland
@AMHOL
Feels weird to update the actual library just for testing though
Piotr Solnica
@solnic
I dunno
no super strong opinions
otoh it feels essential to have this kind of an interface for tests
Andy Holland
@AMHOL

You happy with

Dry::Container.configure do |config|
  config.registry = Dry::Container::Test::Registry.new
end

For the things you want to stub for all tests?

Piotr Solnica
@solnic
if we could collapse that into Dry::Container.test_mode! then yes, I guess, need to think about this :)
Andy Holland
@AMHOL
Yeah
Benjamin Klotz
@tak1n
at our company I'm trying to introduce dry-constructor as injector lib for our service objects
we use initializers and specify default collaborators, but for specs u can inject mocks and unit test the service object itself
is there a way to specify default values for dependencies injected by dry-constructor?
eg :
class DoThings
  def initializer(collab = Collaborator.new)
    @collab = collab
  end
end
and in specs u can do DoThings.new(double).call
in controller or anywhere else u do DoThings.new.call
Andy Holland
@AMHOL
@tak1n, dry-constructor is just for defining the constructor with the args to inject and assigning them to ivars, might be worth looking at Dry::AutoInject
@tak1n if you're using Rails, worth talking to @solnic as he recently implemented IoC in Rails and said it worked really well
Benjamin Klotz
@tak1n
@AMHOL okay thx :)
Andy Holland
@AMHOL
NP :)
Hannes Nevalainen
@kwando
This message was deleted
nvm, it won't work for more complex cases anyway
Piotr Solnica
@solnic
@kwando hmm?
Hannes Nevalainen
@kwando
let(:container){ Hash.new{ |_,k| MyAppContainer.resolve(k) }
This message was deleted
then override as needed in tests
Piotr Solnica
@solnic
@AMHOL can we push new dry-container release? I’d like to get off of master in rodakase
Andy Holland
@AMHOL
@solnic yeah, do you have permissions on rubygems?
Piotr Solnica
@solnic
@AMHOL I don’t think so
Piotr Solnica
@solnic
@AMHOL can dry-configurable be used on an object instance level?
Andy Holland
@AMHOL
No, there was a reason why I made it like that but that was a while ago now
Piotr Solnica
@solnic
it’s ok, just curious
Andy Holland
@AMHOL
Think I just thought configuring instances was a bad idea, should just use DI
To compose behaviour
Piotr Solnica
@solnic
@AMHOL could you add me to dry-container on rubygems and/or release a new version?
Andy Holland
@AMHOL
@solnic rubygems says you've got access?
Piotr Solnica
@solnic
ah ok
Andy Holland
@AMHOL
Need to update readme in dry-equalizer BTW
Piotr Solnica
@solnic
@AMHOL right
Tim Riley
@timriley
Is the idea with Dry::Container::Mixin that once you’ve extend-ed it in a class, any of that class’ subclasses share the same container storage?
That’s how it’s working now, anyway (as of dryrb/dry-container@652dd84) – just interested in learning what the thinking was behind it?
I’ve been wondering why in my Rodakase app, where I have a MyApp::Container < Rodakase::Container class, which is top-level, and a Main::Container < Rodakase::Container class, which is in a “sub-app”, how they actually ended up having access to all of the container registrations across the codebase. This appears to be why :)
Tim Riley
@timriley
Hmm, I’m guessing it’s because when you extend, the container is “static,” at the class-level, meaning it should be the same for any subclasses.
makes sense after I think about it for a while :)