Loader vs ES6 Classes

Kevin Smith zenparsing at gmail.com
Sun Aug 3 12:31:46 PDT 2014


I've often wondered why we aren't using inheritance to customize Loaders.
 I'd be interested in the rationale.


On Sun, Aug 3, 2014 at 2:19 PM, John Barton <johnjbarton at google.com> wrote:

> Since I guess not too many developers work with ES6 and the Loader object,
> here is some feedback: the Loader callback design does not play well with
> ES6 classes.
>
> The Loader takes 'options', an object with function properties like
> normalize, locate, and fetch. If you pass a literal object with function
> properties, it works fine.
>
> If you pass an instance of a class, then you discover that the Loader
> calls these functions with 'this' bound to the Loader, not the 'options'
> object.
>
> There isn't a simple way around this as far as I know. The options
> functions don't have access to the options object, only module-state and
> global. So you're stuck with the awkward:
>    var loader = new Loader({
>       normalize: options.normalize.bind(options),
>       locate: options.locate.bind(locate),
>       etc,
>    };
> I guess you can give up on ES6 inheritance and create the hook instances
> by old-school JS, but that is even more annoying.  Or maybe there is
> something else I've not thought of?
>
> jjb
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140803/a94ae78e/attachment.html>


More information about the es-discuss mailing list