- Is there anything I need to avoid to prevent conflicts with other libraries?
La risposta semplice è forse, a seconda della situazione.
Esempio
jQuery per impostazione predefinita si aggiunge come jQuery sull'oggetto window e $ . Mentre è improbabile che un'altra libreria chiamerà se stessa jQuery (ne parleremo più avanti), il $ globale è in realtà una scorciatoia abbastanza comune.
Quello che fa jQuery è salvare le variabili $ e jQuery internamente e alla chiamata $.noConflict() ripristinerà le precedenti variabili impostate. [Riferimento]
Ecco un modo molto semplice per programmare questo:
var jQuery = function(){ return 1; };
(function()
{
var _jQuery = jQuery;
jQuery = function()
{
return 2;
}
jQuery.noConflict = function()
{
jQuery = _jQuery;
}
})();
//Prints "2"
console.log(jQuery());
var jQuery2 = jQuery;
jQuery2.noConflict();
//Prints "1"
console.log(jQuery());
//Prints "2"
console.log(jQuery2());
Le mie domande sarebbero:
- Vuoi utilizzare una variabile globale comune (ad esempio
$ )?
- Quali tipi di scenari vedi con le persone che lavorano con la tua libreria?
Se il tuo SDK utilizzerà una variabile globale comune e pensi che le persone potrebbero utilizzare una dozzina di librerie diverse mentre usi il tuo codice, potresti prenderlo in considerazione. Noterò che se progetti bene il tuo oggetto / funzione, non dovrebbe essere difficile aggiungere una funzionalità simile a quella che ho mostrato più avanti nel tuo progetto.
- How do I handle dependencies? Should I encapsulate them or let the user know they have to add it?
Di quante dipendenze pensi di aver bisogno? Le dipendenze sono abbastanza comuni (ad esempio jQuery)?
Personalmente, se ci sono una o due dipendenze, vorrei semplicemente dichiararlo in docs per il tuo SDK. Non è necessario che tu esca e tieni una copia delle tue dipendenze internamente mantenuta e testata.
La maggior parte dei plugin jQuery richiede jQuery (ovviamente) ma non lo raggruppa semplicemente perché non è necessario. Generalmente questi plug-in indicano una versione minima di jQuery che supportano / hanno testato ma non molto oltre.
Detto questo, il raggruppamento può essere utile specialmente se l'API della dipendenza non è molto stabile. C'è una libreria che ho usato chiamata Kalendae che raggruppa Moment. js . In questo caso, ho trovato abbastanza utile il pacchetto.
Ci sono degli svantaggi nel raggruppare i collegamenti al tuo primo punto, possono causare conflitti se la persona include già una particolare versione della libreria XYZ . Se fai il bundle, fallo in modo da creare il minimo disturbo per gli sviluppatori futuri.
Senza sapere quali sono le tue specifiche dipendenze, non posso davvero aiutarti a capire se nel tuo caso dovresti raggruppare o meno.
- Are there any methods of structuring SDKs that provide similar benefits to, say, MVC within a web app?
Non sono esattamente ciò che stai chiedendo qui in relazione alla struttura dell'SDK in MVC all'interno di un'app Web.
A seconda di ciò che fa il tuo SDK e di come le persone verrebbero probabilmente integrate con esso spiegherebbe il modo migliore per strutturarlo.
In termini di cose generali da fare:
- Riduci al minimo le variabili globali. È possibile includere il codice in una chiusura per evitare di farlo (a seconda di come si sta fuori il tuo codice).
- Consenti la flessibilità consentendo i callback e gli eventi. Dato che stai facendo un'API REST, potresti voler esaminare JS Promises. Ci sono molte librerie che forniscono tale funzionalità e speriamo presto, i browser forniranno questo in modo nativo. [Ulteriori informazioni su futures / promesse / ritardo in Informatica]
- Consentire una facile configurazione / opzioni da passare alle tue funzioni. Mentre può essere utile aggiungere 20 diverse funzioni sul tuo oggetto che configurano un gruppo di impostazioni, è molto più semplice consentire all'utente di scaricare un oggetto JS in un costruttore o un'altra funzione per eseguire tutto in una volta.
Se puoi spiegare di più su quel terzo punto, potrei essere in grado di fornire una risposta migliore.
Nota
Ho detto che un'altra libreria non si chiamerebbe jQuery nello spazio globale. Mentre in genere ciò sarebbe vero, se la persona utilizza due diverse versioni di jQuery nella stessa pagina (credetemi, succede), allora si verrebbero a trovare dei problemi. Per impostazione predefinita, la chiamata di $.noConflict() risolverà solo il riferimento $ nello scope globale, tuttavia $.noConflict ha un parametro opzionale anche per fare la stessa cosa sull'oggetto jQuery .