@benboecker great work! However falling back to UIApplication.shared.container may lead to the wrong container in a lot of cases:
what if the application does not set an container?
what if the application uses a different container within a storyboard?
That is indeed a Problem. We need to find the correct container from within our extensions on the component. The easiest way would be to add an associated object reference to the container - however that would break with the idea that an component has only access to the dependencies it really needs.
I would prefer a stricter way: the container should keep a static, weak-referencing list of all instantiated components together with the container instance it originated from. Then we can move your containerHasDependencyForType implementation to a static method on Container.
That solution keeps the "container-component-barrier" intact and solves the Problem.
@benboecker great work! However falling back to UIApplication.shared.container may lead to the wrong container in a lot of cases:
That is indeed a Problem. We need to find the correct container from within our extensions on the component. The easiest way would be to add an associated object reference to the container - however that would break with the idea that an component has only access to the dependencies it really needs.
I would prefer a stricter way: the container should keep a static, weak-referencing list of all instantiated components together with the container instance it originated from. Then we can move your
containerHasDependencyForTypeimplementation to a static method on Container.That solution keeps the "container-component-barrier" intact and solves the Problem.
You or me? :)