Options and injections from a fallback registry must also be applied to an instantiation.
@dgeb It seems like two other directions to go would be to create a FallbackableRegistry that wraps registries and only manages the fallback part of the work. I'm not sure there is a lot of value in that.
Oddest thing about this change is that while registrationOption will return the singleton state taking the fallback into consideration, the registrationOptions API will not. The latter (and registrationInjections which is also make fallback compatible) are both used in Ember tests, but not on any public APIs. Perhaps we can just not expose some of this, and keep all APIs fallback safe.
While integrating with Ember it quickly became clear the fallback semantics of https://github.com/glimmerjs/glimmer-di/pull/34 were vastly under-powered.
Options and injections from a fallback registry must also be applied to an instantiation.
@dgeb It seems like two other directions to go would be to create a
FallbackableRegistrythat wraps registries and only manages the fallback part of the work. I'm not sure there is a lot of value in that.Oddest thing about this change is that while
registrationOptionwill return the singleton state taking the fallback into consideration, theregistrationOptionsAPI will not. The latter (andregistrationInjectionswhich is also make fallback compatible) are both used in Ember tests, but not on any public APIs. Perhaps we can just not expose some of this, and keep all APIs fallback safe.