JavaScript: raggruppa un polyfill obbligatorio ma comune nella mia libreria?

Question

JavaScript: raggruppa un polyfill obbligatorio ma comune nella mia libreria?

#1 da (3 voti)
#2 da (3 voti)

2

Innanzitutto, ecco un paio di domande correlate, ma non proprio uguali :

Ora su la mia domanda particolare:

Sto costruendo una piccola libreria JavaScript. Se eseguito all'interno di alcuni browser meno recenti, parte della sua funzionalità dipenderà da un certo polyfill . Per gli scopi di un esempio, supponiamo che questo polyfill sia il requestAnimationFrame polyfill.

Questo polyfill è:

Ben noto: la maggior parte degli sviluppatori JavaScript ne è per lo meno vagamente consapevole.
Disponibile: frammenti di codice copia-incollabili di varianti di esso sono dappertutto.
Tiny: sono solo poche righe di codice,
Endemico: le librerie nello stesso spazio dei problemi di mia possono averle già raggruppate.

Ovviamente, se la mia libreria fosse l'unica libreria utilizzata nel progetto di qualcuno, e se parte di quel codice potesse fallire senza il polyfill in circostanze probabilmente per il pubblico dello sviluppatore, avrebbe senso raggruppare il polyfill con la libreria.

Ma nel mondo JavaScript, in particolare nel dominio di questa libreria, è possibile che lo sviluppatore abbia già il polyfill, e che raggruppandolo, potrei essere re-polyfilling requestAnimationFrame per la seconda, terza, quarta volta. (Questo in sé non è un problema, dato che la maggior parte dei polyfill per loro natura include un pre-controllo dello spazio dei nomi, ma, lo ammetto, il pensiero dello stesso polyfill che appare più volte nel codice di qualcuno mi disturba come un quadro appeso leggermente storto.)

Quindi qual è la cosa sensata da fare? Includerlo? Oppure lascia una nota nella documentazione che dice: "A proposito, assicurati di avere Polyfill X se devi supportare il browser Y"?

javascript dependencies polyfill

posta GladstoneKeep 27.03.2014 - 21:45

fonte

2 risposte

Leggi altre domande sui tag javascript dependencies polyfill

Costruire il livello di presentazione direttamente sul livello dati diagrammi delle classi UML: come mostrare la dipendenza

score 3 · Answer 1

La tua decisione si baserà sui seguenti fattori:

Esiste una libreria Javascript ben nota, stabile, affidabile che contiene la funzione polyfill di cui ho bisogno, disponibile nella sua API pubblicata esternamente?
Vale la pena * richiedere agli utenti della mia libreria di fare affidamento su quell'altra libreria per ottenere la funzione di polyfill richiesta di cui la mia biblioteca ha bisogno?

Se non riesci a rispondere a entrambe le domande, stringi i denti e copia / incolla la piccola quantità di codice di cui hai bisogno (supponendo che non vi siano restrizioni di licenza).

* _{Richiedere un'altra libreria causerà un codice che non sarà nemmeno necessario caricare in ogni pagina web. Questo non è l'unico costo.}

Ulteriori letture
L'ossessione DRY

score 3 · Answer 2

In base alle tue esigenze, includilo. Robert Harvey ha fornito buoni motivi per spiegare perché. Ho intenzione di parlare di come.

Hai detto che il polyfill è piccolo. Ma se lo includi di nuovo e molte altre librerie che i tuoi utenti inseriscono nelle loro pagine, aggiungerai al problema.

Puoi prendere un paio di approcci.

Il primo approccio sarebbe quello di fare ciò che molti framework fanno, avere un'istanza globale del tuo framework con qualsiasi framework figlio associato contenuto nel tuo namespace (jsLite in AngularJS viene in mente). Questo garantirà che il framework figlio è lì, funziona , sai dove si trova e che la versione che ti serve è caricata. Ma fallisce DRY.

L'approccio successivo consiste nel percorrere la rotta di disponibilità globale, in cui si carica il framework figlio nel prototipo dell'oggetto, verificando che non sia già caricato. Con questo approccio, si corre il rischio di una diversa revisione del framework figlio che viene caricato. Il più delle volte, questo interromperà la tua funzionalità a causa dell'interruzione dell'interfaccia.