Share
Cu atâția oameni care dezvoltă pluginuri jQuery, nu este neobișnuit să se întâmple una care, pur și simplu - pentru lipsa unor cuvinte mai bune - este gravă. Nu există exemple sau documente, pluginul nu respectă cele mai bune practici etc. Dar sunteți unul dintre cei norocoși: acest articol va detalia capcanele pe care trebuie să le evitați.
jQuery nu este străin pentru cei dintre voi frecvent Nettuts +. Jeffrey Way de minunat 30 de zile de a învăța jQuery (și diverse alte tutoriale aici și în altă parte) ne-au condus pe toate calea spre Sizzle-powered awesomesauce. În toate hiperele (și multe salturi în adoptarea JavaScript de către dezvoltatori și furnizori de browser), o mulțime de plugin-uri au venit pe scena. Acesta este parțial motivul pentru care jQuery a devenit cea mai populară bibliotecă JavaScript disponibilă! Singura problemă este că multe dintre ele nu sunt prea mari.
În acest articol, ne vom concentra mai degrabă pe JavaScript în mod special și mai multe despre cele mai bune practici pentru livrarea pluginurilor.
Există câteva modele care sunt, mai mult sau mai puțin, universal acceptate ca "Calea cea bună" pentru a crea pluginuri jQuery. Dacă nu urmați aceste convenții, pluginul dvs. poate ... suge! Luați în considerare unul dintre cele mai comune modele:
(funcția ($, fereastră, undefined) $ .fn.myPlugin = funcția (opts) var defaults = // setarea valorilor implicite pentru opțiuni // extinderea opțiunilor din valorile implicite cu opțiunile utilizatorului var opțiuni = (implicit, opts || ); returnați this.each (funcția (// jQuery chainability // do plugin-uri);) (jQuery, fereastră);
În primul rând, creăm o funcție anonimă care invocă auto-invitație pentru a ne proteja de utilizarea variabilelor globale. Intrăm $, fereastră, și nedefinit. Argumentele pe care funcția de invocare în sine o numesc sunt jQuery și fereastră; nimic nu este transmis pentru nedefinit, astfel încât, dacă decidem să folosim cuvântul cheie nedefinit în plugin, "undefined" va fi de fapt nedefinit.
Acest scuturi de la alte scripturi care ar putea atribui o valoare rău intenționată
nedefinit, precumAdevărat!
$ este trecut ca jQuery; facem acest lucru pentru a ne asigura că, în afara funcției anonime, $ se pot referi la altceva în întregime, cum ar fi Prototype.
Transmiterea variabilei accesibile la nivel global fereastră obiect permite codul mai comprimat prin procesele de minificare (pe care ar trebui să le faceți, de asemenea).
Apoi, folosim modelul de plugin jQuery, $ .fn.PluginName. Aceasta este o modalitate de a înregistra pluginul dvs. pentru a fi utilizat cu $ (Selector) .method () format. Pur și simplu extind prototipul lui jQuery cu noua dvs. metodă. Dacă doriți să creați în schimb un plugin care definește o funcție pe obiectul jQuery, adăugați-l direct, după cum urmează:
$ .PluginName = functie (optiuni) // prelungi optiuni, do plugin stuff
Acest tip de plugin nu va putea fi încărcat, deoarece funcțiile care sunt definite ca proprietăți ale obiectului jQuery nu în mod obișnuit returnează obiectul jQuery. De exemplu, luați în considerare următorul cod:
$ .splitInHalf = funcția (stringToSplit) var length = stringToSplit.length; var șirArray = stringToSplit.split (stringToSplit [Math.floor (lungime / 2)]); return stringArray;
Aici, întoarcem o serie de șiruri de caractere. Are sens să returnezi pur și simplu acest lucru ca o matrice, deoarece este foarte probabil ca utilizatorii să vor să folosească (și pot să-l înfășoare cu ușurință în obiectul jQuery dacă doresc). În schimb, ia în considerare următorul exemplu conturat:
$ .getOddEls = funcția (jQcollection) // return jQcollection.filter (funcție (index) var i = index + 1; return (index% 2! = 0);
În acest caz, utilizatorul se așteaptă probabil ca obiectul jQuery să se întoarcă de la $ .getOddEls; deci, returnează metoda de filtrare, care returnează colecția jQuery definită de funcția care a trecut. O regulă bună este de a împacheta elemente returnate în funcția jQuery, mai ales dacă acestea pot fi înlănțuite; dacă întoarceți tablouri, șiruri de caractere, numere, funcții sau alte tipuri de date, lăsați-le să fie dezbrăcate.
Probabil, cel mai important lucru pe care îl puteți face când publicați codul dvs. este adăugarea documentației necesare. Decalajul dintre ceea ce explicați dezvoltatorilor și ceea ce codul are de fapt sau poate face este timpul în care utilizatorii nu vor să piardă calculul sumelor din codul dvs..
Documentația este o practică care nu are reguli de durată; cu toate acestea, este în general acceptat faptul că documentația mai bine organizată (mai bine organizată), cu atât mai bine.
Acest proces ar trebui să fie atât o practică internă (în interiorul / interconectată în codul dvs.), cât și o practică externă (explicând temeinic toate metodele publice, opțiunile și cazurile multiple de utilizare într-un wiki sau readme).
Pluginurile cele mai populare oferă acces deplin la variabile (ceea ce majoritatea pluginurilor se referă la obiecte "opțiuni") pe care un utilizator ar putea dori să le controleze. De asemenea, ele pot oferi mai multe configurații diferite ale plugin-ului, astfel încât să fie reutilizabile în multe contexte diferite. De exemplu, să luăm în considerare un simplu plugin de slider. Opțiunile pe care utilizatorul le-ar putea dori să le controleze includ viteza, tipul și întârzierea animației.
Este o bună practică să oferiți utilizatorilor acces și la nume de clasă / nume care sunt adăugate elementelor DOM inserate sau manipulate de plugin. Dar dincolo de aceasta, ei pot dori, de asemenea, să aibă acces la o funcție de apel invers ori de câte ori tranziția diapozitivelor, sau poate atunci când slide-ul trece din nou la început (un ciclu complet).
Este de datoria dvs. să vă gândiți la toate posibilele utilizări și nevoi ale pluginului.
Să luăm în considerare un alt exemplu: un plugin care face un apel către un API ar trebui să ofere accesul la obiectul returnat al API-ului. Luați următorul exemplu de concepție a unui plugin simplu:.
$ .fn.getFlickr = funcția (opts) return this.each (funcția (jQuery chainability var defaults = // setarea opțiunilor implicite cb: function (data) , flickrUrl: pentru un apel API // extindeți opțiunile din valorile implicite cu opțiunile utilizatorului var opțiuni = $ .extend (implicite, opts || ); // apelați funcția asincronă și apoi apelați callback // trecând în obiectul api care a fost returnat $ .ajax (flickrUrl, funcția (dataReturned) options.cb.call (this, dataReturned);););
Acest lucru ne permite să facem ceva în conformitate cu:
$ (selector) .getFlickr (funcția (fdata) // datele flickr sunt în obiectul fdata);
Un alt mod de a face public acest lucru este de a oferi "cârlige" ca opțiuni. Ca de la jQuery 1.7.1 și mai sus, putem folosi .la (eventName, funcția () ) după apelul nostru de plugin pentru a separa comportamentele în propriile lor funcții. De exemplu, cu pluginul de mai sus, putem schimba codul astfel încât să arate astfel:
Accentsconagua
$ .fn.getFlickr = funcția (opts) return this.each (funcția (i, el) var $ this = el; var defaults = // setarea opțiunilor implicite flickrUrl: "http://someurl.com" // o valoare implicită pentru un apel API var options = $ .extend (implicit, opts || ); // apela funcția asincronă și apoi a apela callback // trecând în obiectul api care a fost returnat $ .ajax (funcția () $ this.trigger ("error", dataReturned);); ); Acest lucru ne permite să sunăm getFlickr plugin și lanț alte manipulatoare de comportament.
$ (selector) .getFlickr (opțiuni) .on ("callback", funcția (date) // do stuff) on ("eroare"; Puteți vedea că oferirea acestui tip de flexibilitate este absolut importantă; cu cât sunt mai complexe acțiunile pe care le au pluginurile, cu atât mai complexă ar fi controlul care ar trebui să fie disponibil.
Ok, deci vârful numărul trei a sugerat că acțiunile mai complexe pe care le au pluginurile dvs., controlul mai complex care ar trebui să fie disponibil. O mare greșeală, totuși, face prea multe opțiuni necesare pentru funcționalitatea pluginului. De exemplu, este ideal ca pluginurile bazate pe UI să aibă un comportament implicit fără argumente.
$ (Selector) .myPlugin ();
Desigur, uneori acest lucru nu este realist (de exemplu, utilizatorii pot prelua un feed specific). În acest caz, ar trebui să faceți o parte din ridicarea grele pentru ei. Au mai multe moduri de trecere a opțiunilor la plugin. De exemplu, să presupunem că avem un simplu plugin Fetcher Tweet. Ar trebui să existe un comportament implicit al acelei prelucrători Tweet cu o singură opțiune necesară (numele de utilizator pe care doriți să-l preluați).
$ (selector) .fetchTweets ( "jcutrell");
În mod prestabilit, puteți lua, de exemplu, un singur tweet, îl înfășurați într-o etichetă de paragraf și umpleți elementul selector cu html-ul respectiv. Acesta este un fel de comportament pe care majoritatea dezvoltatorilor îl așteaptă și îl apreciază. Opțiunile granulare ar trebui să fie doar că: opțiuni.
Este inevitabil, în funcție de tipul de plugin, desigur că va trebui să includeți un fișier CSS dacă se bazează foarte mult pe manipulările UI. Aceasta este o soluție acceptabilă a problemei, în general; cele mai multe plugin-uri sunt însoțite de imagini și CSS. Dar nu uitați de vârful numărul doi - documentația trebuie să includă și modul de utilizare / referință a foii de stil și a imaginilor. Dezvoltatorii nu vor dori să piardă timpul cautând codul sursă pentru a afla aceste lucruri.
Lucrurile ar trebui doar ... să funcționeze.
Cu aceasta a spus că este o practică optimă de a utiliza fie stiluri injectate (care sunt foarte accesibile prin intermediul opțiunilor plugin), fie stil / stil bazat pe ID. Aceste numere și clase ar trebui să fie accesibile și prin opțiunile menționate mai sus. Stilurile inline suprascriu însă regulile CSS externe; amestecarea celor două este descurajată, deoarece este posibil ca un dezvoltator să ia mult timp să-și dea seama de ce regulile lor CSS nu sunt respectate de elementele create de plugin-ul dvs. Utilizați judecata cea mai bună în aceste cazuri.
Ca regulă generală, CSS inline este rău - cu excepția cazului în care este atât de minim până la punctul că nu-și justifică propria foaie de stil externă.
Dovada este în budincă: dacă nu puteți oferi un exemplu practic despre ceea ce face plugin-ul cu codul de însoțire, oamenii vor fi repede opriți să utilizeze pluginul. Simplu ca asta. Nu fi leneș.
Un model bun pentru exemple:
jQuery, ca orice bibliotecă de cod bun, crește cu fiecare versiune. Cele mai multe metode sunt păstrate chiar și după ce suportul este depreciat. Cu toate acestea, se adaugă noi metode; un exemplu perfect al acestui lucru este .pe() , care este noua soluție all-in-one a jQuery pentru delegarea evenimentelor. Dacă scrieți un plugin care utilizează .pe(), utilizatorii care folosesc jQuery 1.6 sau mai devreme nu vor avea noroc. Acum nu sugerez să codificați cel mai mic numitor comun, dar, în documentația dvs., asigurați-vă că explicați ce versiune de jQuery acceptă plugin-ul dvs. Dacă introduceți un plugin cu suport pentru jQuery 1.7, trebuie să luați în considerare considerabil menținerea suportului pentru 1.7 chiar și odată ce 1.8 va ieși. De asemenea, ar trebui să luați în considerare posibilitatea de a beneficia de funcțiile noi / mai bune / mai rapide din jQuery în momentul în care acestea apar.
Încurajați dezvoltatorii să facă upgrade, dar nu rupeți plugin-ul prea des! O opțiune este de a oferi o versiune "moștenită", neprotejată, a pluginului dvs..
Este timpul să mușcați glonțul dacă nu ați învățat încă cum să utilizați controlul versiunii.
Împreună cu păstrarea suportului / compatibilității versiunii jQuery a unei părți din documentația dvs., trebuie de asemenea să lucrați în controlul versiunii. Controlul versiunii (în mod special, prin GitHub) este în mare parte casa de codificare socială. Dacă dezvoltați un plugin pentru jQuery pe care doriți să-l publicați în cele din urmă în repozitoriul oficial, acesta trebuie să fie stocat într-un depozit GitHub oricum; este timpul să mușcați glonțul dacă nu ați învățat cum să utilizați controlul versiunii. Există nenumărate beneficii pentru controlul versiunilor, toate acestea depășind domeniul de aplicare al acestui articol. Dar unul dintre avantajele principale este că permite oamenilor să vadă schimbările, îmbunătățirile și corecțiile de compatibilitate pe care le faceți și când le faceți. Aceasta deschide, de asemenea, podeaua pentru contribuția și personalizarea / extinderea pluginurilor pe care le scrieți.
Lumea nu are nevoie de un alt plugin slider.
Ok, am ignorat destul de mult aici: unele "plugin-uri" sunt inutile sau prea superficiale pentru a justifica numirea unui plugin. Lumea nu are nevoie de un alt plugin slider! Trebuie remarcat, totuși, că echipele interne își pot dezvolta propriile plugin-uri pentru propriile lor utilizări, ceea ce este perfect. Cu toate acestea, dacă sperăți să împingeți pluginul în sfera de codare socială, găsiți un motiv pentru a scrie mai multe coduri. După cum se spune, nu există niciun motiv pentru a reinventa roata. În schimb, luați roata altcuiva și construiți o mașină de curse. Desigur, uneori există modalități noi și mai bune de a face aceleași lucruri care s-au făcut deja. De exemplu, ar trebui să scrieți un nou plugin slider dacă utilizați tehnologii mai rapide sau noi.
Aceasta este destul de simplă: oferiți o versiune minimizată a codului. Acest lucru îl face mai mic și mai rapid. Se asigură, de asemenea, că Javascript-ul dvs. este gratuit când este compilat. Când minifiționați codul, nu uitați să oferiți și versiunea necomprimată, astfel încât colegii dvs. să poată examina codul de bază. Sunt disponibile instrumente gratuite și ieftine pentru dezvoltatorii de la toate nivelurile de experiență.
Consultați numărul de vârf treisprezece pentru o soluție automată.
Când scrieți un plugin, acesta este destinat să fie folosit de alții, nu? Din acest motiv, cel mai eficient cod sursă este foarte lizibil. Dacă scrieți nenumărate funcții de stil lambda inteligentă, sau numele dvs. de variabilă nu sunt semantice, va fi dificil să depanați erorile atunci când apar în mod inevitabil. În loc să scrie nume de variabile scurte pentru a economisi spațiu, urmați sfatul din numărul 9 (minify!). Aceasta este o altă parte a unei bune documentații; dezvoltatorii decente ar trebui să poată să vă revizuiască codul și să înțeleagă ce face, fără a cheltui prea multă energie.
Dacă vă aflați la apelul variabilelor "
A"sau"X", o faci gresit.
În plus, dacă vă aflați în documentația de consultare pentru a vă amintiți ce al tau un cod ciudat caută, trebuie, de asemenea, să fie mai puțin concis și mai explicativ. Limitați numărul de linii din fiecare funcție la cât mai puține posibil; dacă se întind de treizeci sau mai multe linii, ar putea exista un miros de cod.
Atât cât iubim cu toții folosind jQuery, este important să înțelegem că este o bibliotecă și că vine cu un cost mic. În general, nu trebuie să vă faceți griji prea mult despre lucruri precum performanța jQuery selector. Nu fii neplăcut și vei fi bine. jQuery este foarte optimizat. Acestea fiind spuse, dacă singurul motiv pentru care aveți nevoie de jQuery (sau un plugin) este de a efectua câteva interogări pe DOM, puteți lua în considerare eliminarea în întregime a abstractizării și, în schimb, lipirea cu vanilla JavaScript sau Zepto.
Notă: dacă vă decideți să păstrați cu JavaScript de vanilie, asigurați-vă că utilizați metode care sunt cross-browser. S-ar putea să aveți nevoie de o mică cantitate de polimer pentru API-urile mai noi.
Utilizați Grunt. Perioadă.
Grunt este un "instrument de construire a liniei de comandă bazate pe sarcini pentru proiectele JavaScript", care a fost detaliat aici în detaliu aici pe Nettuts +. Vă permite să faceți astfel de lucruri:
grunt init: jquery
Această linie (executată în linia de comandă) vă va solicita un set de întrebări, cum ar fi titlul, descrierea, versiunea, depozitul git, licențele etc. Aceste informații ajută la automatizarea procesului de configurare a documentației, a acordării de licențe etc..
Grunt face mult mai mult decât să faci un cod personalizat pentru boilerplate; de asemenea, oferă instrumente construite, cum ar fi linia de cod JSHint, și poate automatiza testele Qunit pentru tine atâta timp cât aveți instalat PhantomJS (pe care Grunt îl ocupă). În acest fel, puteți simplifica fluxul de lucru, deoarece testele se execută instantaneu în terminalul salvat.
Oh, apropo ... tu do testați-vă codul, nu? Dacă nu, cum puteți asigura / declara că codul dvs. funcționează conform așteptărilor? Testarea manuală are loc, dar, dacă vă aflați în stare să revărcați browserul de nenumărate ori la fiecare oră, faceți acest lucru greșit. Luați în considerare utilizarea instrumentelor, cum ar fi Qunit, Jasmine sau chiar Mocha.
Testarea este utilă în special atunci când se îmbină în cererile de tragere pe GitHub. Puteți solicita ca toate solicitările să furnizeze teste pentru a vă asigura că codul nou / modificat nu va rupe pluginul existent.
În cazul în care conceptul de testare a plugin-urilor jQuery este nou pentru dvs., luați în considerare urmărirea noastră exclusivă Premiumcast, Tehnici pentru jQuery Plugin-uri de testare. În plus, lansează un nou curs "JavaScript Testing With Jasmine", care va fi lansat mai târziu în această săptămână pe site!
Nu v-am fi făcut vreun favor, spunându-ne doar ce faceți greșit. Iată câteva linkuri care vă vor ajuta să reveniți pe calea cea bună!
Dacă scrieți un plugin jQuery, este vital să vă îndepărtați de capcanele enumerate mai sus. Am pierdut semnele cheie ale unui plugin prost executat?
