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

Add the script tag after-render #48

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

stefanpenner
Copy link
Contributor

@stefanpenner stefanpenner commented May 26, 2017

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.

import { setScriptScheduler } from '...';

setScriptScheduler(function(cb) {
  schedular.scheduleWork('afterContentPaint', cb);
});

cc @scalvert

Copy link
Member

@trentmwillis trentmwillis left a 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);
Copy link
Member

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?

Copy link
Contributor Author

@stefanpenner stefanpenner May 30, 2017

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.

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 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.

@@ -15,11 +15,17 @@ export default nodeLoader(function js(uri) {
return resolve();
}

const script = createLoadElement('script', resolve, reject);
Ember.run.schedule('afterRender', () => {
Copy link
Member

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.

stefanpenner and others added 2 commits August 11, 2017 08:58
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).
@rwjblue
Copy link
Member

rwjblue commented Aug 11, 2017

Rebased this on top of latest master, and fixed the two failing assertions (both around service.loadAsset() rejecting).

@stefanpenner / @trentmwillis - This is ready for another look.

Copy link
Member

@trentmwillis trentmwillis left a 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);
Copy link
Member

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?

@rwjblue
Copy link
Member

rwjblue commented Mar 19, 2018

@stefanpenner - Mind rebasing?

@villander
Copy link
Member

@stefanpenner mind rebasing? please

@stefanpenner
Copy link
Contributor Author

sure

@villander
Copy link
Member

@stefanpenner I'd love to see this merge, you want some help?

@stefanpenner
Copy link
Contributor Author

@villander yes please

@villander
Copy link
Member

@stefanpenner conflicts solved by #81

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.

4 participants