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

Consistently use the new view registry #90

Merged
merged 1 commit into from
Jul 28, 2015
Merged

Conversation

ef4
Copy link
Contributor

@ef4 ef4 commented Jul 28, 2015

Internally, the EventDispatcher looks for the global view registry on the container and then falls back to using View.views. Since we were creating it directly instead of via the container, it had no container reference, and so it was doing all view tracking using the fallback.

This is problematic, because the global fallback path is now only accessible from inside Ember (by design, because we're trying to eliminate it.)

var viewRegistry = this.container.lookup('-view-registry:main');
if (viewRegistry) {
var View = Ember.__loader.require('ember-views/views/view').default;
View.views = viewRegistry;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking up the EventDispatcher from the container (as you changed above), should be sufficient to ensure that it internally has access to -view-registry:main, we should not need to set the internal Ember.View.views.

Was this left over from before you changed context.dispatcher to be looked up?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, this was necessary. Ember is internally using the View.views list still, and it only copies that list out of the container during app instance initialization.

Our integration tests don't go down that initialization path.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In all cases Ember should be using -view-registry:main then falling back to its internal View.views. The -view-registry:main is setup during Ember.Application.buildRegistry (injection is setup directly below) which we are calling from here. Since the EventDispatcher is now being looked up from the container (from the other changes in this PR) that is built with -view-registry:main it will be have a container and be able to do this.container.lookup('-view-registry:main') (here).

Where in Ember are we still using View.views without checking -view-registry:main first?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I think I see the problem. ember-test-helpers is doing a Component.create, and although it passes in a container, that is insufficient.

To play nicely with dependency injection, ember-test-helpers should be doing lookupFactory instead. Is there a generic component factory available? Something equivalent to the old view:default?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I don't think something like that exists, but the following code should work for us here:

var thingToRegisterWith = this.registry || this.container;
thingToRegisterWith.register('component:-template-under-test', Ember.Component.extend({
  layout: template
});
module.component = this.container.lookup('component:-template-under-test');

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This gets weirder. Even if I use lookupFactory, _viewRegistry is only injected onto things registered as view:foo, not things registered as component:foo. That seems like a potential Ember bug, although it doesn't effect a normal app since they use view:toplevel (not component:toplevel, and then each view inherits a viewRegistry from its parent.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I agree that this should be fixed upstream in Ember (we should inject -view-registry:main into both view and component), but the solution with the smallest amount of change might just be:

module.component = Ember.Component.create({
        layout: template,
        container: module.container,
        _viewRegistry: module.container.lookup('-view-registry:main')
      });

We should still fix that injection upstream though....

@rwjblue
Copy link
Member

rwjblue commented Jul 28, 2015

I'd like a test that we can use to help prevent regressions here. Seems like this bug prevents testing of event dispatcher handled events, right? I can try to PR a test against your branch if you'd like...

@ef4
Copy link
Contributor Author

ef4 commented Jul 28, 2015

We actually have test coverage for event dispatching, and the bug wasn't breaking the tests because it was canceling itself out. All the views were being placed on View.views, and that's where the event dispatcher was expecting to find them.

I only noticed a problem due to ember-mobiletouch failing to find this.container in the event dispatcher.

So I don't see a good test for this condition that doesn't peek into internals and test things that don't really matter to users. This issue was really about upgrading the test helpers to use newer internals.

rwjblue added a commit that referenced this pull request Jul 28, 2015
Consistently use the new view registry
@rwjblue rwjblue merged commit 1b237f2 into emberjs:master Jul 28, 2015
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

Successfully merging this pull request may close these issues.

2 participants