Skip to content
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

Re-registration by initializers on App.reset #12231

Closed
trentmwillis opened this issue Aug 28, 2015 · 8 comments
Closed

Re-registration by initializers on App.reset #12231

trentmwillis opened this issue Aug 28, 2015 · 8 comments

Comments

@trentmwillis
Copy link
Member

While looking into using App.reset() for acceptance tests, I stumbled onto this error:

Error: Cannot re-register: `service:-routing`, as it has already been resolved.

It seems the root cause is if you use the routing service (e.g., in a link-to) it gets cached in the application registry and then when you restart, it is picked up by the initializer running again and throws the error. I worked around that particular instance only to have a similar issue crop up with registration of transforms by Ember Data.

I'm wondering if re-running initializers should be part of resetting an application. I feel like semantically, only instance initializer should be re-ran. Thoughts? It seems like we could get some faster test times without having to completely recreate the application each time, but this blocks us from being able to use new instances right now.

Here's a super simple repro case: JSBin

@rwjblue
Copy link
Member

rwjblue commented Aug 31, 2015

I feel like semantically, only instance initializer should be re-ran.

I agree.

@stefanpenner
Copy link
Member

app instances and app.reset are two different things.

App.reset is older and is more or less meant to rebuild everything while preserving the namespace. This is to support globals, which used the namespace to store various factories.

In a world of modules the namespace doesn't need to be perserved.

The app.visit + appInstance work exists to replace for both SSR and testing. In the world of appInstances, instance vs non instance initializers actually have meaning.

–––

If you are trying to make tests faster, fixing the appInstance path is going to be the best path forward. As this is actually its intended design.

It is also important that our SSR use-cases, and general app testing are as close as possible. So having testing use the same path, will be net positive.

@rwjblue
Copy link
Member

rwjblue commented Aug 31, 2015

I believe that the acceptance test helpers in ember-testing will need some significant work to make compatible with living on ApplicationInstance instances, but that is likely the best path forward IMHO.

aka, what Stef said 😺

@stefanpenner
Copy link
Member

That being said App.reset should work, as it should blow away and rebuild the original registry.
It's worth noting, this likely wont give you the perf you want as that is what the appInstances work is for.

This may have been a regression, @dgeb anything come to mind?

@rwjblue
Copy link
Member

rwjblue commented Aug 31, 2015

@stefanpenner - I have a fix for that bit (basically we need to not be using initializers internally for this) incoming.

@stefanpenner
Copy link
Member

@rwjblue 👍

@trentmwillis
Copy link
Member Author

Thanks for the clarification everyone. I'm glad this issue is getting addressed, but will look into the appInstance approach for test perf improvement instead.

@rwjblue do you have any thoughts on how to refactor the test helpers to support using instances? I took a look, and they seem fairly bound to the application itself. I'd be more than happy to pursue whatever work needs to be done to get them working.

@stefanpenner
Copy link
Member

@trentmwillis sorry for the upfront confusion, i hope my explanation made sense. I can gladly provide more context if you are interested. I would love to see all our efforts aligned

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants