Introduce async support for getHandler #183
Merged
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
trentmwillis
force-pushed
the
get-handler-async
branch
2 times, most recently
from
6462567
to
ecb3051
Compare
trentmwillis
force-pushed
the
get-handler-async
branch
2 times, most recently
from
462ca5e
to
5ba7c53
Compare
trentmwillis
changed the title
trentmwillis
changed the title
|
It would be great if @machty had a chance to review (though not a blocker per-se). |
|
|
||
| return Promise.resolve(this.handlerPromise, this.promiseLabel("Start handler")) | ||
| .then(function(handler) { | ||
| return Promise.resolve(handler) |
There was a problem hiding this comment.
Is this nesting needed? I could be missing something, but I would think this would work:
return Promise.resolve(this.handlerPromise, this.promiseLabel("Start handler"))
.then(checkForAbort, null, self.promiseLabel("Check for abort"))
.then(beforeModel, null, self.promiseLabel("Before model"))
.then(checkForAbort, null, self.promiseLabel("Check if aborted during 'beforeModel' hook"))
.then(model, null, self.promiseLabel("Model"))
.then(checkForAbort, null, self.promiseLabel("Check if aborted in 'model' hook"))
.then(afterModel, null, self.promiseLabel("After model"))
.then(checkForAbort, null, self.promiseLabel("Check if aborted in 'afterModel' hook"))
.then(becomeResolved, null, self.promiseLabel("Become resolved"));There was a problem hiding this comment.
So we can do that, the one issue with that approach (and the reason the code is this way) is if we have an error early on in the chain (for example when checking inaccessibleByURL), then we have to propagate it through the whole chain which is annoying.
29 tasks
| Determines if an object is Promise by checking if it is "thenable". | ||
| **/ | ||
| export function isPromise(obj) { | ||
| return !!obj && (typeof obj === 'object' || typeof obj === 'function') && typeof obj.then === 'function'; |
There was a problem hiding this comment.
Can you tweak to:
return ((typeof obj === 'object' && obj !== null) || typeof obj === 'function') && typeof obj.then === 'function';We would prefer to only do the comparison to null (instead of !!obj) when it is an object.
|
Just a few small nit-pick things, but this LGTM. Can you update those things and squash? |
| Determines if an object is Promise by checking if it is "thenable". | ||
| **/ | ||
| export function isPromise(obj) { | ||
| return ((typeof obj === 'object' && typeof obj !== null) || typeof obj === 'function') && typeof obj.then === 'function'; |
There was a problem hiding this comment.
Should just be obj !== null, not typeof obj !== null
getHandler can now return a Promise for handlers that need to be fetched asynchronously. Two notable differences from the sync case are inaccessibleByURL and intermediateTransitionTo. inaccessibleByURL will now error after going through a loading state since we need to load the handler before being able to determine accessibility. intermediateTransitionTo will assume that the handler is available synchronously as it should be used for error and loading substates.
trentmwillis
force-pushed
the
get-handler-async
branch
from
24c3164
to
02047bd
Compare
Merged
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.
READY FOR REVIEW
In order to support lazy-loading, router.js should not assume handlers returned from
getHandlerwill be present synchronously. This PR introduces support for loading handlers asynchronously by returning a Promise from thegetHandlerfunction.A common response to this idea is why not load handlers upfront? The reason to avoid loading handlers upfront is that they have the potential of being stateful and dependent on other constructs. This introduces a dependency tree that also must be loaded upfront with the handler, thus potentially negating the benefit of lazy loading.
This implementation reuses all existing tests that defined a
getHandlermethod and has them passing while returning a Promise-based handler instead. One callout here is thatintermediateTransitionTopasses under the assumption that it is used to transition into a synchronously loaded route.TODO: