Shirinji
Dependencies Injection made clean and easy for Ruby.
Supported ruby versions
- 2.7.x
- 3.0.x
Principles
Remove hard dependencies between your objects and delegate object tree building to an unobtrusive framework with cool convention over configuration.
Shirinji relies on a mapping of beans and a resolver. When you resolve a bean, it will return (by default) an instance of the class associated to the bean, with all the bean dependencies resolved.
class FooService
attr_reader :bar_service
def initialize(bar_service:)
@bar_service = bar_service
end
def call(obj)
obj.foo = 123
bar_service.call(obj)
end
end
map = Shirinji::Map.new do
bean(:foo_service, klass: 'FooService')
bean(:bar_service, klass: 'BarService')
end
resolver = Shirinji::Resolver.new(map)
resolver.resolve(:foo_service)
# => <#FooService @bar_service=<#BarService>>
Shirinji is unobtrusive. Basically, any of your objects can be used outside of its context.
bar_service = BarService.new
foo_service = FooService.new(bar_service: bar_service)
# => <#FooService @bar_service=<#BarService>>
# tests
RSpec.describe FooService do
let(:bar_service) { double(call: nil) }
let(:service) { described_class.new(bar_service: bar_service) }
describe '.call' do
# ...
end
end
Constructor arguments
Shirinji relies on constructor to inject dependencies. It's considering that objects that receive dependencies should be immutables and those dependencies should not change during your program lifecycle.
Shirinji doesn't accept anything else than named parameters. This way, arguments order doesn't matter and it makes everybody's life easier.
Name resolution
By default, when you try to resolve a bean, Shirinji will look for a bean named accordingly for each constructor parameter.
It's possible to locally override this behaviour though by using attr
macro.
class FooService
attr_reader :bar_service
def initialize(my_service:)
@bar_service = my_service
end
end
map = Shirinji::Map.new do
bean(:foo_service, klass: 'FooService') do
attr :my_service, ref: :bar_service
end
bean(:bar_service, klass: 'BarService')
end
resolver = Shirinji::Resolver.new(map)
resolver.resolve(:foo_service)
# => <#FooService @bar_service=<#BarService>>
Caching and singletons
Shirinji provides a caching mecanism to help you improve memory consumption. This cache is safe as long as your beans remains immutable (they should always be).
The consequence is that any cached instance is actually a singleton. Singleton is no more a property of your class but of it's environment, improving the reusability of your code.
Singleton is the default access mode for a bean.
map = Shirinji::Map.new do
bean(:bar_service, klass: 'BarService', access: :instance)
bean(:foo_service, klass: 'FooService', access: :singleton)
# same as bean(:foo_service, klass: 'FooService')
end
resolver = Shirinji::Resolver.new(map)
resolver.resolve(:foo_service).object_id #=> 1
resolver.resolve(:foo_service).object_id #=> 1
resolver.resolve(:bar_service).object_id #=> 2
resolver.resolve(:bar_service).object_id #=> 3
Cache can be reset with the simple command resolver.reset_cache
, which can be
useful when using a development console like rails console (shirinji-rails is attaching cache reset to reload!
command).
Other type of beans
Dependencies injection doesn't apply only to classes. You can actually inject
anything and therefore, Shirinji allows you to declare anything as a dependency.
To achieve that, use the key value
instead of class
.
module MyApp
def self.config
@config
end
def self.load!
@config = OpenStruct.new
end
end
class FooService
attr_reader :config
def initialize(config:)
@config = config
end
end
MyApp.load!
map = Shirinji::Map.new do
bean(:config, value: Proc.new { MyApp.config })
bean(:foo_service, klass: 'FooService')
end
resolver = Shirinji::Resolver.new(map)
resolver.resolve(:foo_service)
#=> <#FooService @config=<#OpenStruct ...> ...>
A value can be anything. Proc
will be lazily evaluated. It also obeys the
cache mechanism described before.
Skip construction mechanism
In some cases, you need a dependency to be injected as a class and not an instance. In such case, you could use value beans, returning the class itself, but you would lose the benefit of scopes (see below). Instead, Shirinji provides a parameter to skip the object construction.
A real life example is a Job where deliver_now
and deliver_later
are
class methods.
map = Shirinji::Map.new do
bean(:foo_job, klass: 'FooJob', construct: false)
end
resolver = Shirinji::Resolver.new(map)
resolver.resolve(:foo_job) #=> FooJob
Scopes
Building complex objects mapping leads to lot of repetition. That's why Shirinji also provides a scope mechanism to help you dry your code.
map = Shirinji::Map.new do
scope module: :Services, suffix: :service, klass_suffix: :Service do
bean(:foo, klass: 'Foo')
# same as bean(:foo_service, klass: 'Services::FooService')
scope module: :User, prefix: :user do
bean(:bar, klass: 'Bar')
# same as bean(:user_bar_service, klass: 'Services::User::BarService')
end
end
end
Scopes also come with an auto_klass
attribute to save even more time for
common cases
map = Shirinji::Map.new do
scope module: :Services,
suffix: :service,
klass_suffix: :Service,
auto_klass: true do
bean(:foo)
# same as bean(:foo_service, klass: 'Services::FooService')
end
end
Scopes also provides an auto_prefix
option
map = Shirinji::Map.new do
scope module: :Services,
suffix: :service,
klass_suffix: :Service,
auto_klass: true do
# Do not use auto prefix on root scope or every bean will be prefixed
# with `services_`
scope auto_prefix: true do
bean(:foo)
# same as bean(:foo_service, klass: 'Services::FooService')
scope module: :User do
# same as scope module: :User, prefix: :user
bean(:bar)
# same as bean(:user_bar_service, klass: 'Services::User::BarService')
end
end
end
end
Finally, for mailers / jobs ..., Scopes allow you to specify a global value
for construct
map = Shirinji::Map.new do
scope module: :Jobs,
suffix: :job,
klass_suffix: :Job,
auto_klass: true,
construct: false do
bean(:foo)
# bean(:foo_job, klass: 'Jobs::FooJob', construct: false)
end
end
Scopes do not carry property access
Code splitting
When a project grows, dependencies grows too. Keeping them into one single file leads to headaches. One possible solution to keep everything under control is to split your dependencies into many files.
To include a "sub-map" into another one, you can use include_map
method.
# dependencies/services.rb
Shirinji::Map.new do
bean(:foo_service, klass: 'FooService')
end
# dependencies/queries.rb
Shirinji::Map.new do
bean(:foo_query, klass: 'FooQuery')
end
# dependencies.rb
root = Pathname.new(File.expand_path('../dependencies', __FILE__))
Shirinji::Map.new do
bean(:config, value: -> { MyApp.config })
# paths must be absolute
include_map(root.join('queries.rb'))
include_map(root.join('services.rb'))
end
Notes
- It is absolutely mandatory for your beans to be stateless to use the singleton mode. If they're not, you will probably run into trouble as your objects behavior will depend on their history, leading to unpredictable effects.
- Shirinji only works with named arguments. It will raise
ArgumentError
if you try to use it with "standard" method arguments.
TODOS
- solve absolute paths problems for
include_map
(instance_eval
is a problem)
Contributing
Bug reports and pull requests are welcome on GitHub at https://github.com/fdutey/shirinji.