Asynchronous library code load. about airbrake-js

[iainbeeston]

How about something like this? (Uses callbacks to avoid the need for passing params)

https://gist.github.com/b225fc3566e4adcc241a

[benarent]

Hi @iainbeeston I'm open, and I welcome a pull request. Would you be able to show in a demo? View source of blog.airbrake.io/js-test/ for a demo (Note: This has a ton of alpha and other funky stuff)

[iainbeeston]

How about this? http://www.iainbeeston.com/airbrake-test.html (I'm getting xss errors though using the same airbrake credentials as the original blog page)

[benarent]

Hi @iainbeeston . Hit me up on IM, [email protected] I need to make a few tweaks, but I've a notifier that works.

[bluesmoon]

Rather than a simple asynchronous load, I'd suggest going into full non-blocking mode so that server/CDN failure does not block the hosting page from loading. Method described here: http://calendar.perfplanet.com/2012/the-non-blocking-script-loader-pattern/

[vmihailenco]

@duncanbeevers , can you please look at this?

[duncanbeevers]

I personally prefer relying on the browser's handling of the defer attribute, though we should probably add the async attribute as well. As it stands, all the inline code directly addresses creating a shim notifier implementation and not at all with browser-quirks gymnastics.

Anyone else care to weigh in on this?

[bluesmoon]

neither defer nor async will prevent blocking the onload handler. If the server your script is on goes down, this will cause the host page to not complete loading. I'm not sure too many site owners like adding another SPOF to their site, especially one that they cannot control.

The technique I've described above takes you out of the loading queue so that failures in your infrastructure do not affect your customers. It is more effort, but ultimately it's about being a responsible third party.

[duncanbeevers]

The FIF technique requires quite a lot of inline code. @benarent @vmihailenco What do you think of just registering a hook onto window.onload and pulling down the notifier after everything else? Something like this:

// Setup shim
window.Airbrake = [];
window.Airbrake.wrap = function(fn) { return function() {
  try { return fn.apply(this, arguments); }
  catch (exc) { Airbrake.push({error: exc}); throw exc; } }; };
// Invoke script-loader
(function() {
  // We'll do this once the page's onload has fired
  function get() {
    var s = document.createElement('script'),
        p = document.getElementsByTagName('script')[0];
    s.src = 'https://ssljscdn.airbrake.io/airbrake-js-tracekit-sourcemap.min.js';
    p.parentNode.insertBefore(s, p);
  }
  // Attach event handler to window onload
  if (window.addEventListener) { window.addEventListener('load', get, false); }
  } else { window.attachEvent('onload', get); }
}());

[bluesmoon]

That works too, but then you won't capture errors that happen before onload fires.

[benarent]

@duncanbeevers I'm not 100% on this. I'll leave it to you.

[duncanbeevers]

Fortunately the shim implementation can capture and queue up errors that
are later processed by the full implementation.
On Nov 18, 2013 4:01 PM, "Philip Tellis" [email protected] wrote:

That works too, but then you won't capture errors that happen before
onload fires.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-28742523
.

[vmihailenco]

SGTM.

Can I ask you to not "compact" code like that? You hardly save 50 bytes, but reading such code is complicated.

[duncanbeevers]

Addressed by e2629e6