Dependency injection/IOC

I just pass modules as a function arguments where needed. In other cases I just do not bother at all.

In which cases would you pass a module as an argument? Do you mean a module when it’s a GenServer?

I think an example of this would be Ecto. In cases like Ecto.Multi, the repo module is passed around so you can make sure you’re using the same repo during a transaction: Ecto.Multi — Ecto v3.14.0

A case where I did that was when doing something similar to the strategy pattern, I had many modules that were candidates to perform a given action, and when one of them was picked, I passed them around to the functions that would use it

For sure I do this: if you want to achieve testable code, it’s quite handy to be able to “inject” overrides as options. E.g. something like the following:

def fetch_page(url, opts \\ []) do
    parser = Keyword.get(opts, :parser, SomeParserModule)
    client = Keyword.get(opts, :client, HTTPoison)
    with {:ok, raw_html} <- client.get(url), 
        {:ok, parsed} <- parser.parse(raw_html) do
        {:ok, struct(SomeStruct, parsed)}
    end
end

This is over-simplified, perhaps, but if you don’t want to redundantly test a separate module that receives dispatches, then providing an injectable/overridable option lets you focus on one layer/module at a time.

Some purists may argue that this isn’t the same as DI, but it accomplishes the same goals and has the same intent as far as I’m concerned. Mox is certainly helpful in this regard, but it’s not strictly required.

Beware that this approach converts compile-time errors (like passing the wrong number of arguments to a function) to runtime errors, and substantially reduces the usefulness of Dialyzer.

Wrapping the call can help some:

def fetch_page(url, opts \\ []) do
  with {:ok, raw_html} <- client_get(url, opts),
  ...
end

@spec client_get(String.t(), Keyword.t()) :: {:ok, String.t()} | {:error, any()}
defp client_get(url, opts) do
  client = Keyword.get(opts, :client, HTTPoison)
  client.get(url)
end

This allows Dialyzer to understand the type of client_get - but there is no checking that the type written in the @spec matches the types actually seen at runtime.

Usually, we have a Client behaviour here, declaring a type, and refine the spec to

@typet opts [{:client, Client.t()} | {atom(), any()}]
@spec client_get(String.t(), opts()) :: {:ok, String.t()} | {:error, any()}

There are libraries that have different “adapters” for use in production, development, and test environments. This is sort of similar to dependency injection.

Take the Swoosh hex library for sending emails. You set the adapter (a module that follows a behaviour) in configuration. In production, you choose an adapter corresponding to your email service — say, the SendGrid adapter. In test, you use the Test adapter which is wired up to allow you to perform assertions on whether an email was sent and if it contained the right data. In development, you use a special adapter that captures “sent emails” in memory in a process, so that you can go to a special local route and view what would have been sent were it production.

I think this is a problem of how to ensure the passed-in module has the expected @behaviour using typespec.

Freud intensifies :-))))

I was a fan of dependency injection containers when I was working with object-oriented web frameworks. Alternatives were a service locator or a global registry/singleton, which were both considered anti-patterns. When you work with a DI container, your classes typically keep the dependencies as state in the constructors.
In Elixir we just don’t need those anymore, it’s a just a different way of thinking and designing. We use config and functions arguments.

Even though the OP didn’t mention containers, I believe dependency injection is more talked about in OOP because it is harder to achieve.

And as an example of how DI is achieved in Elixir, take the injection of a time zone database to DateTime functions:

• via configuration:

config :elixir, :time_zone_database, Tz.TimeZoneDatabase

or:

Calendar.put_time_zone_database(Tz.TimeZoneDatabase)

• by passing the module name to the different functions:

DateTime.now("America/Sao_Paulo", Tz.TimeZoneDatabase)