How to dynamically inject the implementation for ZIO with MacWire

In my last Blog I tried to decouple the Program from its Implementation — see here.

This is a follow up to the question: How to wire the implementation dynamically on application start (defined in a configuration file).

Photo by Rahul Bhogal on Unsplash


Here we take PureConfig that we already used in the last blog.

The configuration is described in a Case Class:

case class MyConfig(compsImpl: String)

The accordingapplication.conf looks then:

comps-impl = "pme123.zio.comps.yaml.YamlComps"

Because it can throw an Exception, we provide a function that wraps the creation of MyConfig in a ZIO.effect. As we us the default (application.conf), ConfigSource.default is all we need.

def config[T]: Task[T] = ZIO.effect(ConfigSource.default.loadOrThrow[T])

Dependency Injection

First we need a simple Dependency Injection library. I pick MacWire, as I wanted to check it out anyway and libraries from SoftwareMill never let me down;).

Following the instructions on Accessing wired instances dynamically, we can now provide a simple function that creates an Instance T from a Class name. Again wrapped in a ZIO.effect just in case.

Create the Environment

This is the way we provided the Implementation statically in a zio.App:

new Console.Live with HoconComps {}

And here the problems start. There is no way we can inject HoconComps, as it is a Trait. Or does anyone know?

This means we have to refactor our whole project and use the standard way of ZIO handling dependencies.

What we do here is providing an implementation that delegates the work to the actual Service; a real Implementation that we can inject. It is actually the same Type (Components.Service) as we have implemented in the Live Trait.

With this, we can now provide our environment:

Adjust the Implementations

The two implementations extend now directly the Service:

class HoconComps extends Components.Service[ComponentsEnv]

So the only change is to move both functions, and we are done . See here the Commit.


Photo by Carl Nenzen Loven on Unsplash

It was not possible to have dynamic dependency injection with my first solution.

New we implement just a Service not the whole Module. This sounds ok, despite the additional indirection.

However that has one big disadvantage: We have to define the environment for all Service implementations. So for example if one of them wants to use Random, it is not possible, as we only provide Console.


The Project to this Blog: zio-comps-module




Let me know if you have questions or stuff that can be done better!

Check also out: How you can use the same Test for different Implementations

Working for in the Banking business. Prefer to work with Scala / ScalaJS.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store