Suggestions for provider container terminology

proposals
1

Hey all. :wave: This is an extraction of conversation originally discussed in this logger backends issue with Peter and Tim regarding provider container terminology.

I’ve been struggling with the use of target and container when inside my provider lifecycle blocks and was hoping to spawn further discussion around this terminology to help make working within a provider easier to intuit. For more context, consider current behavior (with lightweight truncation of output):

Hanami.app.register_provider :debug do
  prepare do
    instance_variables  # [:@__config__, :@callbacks, :@provider_container, :@target_container]
    target              # Demo::Container (a.k.a. @target_container)
    target_container    # Demo::Container (alias to `target`)
    container           # #<Dry::Core::Container @_container={}> (a.k.a. @provider_container)
    provider_container  # #<Dry::Core::Container @_container={}> (alias to `container`)
  end
end

Here are some suggestions:

  • Rename target as app_container so it’s easier to intuit you are dealing with the primary application container.
  • Leave container as container because it’s relative to the current provider which is starting to make sense (at least to me).

Here are some additional thoughts from Tim for further thought but also providing space for Tim to elaborate on more when he frees up:

If we can have Hanami provide its own dry-system provider source implementation (per my thoughts above), then we can just make it named “slice” (and additionally app when we know the provider is being registered with the app) as an alias of target.

There’s are good reasons these two different containers exist for each provider, and I just need to fine the time to write it down :weary:. For example, we need them to support providers registered with a namespace. And they open up a range of interesting use cases where external provider sources are used and then the user of that provider source can more exactly control what eventually gets registered in the target container. FWIW, the multiple containers were not actually my invention! So this is definitely not me here trying to defend my “baby.” In fact, during my big dry-system refactors of 2021/2022 I tried to remove the provider container, and only in doing that did I realize its usefulness.

I only wanted to extract this information out of the original log issue and into a discussion for Tim and others to elaborate on this more. I’m eager to learn more and/or help where possible. :bow:

1 Like
2

How about…just app. In general, we have app expose some of the container interface, so this would make sense (because duck typing). Another option is to actually expose app using a custom provider implementation for Hanami.

3

Yeah, so app and container because you’d only ever be interacting with those two containers within the provider scope? I think that makes sense. The use of app terminology is slightly overloaded since it’s used in different contexts (especially via Hanami.app) but as long as you think in terms of app – as a container – relative to the current scope of the provider I think that would work. It’s also nice that not much else is exposed while within the scope of the provider blocks too which simplifies things further.