views:

30

answers:

1

What is the best way to create library agnostic wrapper for JS library selectors? I have a custom JS framework, that aims to be as library-agnostic as possible. The problem I have is that for example Mootools enhances the returned DOM element with it's own specific methods (inject, adopt etc.), and I don't want these to be visible to the modules, layered on top of the framework (as Nicholas Zakas once described), to prevent misuses/accidents.

As a simple first-aid I created a custom selector that uses Mootools, it then creates custom Element -object/wrapper and hands selected (and enhanced) Mootools DOM element to it, thus the Mootools enhanced methods are not directly visible to the modules above. The problem with this approach is that I lose all the native functionality of the DOM element (value, style etc.) if it's not specifically coded to the wrapper (Element).

Is there another and/or better way to do this? Something that would extend the native DOM element, thus providing the native properties/methods automatically AND offering advanced functionality through the wrapper (via Mootools, jQuery, whatnot...).

Some example code, how it's currently done:

/*
 * Wrap the native library element
 */
Element = function(_libElement) {
    // Store native object
    var libElement = _libElement;

    return {
        addClass: function(_class) { libElement.addClass(_class); return this; },
        removeClass: function(_class) { libElement.removeClass(_class); return this; },
        hasClass: function(_class) { return libElement.hasClass(_class); }
    };
};

/*
 * Custom selector
 */
getElement = function(_query) {
    var elements = $$(_query);

    // Wrap each element to Element wrapper
    var num = elements.length;
    while(num--) {
        elements[num] = new Element(elements[num]);
    }

    return elements;
};
+1  A: 
T.J. Crowder
That would be the idea exactly, to prevent the use of library specific enhancement. I feel that such approach (just handing over the native library element) would be quite sloppy implementation and would end up causing problems down the line (lines which by accident end up using the library instead directly) when switching from one library to another. The framework is strictly in-house currently so all the code will be written as library agnostic from the get-go.
crappish
@crappish: But you're *not* being library-agnostic if you're preventing use of libs that extend DOM elements; you're being biased against some libraries in favor of others. But if you really want to go down that road, you have no choice but to use a wrapper and prevent clients using the raw DOM element. That's going to be expensive, because if you're hiding the element, then *everything* has to be through your wrapper, every property and function. It'll be a maintenance hassle to say the least. (Cont'd)
T.J. Crowder
(continuing) I prefer jQuery's approach: You get a wrapper, 99% of the time it's all you need, but you can get the raw element if you need it.
T.J. Crowder