Clean up boot process #10271
Merged
Clean up boot process #10271
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| @@ -256,28 +256,27 @@ var Application = Namespace.extend(DeferredMixin, { | |||
| init: function() { | |||
| this._super(); | |||
There was a problem hiding this comment.
this._super.apply(this, arguments);
There was a problem hiding this comment.
Hm. This code is not in a change in this commit.
wagenet
added
Needs Label Review
Cleanup
Needs Code Review
and removed
Needs Label Review
labels
|
@rwjblue asked for a diagram of this change, thought it might be useful for others. |
This is the beginning of a refactor that improves the clarity and explicitness of the Application boot process. In particular, it takes advantage of the previous ApplicationInstance refactoring, and explicitly exposes boot phases via promises. The end-game here is to allow FastBoot to boot up an application but not create an application instance, and allow individual FastBoot requests to create instances on demand. This will also help the testing infrastructure, which also wants to boot an application once for the entire test suite, and create an instance for each test run.
Shout out to @rwjblue
This test had its heart in the right place, but the semantics it actually exercises are unimportant and simply tested the side-effects of a previous implementation. To wit, this test sets the application’s location to `none`, yet still expects the application’s `rootURL` to be injected on _any_ arbitrary location looked up via the container. Under the hood, the router registered a private (dash-prefixed) injection, so we feel confident we can refactor the internal implementation without breaking any apps. In short, this test was testing the side-effects of a private injection, which we are eliminating, while retaining the public API it supported.
A registry's fallback registry resolves registrations and injections when no matches can be found.
The instance's registry sets its fallback to the corresponding application's registry.
Ensure that `name` and `type` are valid after initial parsing and before any post-parsing mutations might be performed. This fixes a problem in which mutations are performed to the cached object (e.g. "route:basic" -> "route:") and then the validation of the mutated object fail when it's accessed a second time. It's also more efficient, since validation only occurs once.
| // decremented by the Application's own `initialize` method. | ||
| this._readinessDeferrals = 1; | ||
|
|
||
| if (!Ember.FEATURES.isEnabled('ember-application-visit') || this.autoboot) { |
There was a problem hiding this comment.
The feature flag system cannot handle this properly.
It must be precisely:
if (Ember.FEATURES.isEnabled('ember-application-visit')) {
/* stuff when enabled */
} else {
/* stuff when disabled */
}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This refactor improves the clarity and explicitness of the Application boot process. In particular, it takes
advantage of the previous ApplicationInstance refactoring, and explicitly exposes boot phases via promises.
The end-game here is to allow FastBoot to boot up an application but not create an application instance, and allow individual FastBoot requests to create instances on demand via the
visit()API.This will also help the testing infrastructure, which also wants to boot an application once for the entire test suite, and create an instance for each test run.