Construire ma bibliothèque JS, quelques questions

Question

Je construis une bibliothèque (https://github.com/OscarGodson/storageLocker), une enveloppe de localStorage pour être plus exact, mais parce que ceci est mon premier essai à OO JavaScript Je suis encore à apprendre et j'ai ou deux questions.

1. Je l'ai vu dans d'autres bibliothèques que parfois ils les envelopper dans une fonction anonyme. Dois-je, ou devrais-je, faire avec cela? Et si oui, comment sans casser quoi que ce soit?

2. Pour l'API interne (essentiellement, les fonctions internes) comment dois-je les écrire? Devrait les ajouter à l'objet principal par exemple storageLocker.prototype.myInternalFunction() ou tout simplement myInternalFunction() au hasard dans mon script? Je ne voulais pas les fonctions à bien globale ... L'une des fonctions par exemple seulement les chèques un tas d'éléments dans le JSON, voit si leurs objets, et vérifie ensuite ce que le type d'objet est (comme Date()) puis convertis il.

3. Comment / où dois-je ajouter mondiale, à mon script, vars? par exemple. J'ai appelé var patterns qui est quelque chose comme var patterns = {"date":/\/Date\(([0-9]+)\)\//} comment dois-je ajouter que dans mon script?

Merci beaucoup. Je veux écrire mon script chemin si im vous demander les gars. Je ne connais pas de gars JS localement qui font tout OO JS, ils sont tous les anciens types d'écoles ...

Answer 1

  

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

a une section décente sur la lecture de la valeur des espaces de noms.

  

http://yuiblog.com/blog/2007/06/12 / module de configuration /

est également une autre bonne vue d'ensemble.

Pour le matériel plus grand sur les bonnes pratiques de javascript, consultez

  

http://javascript.crockford.com/

Après notre discussion dans les commentaires, je l'ai changé l'exemple à ceci:

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);

Bien que ce n'est pas exactement un exemple d'une bibliothèque / module (parce que vous avez accès au code en appelant le constructeur directement), il est un exemple de garder le même objet dans la portée de plus des méthodes chaînage. En fait, il ne revient pas l'objet storageLocker, il est de retour l'objet « public », mais cet objet a accès à la portée du storageLocker par la fermeture.

Il pourrait y avoir d'autres meilleures façons de le faire par peut-être retourner l'objet storageLocker lui-même, mais cela nécessiterait un peu plus penser à travers.

Answer 2

Je dirais:

1) le but de cette technique est pollue l'espace de noms global. C'est une bonne chose.    Dans l'exemple ci-dessous vous pouvez voir que toutes vos interactions avec la bibliothèque se fait par un MyLibrary objet. API publique est la valeur de retour de la fonction anonyme.

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) voir aussi l'exemple ci-dessus sur la façon de placer les fonctions « internes »

3) si vous variable globale est une sorte d'une option de configuration, je viens de faire setter / getter public et gardé la variable "privée"