Add initialize/1 handler callback

[dvic]

This PR replaces the init/0 callback with initialize/1 (using the old callback still works). In this way, you can for example use ecto dynamic repos with Commanded.Projections.Ecto, e.g.

defmodule Myhandler do
  use Commanded.Projections.Ecto,
    name: "MyHandler",
    repo: MyRepo

  @impl true
  def initialize(state) do
    Ecto.Repo.put_dynamic_repo(state.tenant)
  end
end

[yordis]

Is there any particular reason why it can not be init?

[dvic]

Because there is already an init/1 😅😅

[dvic]

It's rather confusing, init/1 is called to get the config (outside the handler process) and init/0 is called inside the handlers process

[yordis]

So you can not use the existing init function, then?

Also, confusing, I agree!

[dvic]

Yes but then that would be a breaking change, because the meaning (and where the function is called) would have to change. So I thought it would be better to have a new callback, where we get rid of init/0 in the future.

[jvantuyl]

Maybe use a completely different name, like setup/1? At least that doesn't complicate init/* more. Probably should document it, too.

[slashdotdash]

Having three similarly named functions is too confusing (init/0, init/1 and initialize/1).

The init/1 function is called before the event handler process is started to optionally configure the handler with runtime config. This is similar to Ecto Repo's init/2 callback function.

The init/0 function is called within the event handler process after it has started.

We could deprecate the init/0 function and then define a new callback function, such as after_start, which could optionally receive the event handler state?

@callback after_start() :: :ok | {:stop, reason :: any()}
@callback after_start(state :: any()) :: :ok | {:stop, reason :: any()}

For backwards compatibility we could call the init/0 function if it exists.

[dvic]

Having three similarly named functions is too confusing (init/0, init/1 and initialize/1).

The init/1 function is called before the event handler process is started to optionally configure the handler with runtime config. This is similar to Ecto Repo's init/2 callback function.

The init/0 function is called within the event handler process after it has started.

We could deprecate the init/0 function and then define a new callback function, such as after_start, which could optionally receive the event handler state?

@callback after_start() :: :ok | {:stop, reason :: any()}
@callback after_start(state :: any()) :: :ok | {:stop, reason :: any()}

For backwards compatibility we could call the init/0 function if it exists.

That sounds like a good idea! But do we need after_start/0? Because we're introducing a new function anyways, we could just have after_start/1, with a default implementation that does nothing or calls init/0 if it exists. So we would always call after_start/1.