The library keeps container to be idiomatic. That means container should not know anything about how it is used and how some dependencies are injected.
All items in the container are singletons until they will be explicitly released.
However it is obvious that we cannot use only globally created containers ignoring request-context on the server or rendering-context on the client.
So, there is a way how context could be considered with true-di:
let's create a container as part of context (idealy the container should be a context).
let's compose containers to create subcontext-related container based on the higher-context container.
Example 1. Container Factory
Let's guess we need to log each request query and some of header, so we should provide correspondent data to the constructor of Logger:
However if globalContainer has a lot of items those should be inherited by the requestContainer to write a lot of new factories could be very annoying.
Example 3. Narrowing container
In the previous example we extend global container by adding two services on the request container.
This example shows how to narrow container for some specific routes:
Define container factory function to create request level container: