These are chat archives for dry-rb/chat
Next-gen ruby libs! » github.com/dry-rb » website: https://dry-rb.org » forum: https://discourse.dry-rb.org
Container.load_componentfor each of the specified dependencies: https://github.com/dry-rb/dry-system/blob/master/lib/dry/system/injector.rb#L63
include MyApp::Import[“foo”, “bar”]is evaluated
class Foo include MyImport[“bar”] def call(input) # bar is here and ready to work. it’s an instance of `Bar` bar.(input) end end
MyImport = MyContainer.injectorwould have to be somehere too
includein the class, the dependencies are "resolved", it's basically like calling require on top of the class file... is that right?
Container.load_component(“foo/bar”)and you’re done
”foo.bar”will work too since we encounter for both file paths and object identifiers
examples/standalone (master«) % be irb irb(main):001:0> require './system/container' => true irb(main):002:0> App.load_component('user_repo') => App irb(main):003:0> UserRepo => UserRepo
load_componentreturn a component object (as in
System::Component) and you can use it to instantiate your object, we support custom object loaders so you can tweak default behavior (which is just calling
irb(main):003:0> App.load_component('user_repo') => App irb(main):004:0> App.component('user_repo').instance => #<UserRepo:0x007fa9919858b8 @db=#<Sequel::SQLite::Database: “sqlite::memory”>>
irb(main):005:0> App.component('user_repo') => #<Dry::System::Component identifier=“user_repo” path="user_repo">
irb(main):006:0> App.component('user_repo').loader => #<Dry::System::Loader:0x007fa9909b85e8 @path=“user_repo”>
irb(main):007:0> App.component('user_repo').loader.constant => UserRepo
requirein your files
Kernel.requirebut container-specific so it uses configured load paths and supports globing as a bonus
.newin a way that is sufficient to call it w/o args, then you can auto-register them with default loader
require_relative 'operation'or something like that
config.auto_registrarcan be set to a custom class that will handle auto-registration
A::Cis a dependency of
Athen why not just put a
if we had auto-inject, an operation would look something along the following lines?
class A < TRB::Operation include Container[:a.contract] include Container[:a.representer]
includelines are just kind of pseudo-code? because they don’t really make sense to me...
System::Container.resolves and returns an object from the container, and unless it’s a module subclass, I don’t see why you’d be including it?
#null?predicate to dry-view parts...
- if my_thing.null? / `my_thing` is a nil value, wrapped in a NullPart == some_partial == another_partial - else / `my_thing` is a real non-nil value in this case == special_partial == another_partial
got error using dry-system with Hanami. Can't find solution, any tips ?
ArgumentError: wrong number of arguments (given 1, expected 0) /usr/local/lib/ruby/gems/2.3.0/gems/dry-auto_inject-0.4.1/lib/dry/auto_inject/strategies/kwargs.rb:12:in `new'
this is result of using
auto inject in Hanami View
Import = App.injector
something like this
module Web::Views::Users class Create include Web::View include Import['repositories.users'] end end
include Web::Viewis present. In other places everything works fine
Whatever::Cell.new(data_object, additional: args).()
dry-web-rodasample app and inside
GemfileI found that ROM gems are fetching from Github instead of released version (rubygems). Is there any reason why they are fetching from Github ?