-
-
Notifications
You must be signed in to change notification settings - Fork 259
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix issues with normalization in primary (non-fallback) registry. #113
Fix issues with normalization in primary (non-fallback) registry. #113
Conversation
For those following along in the other issues, in Ember with the following component: export default Ember.Component.extend({
fooBar: Ember.inject.service()
}); When you call |
// but we need to manually recreate them since ApplicationInstance's are not | ||
// exposed externally | ||
registry.normalizeFullName = fallbackRegistry.normalizeFullName; | ||
registry.makeToString = fallbackRegistry.makeToString; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For consistency, we should probably also set registry.describe = fallbackRegistry.describe;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then again, this would not be consistent with the current ApplicationInstance init
(although perhaps that should be updated to include describe
as well?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dgeb - Yes, I saw that and decided to match ApplicationInstance
's init
. This is exactly why I am suggesting a wrapAsFallback
method to Ember.Registry
that is aware of these things. It seems "wrong" that Ember.Application
or ApplicationInstance
(and ember-test-helpers) have to do the internal bookkeeping.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But I'm happy to add describe
here for now, but I really want to make up an API that can be used by all three parties involved here...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated to add .describe
, please let me know what you think of a .wrap
method or somesuch to make this cleaner from ApplicationInstance
/ ember-test-helpers
perspective.
When Ember internally builds a registry via `Ember.Application.buildRegistry` it aliases `registry.normalizeFullName` to `resolver.normalize` and this becomes the fallback registry. Then Ember creates the primary registry (in `ApplicationInstance`'s constructor) and provides the primary registry's resolver (which is `function() { }` to allow for registration overrides) with the original (aka from the `fallback` registry) `normalizeFullName`. Unfortunately, when this was initially implemented in ember-test-helpers this nuance was missed and we subsequently had many issues reported for things that the normalize method would have fixed (specifically converting `service:fooBar` to `service:foo-bar` before looking up). It would be better IMO if `Ember.Registry` could be made aware of this resolver shenanigans, and provide a hook that can be called to "wrapFallbackRegistry" or somesuch so that ember-test-helpers (and `ApplicationInstance` in Ember) do not need to know about these "magic" methods.
4d7d8a5
to
d4f0266
Compare
…gistry Fix issues with normalization in primary (non-fallback) registry.
Released as ember-qunit@0.4.15 and ember-mocha@0.8.5. |
@rwjblue - thanks for adding |
that was quick! 💯 |
@dgeb - Sounds good. |
This does not seem to work if a service is injected via an initializer instead of with The test worked while the service was injected directly in the component. When I changed it so the service was injected via an initializer with |
Initializers are not (and should not be) ran in unit or integration tests. They are only ran when booting a full application (which is what is done in acceptance tests). I would suggest using the Ember.inject syntax for this reason. |
OK, but this means that there is no way to have an integration test for a component which uses a service which has been injected via an initializer? |
Sure there is, run the initializers function manually in that tests In other words, the "happy path" (using |
Great, thanks for clearing this up! Maybe things like this should go in the component test guides? |
@rwjblue can you post some examples . how to inject services , which are injected via intializers in ember . |
Basically, do not inject services in initializers if you want to be able to unit/integration test with them easily. My suggestion above is still the best way forward, to use a service use |
When Ember internally builds a registry via
Ember.Application.buildRegistry
it aliasesregistry.normalizeFullName
toresolver.normalize
and this becomes the fallback registry. Then Ember creates the primary registry (inApplicationInstance
's constructor) and provides the primary registry's resolver (which isfunction() { }
to allow for registration overrides) with the original (aka from thefallback
registry)normalizeFullName
.Unfortunately, when this was initially implemented in ember-test-helpers I missed this nuance and we subsequently had many issues reported for things that the normalize method would have fixed (specifically converting
service:fooBar
toservice:foo-bar
before looking up).It would be better IMO if
Ember.Registry
could be made aware of this resolver shenanigans, and provide a hook that can be called to "wrapFallbackRegistry" or somesuch so that ember-test-helpers (andApplicationInstance
in Ember) do not need to know about these "magic" methods.Fixes #108.
Fixes https://github.com/rwjblue/ember-qunit/issues/200
Fixes https://github.com/rwjblue/ember-qunit/issues/199