Share
Met zoveel mensen die jQuery plug-ins ontwikkelen, is het niet ongebruikelijk om er een tegen te komen die gewoon - bij gebrek aan betere woorden - stom is. Er zijn geen voorbeelden of documentatie, de plug-in volgt geen best practices, enz. Maar u bent een van de gelukkigen: dit artikel zal de valkuilen beschrijven die u moet vermijden.
jQuery is geen onbekende voor degenen onder jullie die regelmatig Nettuts + zijn. Jeffrey Way's geweldige 30 Days to Learn jQuery (en verschillende andere tutorials hier en elders) hebben ons allemaal op het pad naar Sizzle-aangedreven awesomesauce gebracht. In alle hype (en een hoop sprongen in de acceptatie van JavaScript door ontwikkelaars en browserleveranciers), zijn er veel plug-ins op de markt verschenen. Dit is gedeeltelijk waarom jQuery de meest populaire JavaScript-bibliotheek is die beschikbaar is! Het enige probleem is dat veel van hen niet te groot zijn.
In dit artikel richten we ons minder specifiek op JavaScript, en meer op praktische tips voor het leveren van plug-ins.
Er zijn enkele patronen die min of meer universeel worden geaccepteerd als "De juiste manier" om jQuery-plug-ins te maken. Als u deze conventies niet volgt, kan uw plug-in ... zuigen! Overweeg een van de meest voorkomende patronen:
(functie ($, venster, undefined) $ .fn.myPlugin = function (opts) var defaults = // uw standaardwaarden voor opties // uitbreiding van de opties van standaardwaarden met opties van de gebruiker var options = $ .extend (standaard, opteert || ); return this.each (function () // jQuery chainability // do plugin stuff);) (jQuery, venster);
Ten eerste creëren we een zichzelf aanroepende anonieme functie om onszelf te beschermen tegen het gebruik van globale variabelen. We komen binnen $, venster, en onbepaald. De argumenten waarmee de zichzelf aanroepende functie wordt aangeroepen, zijn jQuery en venster; er wordt niets doorgegeven voor undefined, zodat als we besluiten om het niet-gedefinieerde trefwoord in de plug-in te gebruiken, "undefined" feitelijk ongedefinieerd is.
Dit schermt af van andere scripts die mogelijk een kwaadaardige waarde toekennen aan
onbepaald, zoalswaar!
$ wordt doorgegeven als jQuery; we doen het op deze manier om ervoor te zorgen dat, buiten de anonieme functie, $ kan nog altijd naar iets anders verwijzen, zoals Prototype.
De variabele doorgeven voor de wereldwijd toegankelijke venster object staat meer gecomprimeerde code toe via de minificatieprocessen (wat je ook zou moeten doen).
Vervolgens gebruiken we het plug-inpatroon jQuery, $ .fn.PluginName. Dit is een manier om uw plug-in te registreren voor gebruik met de $ (Selector) .method () formaat. Het breidt eenvoudig het prototype van jQuery uit met uw nieuwe methode. Als u in plaats daarvan een plug-in wilt maken die een functie op het jQuery-object definieert, voegt u deze direct toe, zoals:
$. PluginName = functie (opties) // opties uitbreiden, plug-in doen
Dit type plug-in is niet koppelbaar, omdat functies die zijn gedefinieerd als eigenschappen van het jQuery-object meestal niet het jQuery-object retourneren. Overweeg bijvoorbeeld de volgende code:
$ .splitInHalf = function (stringToSplit) var length = stringToSplit.length; var stringArray = stringToSplit.split (stringToSplit [Math.floor (length / 2)]); return stringArray;
Hier geven we een reeks tekenreeksen terug. Het is logisch dit eenvoudig als een array te retourneren, omdat dit waarschijnlijk is wat gebruikers willen gebruiken (en ze kunnen het gemakkelijk in het jQuery-object plaatsen als ze dat willen). Overweeg daarentegen het volgende gekunstelde voorbeeld:
$ .getOddEls = function (jQcollection) // return jQcollection.filter (functie (index) var i = index + 1; return (index% 2! = 0););
In dit geval verwacht de gebruiker waarschijnlijk dat het jQuery-object retourneert $ .getOddEls; Daarom retourneren we de filtermethode, die de jQuery-verzameling retourneert die wordt gedefinieerd door de functie die wordt doorgegeven. Een goede vuistregel is om geretourneerde elementen in de jQuery-functie te verpakken, vooral als ze kunnen worden geketend; als u arrays, strings, getallen, functies of andere gegevenstypen retourneert, laat u ze onverpakt.
Wellicht is het belangrijkste dat u kunt doen bij het publiceren van uw code, de nodige documentatie toevoegen. De kloof tussen wat u uitlegt aan ontwikkelaars en wat de code feitelijk doet of kan doen, is de tijd die gebruikers niet willen verspillen aan het uitzoeken van de ins en outs van uw code.
Documentatie is een praktijk die geen harde regels kent; het is echter algemeen aanvaard dat hoe meer (goed georganiseerde) documentatie je hebt, hoe beter.
Dit proces moet zowel een interne praktijk zijn (binnen / verspreid door uw code) als een externe praktijk (waarbij alle openbare methoden, opties en casussen voor meervoudig gebruik grondig worden uitgelegd in een wiki of readme).
De populairste plug-ins bieden volledige toegang tot variabelen (wat de meeste plug-ins'object'-objecten noemen) die een gebruiker mogelijk wil bedienen. Ze kunnen ook veel verschillende configuraties van de plug-in bieden, zodat deze in veel verschillende contexten herbruikbaar is. Laten we bijvoorbeeld een eenvoudige slider-plug-in overwegen. Opties die de gebruiker mogelijk wil bedienen, omvatten de snelheid, het type en de vertraging van de animatie.
Het is een goede gewoonte om de gebruiker ook toegang te geven tot klassenamen / ID-namen die zijn toegevoegd aan de DOM-elementen die zijn ingevoegd of bewerkt door de plug-in. Maar daarnaast willen ze mogelijk ook toegang hebben tot een callback-functie elke keer dat de dia overgaat, of misschien wanneer de dia teruggaat naar het begin (één volledige "cyclus").
Het is jouw taak om na te denken over alle mogelijke toepassingen en behoeften van de plug-in.
Laten we een ander voorbeeld bekijken: een plug-in die een aanroep doet naar een API moet toegang bieden tot het geretourneerde object van de API. Neem het volgende voorbeeld van een eenvoudige plugin concep:.
$ .fn.getFlickr = function (opts) return this.each (function () // jQuery chainability var defaults = // setting your default options cb: function (data) , flickrUrl: // een standaardwaarde voor een API-aanroep // de opties uitbreiden van standaardwaarden met opties van de gebruiker var options = $ .extend (standaard, opteert || ); // de functie async bellen en vervolgens de callback // passing in het api-object bellen werd $ .ajax geretourneerd (flickrUrl, function (dataReturned) options.cb.call (this, dataReturned);););
Dit stelt ons in staat iets te doen in de trant van:
$ (selector) .getFlickr (functie (fdata) // flickr-gegevens bevinden zich in het fdata-object);
Een andere manier om dit bekend te maken is om 'hooks' als opties aan te bieden. Vanaf jQuery 1.7.1 en hoger kunnen we gebruiken .on (eventName, function () ) na onze plugin-oproep om het gedrag te scheiden in hun eigen functies. Met de bovenstaande plug-in kunnen we de code bijvoorbeeld zo wijzigen:
Accentsconagua
$ .fn.getFlickr = function (opts) return this.each (functie (i, el) var $ this = el; var defaults = // setting your default options flickrUrl: "http://someurl.com" // een standaardwaarde voor een API-aanroep var options = $ .extend (standaard, opteert || ); // callt de async-functie en belt dan de callback // passing in het api-object dat $ .ajax heeft geretourneerd (flickrUrl, function (dataReturned) // do some stuff $ this.trigger ("callback", dataReturned);). error (function () $ this.trigger ("error", dataReturned);); ); Dit stelt ons in staat om de. Te bellen getFlickr plug-in en keten andere gedragshandlers.
$ (selector) .getFlickr (opts) .on ("callback", functie (gegevens) // do stuff). on ("error", function () // handle an error); Je kunt zien dat het aanbieden van deze vorm van flexibiliteit absoluut belangrijk is; Hoe complexer de acties van uw plug-ins, hoe complexer het besturingselement dat beschikbaar moet zijn.
Ok, dus tip nummer drie suggereerde dat de meer complexe acties die uw plug-ins hebben, de complexere controle die zou moeten zijn beschikbaar. Een grote fout is echter dat er te veel opties vereist zijn voor de plug-infunctionaliteit. Het is bijvoorbeeld ideaal voor op UI gebaseerde plug-ins om een standaard gedrag zonder argumenten te hebben.
$ (Selector) .myPlugin ();
Zeker, soms is dit niet realistisch (omdat gebruikers bijvoorbeeld een specifieke feed kunnen halen). In dit geval zou je een deel van het zware werk voor hen moeten doen. Heb meerdere manieren om opties door te geven aan de plug-in. Laten we zeggen dat we een eenvoudige tweepakketten-inplugin hebben. Er zou een standaardgedrag moeten zijn van die Tweet-fetcher met één enkele vereiste optie (de gebruikersnaam die je wilt ophalen).
$ (Selector) .fetchTweets ( "jcutrell");
De standaard kan bijvoorbeeld een enkele tweet pakken, deze in een alineatag omsluiten en het selectorelement met die html vullen. Dit is het soort gedrag dat de meeste ontwikkelaars verwachten en waarderen. De gedetailleerde opties moeten precies dat zijn: opties.
Het is onvermijdelijk, afhankelijk van het type plug-in, dat u uiteraard een CSS-bestand moet opnemen als het sterk is gebaseerd op UI-manipulaties. Dit is een acceptabele oplossing voor het probleem, in het algemeen; de meeste plug-ins worden gebundeld met afbeeldingen en CSS. Maar vergeet tip nummer twee niet - documentatie moet ook bevatten hoe u de stylesheet (s) en afbeeldingen moet gebruiken / verwijzen. Ontwikkelaars zullen geen tijd willen verspillen aan het doornemen van uw broncode om deze dingen te achterhalen.
Dingen moeten gewoon ... werken.
Met dat gezegd, is het absoluut een goede gewoonte om geïnjecteerde stijlen te gebruiken (die zeer toegankelijk zijn via plugin-opties) of op klasse / ID gebaseerde styling. Deze ID's en klassen moeten ook toegankelijk zijn, via opties zoals eerder vermeld. Inline-stijlen overschrijven echter externe CSS-regels; het mengen van de twee is ontmoedigd, omdat het een ontwikkelaar lang kan uitzoeken waarom zijn CSS-regels niet worden gerespecteerd door elementen die zijn gemaakt door je plug-in. Gebruik je gezond verstand in deze gevallen.
Als vuistregel is inline CSS slecht - tenzij het zo minimaal is dat het zijn eigen externe stylesheet niet rechtvaardigt.
Het bewijs zit in de pudding: als u geen praktisch voorbeeld kunt geven van wat uw plug-in doet met de bijbehorende code, zullen mensen snel worden uitgeschakeld voor het gebruik van uw plug-in. Simpel als dat. Wees niet lui.
Een goede voorbeeldsjabloon:
jQuery groeit, net als elke goede codebibliotheek, bij elke release. De meeste methoden worden bewaard, zelfs als de ondersteuning is verouderd. Er zijn echter nieuwe methoden toegevoegd; een perfect voorbeeld hiervan is de .op() methode, de nieuwe alles-in-één-oplossing van jQuery voor gebeurtenisdelegatie. Als je een plug-in schrijft die gebruikt .op(), mensen die jQuery 1.6 of eerder gebruiken, hebben pech. Nu suggereer ik niet dat je codeert voor de kleinste gemene deler, maar in je documentatie moet je uitleggen welke versie van jQuery je plug-in ondersteunt. Als u een plug-in invoert met ondersteuning voor jQuery 1.7, moet u sterk overwegen om ondersteuning voor 1.7 te behouden, zelfs als 1.8 uitkomt. Je zou ook moeten overwegen om te profiteren van nieuwe / betere / snellere functies in jQuery zodra ze uitkomen.
Moedig ontwikkelaars aan om te upgraden, maar verbreek je plugin niet te vaak! Een optie is om een "verouderde" verouderde, niet-ondersteunde versies van uw plug-in aan te bieden.
Het is tijd om de knoop door te hakken als je nog niet hebt geleerd om versiebeheer te gebruiken.
Naast het behouden van de ondersteuning / compatibiliteit van uw jQuery-versie, moet u ook werken aan versiebeheer. Versiebeheer (specifiek via GitHub) is grotendeels de thuisbasis van sociale codering. Als u een plug-in voor jQuery ontwikkelt die u uiteindelijk in de officiële repository wilt publiceren, moet deze hoe dan ook in een GitHub-repository worden opgeslagen; het is tijd om de knoop door te hakken als je nog niet hebt geleerd hoe je versiebeheer moet gebruiken. Er zijn talloze voordelen aan versiebeheer, die allemaal buiten het bestek van dit artikel vallen. Maar een van de belangrijkste voordelen is dat het mensen in staat stelt om de wijzigingen, verbeteringen en compatibiliteitsoplossingen die u maakt te bekijken, en wanneer u ze maakt. Dit opent ook de basis voor contributie en maatwerk / uitbreiding van de plug-ins die u schrijft.
De wereld heeft geen andere slider plug-in nodig.
Ok, we hebben het hier lang genoeg genegeerd: sommige "plug-ins" zijn nutteloos of te oppervlakkig om een plug-in genoemd te kunnen worden. De wereld heeft geen andere schuifplugin nodig! Er moet echter worden opgemerkt dat interne teams hun eigen plug-ins kunnen ontwikkelen voor hun eigen gebruik, wat perfect in orde is. Als u echter hoopt om uw plug-in in de sociale coderingssfeer te duwen, zoek dan een reden om meer code te schrijven. Zoals het gezegde luidt, is er geen reden om het wiel opnieuw uit te vinden. Neem in plaats daarvan het wiel van iemand anders en bouw een raceauto. Natuurlijk zijn er soms nieuwe en betere manieren om dezelfde dingen te doen die al zijn gedaan. U kunt bijvoorbeeld heel goed een nieuwe slider-plug-in schrijven als u snellere of nieuwe technologie gebruikt.
Deze is vrij eenvoudig: bied een verkleinde versie van je code aan. Dit maakt het kleiner en sneller. Het zorgt er ook voor dat uw Javascript foutloos is bij het compileren. Wanneer u uw code verkleint, vergeet dan niet om de niet-gecomprimeerde versie ook aan te bieden, zodat uw collega's de onderliggende code kunnen bekijken. Gratis en goedkope tools zijn beschikbaar voor front-end ontwikkelaars van alle ervaringsniveaus.
Raadpleeg tip nummer dertien voor een geautomatiseerde oplossing.
Wanneer u een plug-in schrijft, is deze bedoeld om door anderen te worden gebruikt, toch? Om deze reden is de meest effectieve broncode zeer leesbaar. Als je ontelbare slimme one-liner lambda-stijlfuncties schrijft, of je variabelenamen zijn niet semantisch, zal het moeilijk zijn fouten te debuggen wanneer ze onvermijdelijk optreden. In plaats van korte variabelenamen te schrijven om ruimte te besparen, volg dan het advies in tip nummer negen (minify!). Dit is een ander deel van goede documentatie; fatsoenlijke ontwikkelaars moeten in staat zijn om uw code te bekijken en te begrijpen wat ze doet zonder dat ze teveel energie hoeven te spenderen.
Als je merkt dat je variabelen belt "
een"of"X", je doet het verkeerd.
Bovendien, als u merkt dat u documentatie raadpleegt om te onthouden wat je eigen vreemd uitziende code doet, je moet waarschijnlijk ook minder beknopt en meer verklarend zijn. Beperk het aantal regels in elke functie tot zo weinig mogelijk; als ze zich uitstrekken over dertig of meer lijnen, kan er een codegeur zijn.
Hoe graag we jQuery ook gebruiken, het is belangrijk om te begrijpen dat het een bibliotheek is, en dat gaat gepaard met kleine kosten. Over het algemeen hoeft u zich niet al te veel zorgen te maken over zaken als de prestaties van jQuery-selectoren. Wees niet onaangenaam en het komt goed. jQuery is sterk geoptimaliseerd. Dat gezegd hebbende, als de enige reden waarom je jQuery (of een plug-in) nodig hebt, is om een paar vragen over de DOM uit te voeren, zou je kunnen overwegen om de abstractie volledig te verwijderen, en in plaats daarvan blijven hangen met vanille JavaScript, of Zepto.
Notitie: Als u besluit om bij van JavaScript te blijven, moet u ervoor zorgen dat u methoden gebruikt die in verschillende browsers voorkomen. Mogelijk hebt u een kleine polyfill nodig voor de nieuwere API's.
Gebruik Grunt. Periode.
Grunt is een "taakgebaseerde tool voor het bouwen van opdrachtregels voor JavaScript-projecten", die onlangs hier op Nettuts + uitgebreid werd besproken. Hiermee kun je dingen als deze doen:
grunt init: jQuery
Deze regel (uitgevoerd op de opdrachtregel) zal u vragen stellen, zoals de titel, beschrijving, versie, git repository, licenties, enzovoort. Deze stukjes informatie helpen bij het automatiseren van het proces van het opzetten van uw documentatie, licenties, enz.
Grunt doet veel meer dan alleen een aangepaste boilerplate code voor u maken; het biedt ook ingebouwde tools, zoals de code-linter JSHint, en het kan de QUnit-testen voor u automatiseren zolang PhantomJS is geïnstalleerd (waar Grunt voor zorgt). Op deze manier kunt u uw workflow stroomlijnen, omdat tests direct in de terminal worden uitgevoerd bij opslaan.
Oh, tussen haakjes - jij do test je code, toch? Zo nee, hoe kunt u ervoor zorgen / verklaren dat uw code werkt zoals verwacht? Handmatig testen heeft zijn plaats, maar als je ontelbare keren per uur de browser verfrist, doe je het verkeerd. Overweeg hulpmiddelen te gebruiken, zoals QUnit, Jasmine of zelfs Mocha.
Testen is met name handig bij het samenvoegen van pull-aanvragen op GitHub. U kunt eisen dat alle verzoeken tests uitvoeren om ervoor te zorgen dat de nieuwe / gewijzigde code uw bestaande plug-in niet breekt.
Als het concept van het testen van jQuery-plug-ins nieuw voor je is, kun je onze Premium-exclusieve screencast, Techniques For Test-Driving jQuery Plugins, bekijken. Daarnaast lanceren we later deze week een nieuwe cursus 'JavaScript testen met jasmijn' op de site!
We zouden je geen gunsten geven door je alleen maar te vertellen wat je fout doet. Hier zijn enkele links die u helpen om op het goede pad te komen!
Als u een jQuery-plug-in schrijft, is het van groot belang dat u afdwaalt van de hierboven genoemde valkuilen. Heb ik belangrijke tekens gemist van een slecht uitgevoerde plug-in?
