Costruire la mia libreria JS, un paio di domande

Question

Sto costruendo una libreria (https://github.com/OscarGodson/storageLocker), un wrapper localStorage per essere più precisi, ma poiché questo è il mio primo tentativo con OO JavaScript, sto ancora imparando e ho un paio di domande.

1. Ho visto in altre librerie che a volte le racchiudono in una funzione anonima.Devo o dovrei farlo con questo?E se sì, come senza rompere nulla?

2. Per le API interne (sostanzialmente le funzioni interne) come dovrei scriverle?Dovrebbe aggiungerli all'oggetto principale, ad es. storageLocker.prototype.myInternalFunction() o semplicemente myInternalFunction() a caso nel mio script?Non volevo che le funzioni fossero globali però...Una delle funzioni, ad esempio, controlla semplicemente un gruppo di elementi nel JSON, vede se i loro oggetti e quindi controlla qual è il tipo di oggetto (come Date()) e poi lo converte.

3. Come/dove dovrei aggiungere global, al mio script, vars?per esempio.ho chiamato un var patterns è qualcosa del genere var patterns = {"date":/\/Date\(([0-9]+)\)\//} come dovrei aggiungerlo al mio script?

Molte grazie.Voglio scrivere la mia sceneggiatura the giusta direzione quindi ve lo chiedo, ragazzi.Non conosco nessun ragazzo JS a livello locale che faccia OO JS, sono tutti tipi della vecchia scuola...

Answer 1

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

ha una sezione decente sullo spazio dei nomi che vale la pena leggere.

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

è anche un'altra buona panoramica.

Per ulteriore ottimo materiale sulle buone pratiche Javascript, dai un'occhiata

http://javascript.crockford.com/

Dopo la nostra discussione nei commenti, ho cambiato l'esempio in questo:

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

Anche se questo non è esattamente un esempio di libreria/modulo (perché si accede al codice chiamando direttamente il costruttore), è un esempio di come mantenere lo stesso oggetto nell'ambito di un ulteriore concatenamento di metodi.In realtà non sta restituendo il file storageLocker object, restituisce l'oggetto "pubblico", ma quell'oggetto ha accesso a storageLockerattraverso la chiusura.

Potrebbero esserci altri modi migliori per farlo, magari restituendo il file storageLocker oggetto stesso, ma ciò richiederebbe un po' più di riflessione.

Answer 2

Direi:

1) lo scopo di questa tecnica non è inquinare lo spazio dei nomi globale.Questa è una buona cosa.Nell'esempio seguente puoi vedere che tutta la tua interazione con la libreria avviene tramite un oggetto MyLibrary.L'API pubblica è il valore restituito della funzione anonima.

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) guarda anche l'esempio sopra su come posizionare le tue funzioni "interne".

3) se la variabile globale è una sorta di opzione di configurazione, renderei semplicemente setter/getter pubblico e manterrei la variabile "privata"