Costruire la mia libreria JS, un paio di domande
-
29-09-2019 - |
Domanda
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.
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?
Per le API interne (sostanzialmente le funzioni interne) come dovrei scriverle?Dovrebbe aggiungerli all'oggetto principale, ad es.
storageLocker.prototype.myInternalFunction()
o semplicementemyInternalFunction()
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 (comeDate()
) e poi lo converte.Come/dove dovrei aggiungere global, al mio script, vars?per esempio.ho chiamato un var
patterns
è qualcosa del generevar 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...
Soluzione
ha una sezione decente sullo spazio dei nomi che vale la pena leggere.
è anche un'altra buona panoramica.
Per ulteriore ottimo materiale sulle buone pratiche Javascript, dai un'occhiata
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 storageLocker
attraverso la chiusura.
Potrebbero esserci altri modi migliori per farlo, magari restituendo il file storageLocker
oggetto stesso, ma ciò richiederebbe un po' più di riflessione.
Altri suggerimenti
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"