-
Notifications
You must be signed in to change notification settings - Fork 27
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
Add the script tag after-render #48
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't say it is "kinda strange", it is just the simple approach. The current approach doesn't cause any abnormal behavior, but it is likely non-optimal.
Should we do the same thing for CSS loader? It likely isn't as big of a deal as loading JS mid-run-loop, but seems like it may still be beneficial.
document.head.appendChild(script); | ||
document.head.appendChild(script); | ||
} catch(e) { | ||
reject(e); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What error would we expect to happen here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
none, this is to handle the exceptional cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also maintains existing behavior. Currently if any of those lines error, the promise constructor will catch them. As this PR moves them to be async, we must manage that ourselves.
addon/loaders/js.js
Outdated
@@ -15,11 +15,17 @@ export default nodeLoader(function js(uri) { | |||
return resolve(); | |||
} | |||
|
|||
const script = createLoadElement('script', resolve, reject); | |||
Ember.run.schedule('afterRender', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should add a comment as to why this afterRender
is present.
We cannot simply return the promise in the failure scenarios (since returning a rejected promise will fail the test). I have added back a small assertion confirming the rejections in cases we _know_ should reject. The CSS load failure scenario is a bit annoying/odd because we cannot guarantee that we fail properly when the asset cannot be loaded (due to lack of browser support for `onload`/`onerror` callbacks with the `<link>` element).
9a84986
to
96f90e8
Compare
Rebased this on top of latest master, and fixed the two failing assertions (both around @stefanpenner / @trentmwillis - This is ready for another look. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One small nitpick, but otherwise looks good to me!
@@ -19,34 +20,46 @@ export default nodeLoader(function css(uri) { | |||
return resolve(); | |||
} | |||
|
|||
// Try using the default onload/onerror handlers... | |||
const link = createLoadElement('link', resolve, reject); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why move this declaration outside the block where it is initialized?
@stefanpenner - Mind rebasing? |
@stefanpenner mind rebasing? please |
sure |
@stefanpenner I'd love to see this merge, you want some help? |
@villander yes please |
@stefanpenner conflicts solved by #81 |
Kinda strange to add to the DOM during just any period, we likely want this to always happen when stuff has settled down.
In-theory this could be made pluggable, allowing an application to provide an alternative schedular.
cc @scalvert