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

[BUGFIX release] Avoid creating event dispatcher in FastBoot with Engines #15695

Merged

Conversation

rwjblue
Copy link
Member

@rwjblue rwjblue commented Oct 3, 2017

Prior to this commit, the event_dispatcher:main was always being instantiated so that it can be injected eagerly into child engines. In general, this is good (we should only ever have a single event dispatcher going) but in the FastBoot case the event dispatcher should not have been created at all (since there is no DOM or interactivity booting the event dispatcher to listen to DOM events is wasteful and error prone).

This commit updates the EventDispatcher base class to properly look for the isInteractive flag (which is what it should have been doing all along) on the -environment:main that is injected from the Application.visit API. When isInteractive is falsey and the event dispatcher is instantiated we will issue an assertion.

We also avoid eagerly looking up (and therefore forcing to initialize) the EventDispatcher if .visit API is passed isInteractive: false. This avoids the specifically reported issue of triggering an assertion in FastBoot mode.

Fixes #15615

…ines

Prior to this commit, the `event_dispatcher:main` was always being
instantiated so that it can be injected eagerly into child engines. In
general, this is good (we should only ever have a single event
dispatcher going) but in the FastBoot case the event dispatcher should
not have been created at all (since there is no DOM or interactivity
booting the event dispatcher to listen to DOM events is wasteful and
error prone).

This commit updates the EventDispatcher base class to properly look for
the `isInteractive` flag (which is what it should have been doing all
along) on the `-environment:main` that is injected from the
`Application.visit` API. When `isInteractive` is falsey and the event
dispatcher is instantiated we will issue an assertion.

We also avoid eagerly looking up (and therefore forcing to initialize)
the EventDispatcher if `.visit` API is passed `isInteractive: false`.
This avoids the specifically reported issue of triggering an assertion
in FastBoot mode.
@rwjblue rwjblue force-pushed the avoid-event-manager-in-non-interactive branch from 1d698d6 to 6e9a9c1 Compare October 3, 2017 03:05
@rwjblue rwjblue merged commit 20f0ddd into emberjs:master Oct 4, 2017
@rwjblue rwjblue deleted the avoid-event-manager-in-non-interactive branch October 4, 2017 14:05
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.

1 participant