Building my JS library, a couple questions

Question

I'm building a library (https://github.com/OscarGodson/storageLocker), a localStorage wrapper to be more exact, but because this is my first try at OO JavaScript I'm still learning and I have a couple questions.

1. I've seen in other libraries that sometimes they wrap them in a anonymous function. Do I, or should I, do that with this? And if so, how without breaking anything?

2. For the internal API (basically, the internal functions) how should I write them? Should add them to the main object e.g. storageLocker.prototype.myInternalFunction() or just myInternalFunction() randomly in my script? I didn't want the functions to be global though... One of the functions for example just checks a bunch of items in the JSON, sees if their objects, and then checks what the object type is (like Date()) and then converts it.

3. How/where should I add global, to my script, vars? e.g. i have a var called patterns that is something like var patterns = {"date":/\/Date\(([0-9]+)\)\//} how should I add that into my script?

Thanks a lot. I want to write my script the right way so im asking you guys. I don't know of any JS guys locally that do any OO JS, they're all old school types...

Answer 1

http://nefariousdesigns.co.uk/archive/2010/10/object-oriented-javascript-follow-up-part-2-technical/

has a decent section on namespacing worth reading.

http://yuiblog.com/blog/2007/06/12/module-pattern/

is also another good overview.

For more great material on good javascript practices, check out

http://javascript.crockford.com/

After our discussion in the comments, I've changed the example to this:

var storageLocker = function (selector) {

    var _selector = selector || "default value";

    function myPrivateFunction() {

    }

    var public = {

        get: function () {
            return _selector;
        },

        uppercase : function () {
            _selector = _selector.toUpperCase()
            return this;
        }

    }
    return public;

};

// use:
var test = storageLocker("search for this").uppercase().get();;

alert(test);

While this isn't exactly an example of a library/module (because you're accessing the code by calling the constructor directly), it is an example of keeping the same object in scope for further chaining of methods. Actually it's not returning the storageLocker object, it's returning the 'public' object, but that object has access to the storageLocker's scope through closure.

There could be other better ways to do this by perhaps returning the storageLocker object itself, but that would require a bit more thinking through.

Answer 2

I'd say:

1) the purpose of this technique is not pollute the global namespace. That is a good thing. In the example below you can see that all your interaction with the library is via one object MyLibrary. Public API is the return value of the anonymous function.

var MyLibrary = function() {
// private
   this.InternalVariable = 'some value';

   function internalFunction(x,y) {
      return x + y;
      }

     function getInternalVariable() {
    return this.InternalVariable;
}
// public
   return {
      publicVariable : '1.0',
      publicFunction : function(x,y) {
         return x + y
         },
 accessInternalVariable : function() {

     return getInternalVariable();
     }
      }
   }();

2) see also the example above on how to place your "internal" functions

3) if you global variable is some kind of a configuration option, I'd just make public setter/getter and kept the variable "private"