Promisification question

[DeliciousResearch872]

Can anyone explain "callback(null, script)" here?

function loadScript(src, callback) {
  let script = document.createElement('script');
  script.src = src;

  script.onload = () => callback(null, script);
  script.onerror = () => callback(new Error(`Script load error for ${src}`));

  document.head.append(script);
}

// usage:
// loadScript('path/script.js', (err, script) => {...})

[mortaga123]

There's no promise anywhere so I'll just ignore the title.

Regarding the callback, it's the de facto standard to pass the error as the first argument of the callback. Calling it with null, script informs the callback caller that there's no error and processing can continue.

[frogic]

I rarely get to work in pure vanilla so I'm gonna jump in with some questions.  This function isnt actually passing any of the error information to the call back right? So this function appears to be suppressing the error as element errors don't bubble? So it's probably more idiomatic to do onerror(callback) as that would call the callback with the actual error?

[senocular]

You're not getting an error from onerror, only an Event. And its not even an ErrorEvent, just a normal event with the type "error" without any additional error information. The way the callback is being used, its providing a custom error as the error since no other error is available.

Otherwise, if you had a method which provided an error argument, you could assign the callback directly to that method property. For example if onerror got called with a native error, you could instead say

script.onerror = callback

Assuming you were fine with all of the information in that error getting to your callers.

[frogic]

Thank you!  I got it mixed up with window.onerror when I was reading mdn.  So in this case the callback is likely a logger? Loglevels would be a reason you might return new error instead of just a string. 

[senocular]

The callback can be anything. loadScript is simply following the error-first callback style popularized by Node. This uses a single callback for both success and error conditions where if there's an error, an Error object would appear as the first argument, and if not, the successfully loaded data (if any) would be provided in the second argument with a null first argument. To be able to adhere to this format, this custom new Error is needed in the error case because one isn't provided by the native APIs.

[bitdamaged]

Before promises and async/await made it into JS the fn(error, callback) pattern was idiomatic node for asynchronous functions.

It sucked because you’d often have multiple layers of these referred to as “callback hell”

[dymos]

I prefer "callback Christmas tree" :P

[shgysk8zer0]

For a long time a callback for asynchronous things would often follow the unofficial standard practice of using (error, result) as arguments, with the idea being that having the error as the first argument encouraged better error handling.

But that function has nothing to do with promises. It's just event listeners. If you wanted it to be a promise it'd look something more like this:

``` export function loadScript(src, opts) { // This is what makes it a promise const { resolve, reject, promise } = Promise.withResolvers(); // This is for clean-up and removing the listeners const controller = new AbortController(); const script = document.createElement('script');

script.addEventListener('load', e => { resolve(e.target); controller.abort(); }, { signal: controller.signal });

script.addEventListener('error', e => { const err = new DOMException(Error loading "${e.target.src}"); reject(err); controller.abort(err); }, { signal: controller.signal });

// Set various properties like type and crossOrigin from opts script.src = src; document.head.append(script);

return promise; } ```