Share
Lang geleden, in een sterrenstelsel ver, ver weg, was JavaScript een gehate taal. In feite is 'gehaat' een understatement; JavaScript was een verachte taal. Dientengevolge hebben ontwikkelaars het over het algemeen als zodanig behandeld, waarbij ze alleen hun tenen in de JavaScript-wateren tuimelden wanneer ze een vleugje flair in hun toepassingen moesten sprenkelen. Ondanks het feit dat er een heleboel goede dingen in de JavaScript-taal zijn, vanwege de wijdverspreide onwetendheid, hebben weinigen de tijd genomen om het goed te leren. In plaats daarvan, zoals sommigen van jullie misschien zullen onthouden, betrof het standaard JavaScript-gebruik een aanzienlijke hoeveelheid kopiëren en plakken.
"Doe niet de moeite om te leren wat de code doet, of dat deze de beste werkwijzen volgt, maar plak hem gewoon in!" - Slechtste advies ooit
Omdat de opkomst van jQuery opnieuw interesse wekte in de JavaScript-taal, is veel van de informatie op het web een beetje vaag.
Ironisch genoeg blijkt dat veel van wat de ontwikkelingsgemeenschap haatte weinig te maken had met de JavaScript-taal zelf. Nee, de echte dreiging onder het masker was de DOM, oftewel 'Document Object Model', wat, met name in die tijd, vreselijk inconsistent was van browser tot browser. "Natuurlijk werkt het misschien in Firefox, maar hoe zit het met IE8? Oké, het werkt misschien in IE8, maar hoe zit het met IE7?" De lijst ging onvermoeibaar door!
Gelukkig, ongeveer vijf jaar geleden begonnen, zou de JavaScript-gemeenschap een ongelooflijke verandering ten goede zien, omdat bibliotheken zoals jQuery aan het publiek werden voorgesteld. Deze bibliotheken hebben niet alleen een expressieve syntaxis opgeleverd die met name aantrekkelijk was voor webontwerpers, maar ze hebben ook het speelgevoel genivelleerd door de tijdelijke oplossingen voor de verschillende browser-quirks in de API te stoppen. Op gang brengen $ .ajax en laat jQuery het moeilijke deel doen. Fast-forward naar vandaag en de JavaScript-community is levendiger dan ooit - grotendeels dankzij de jQuery-revolutie.
Omdat de opkomst van jQuery opnieuw interesse wekte in de JavaScript-taal, is veel van de informatie op het web een beetje vaag. Dit is minder vanwege de onwetendheid van de schrijvers en meer als gevolg van het feit dat we allemaal leerden. Het kost tijd voor de beste werkwijzen te voorschijn komen.
Gelukkig is de gemeenschap enorm gegroeid sinds die tijd. Voordat we een duik nemen in enkele van deze best practices, laten we eerst een paar slechte adviezen openbaar maken die op het internet zijn verspreid.
Het probleem met tips als deze is dat ze het idee van pre-optimalisatie tot het uiterste nemen.
Net zoals Ruby on Rails was de eerste kennismaking met JavaScript voor veel ontwikkelaars via jQuery. Dit leidde tot een gemeenschappelijke cyclus: leer jQuery, word verliefd, verdiep je in JavaScript van vanille en verhoog het niveau.
Hoewel er absoluut niets mis is met deze cyclus, heeft dit de weg vrijgemaakt voor talloze artikelen, die gebruikers hebben aanbevolen niet gebruik jQuery in verschillende situaties vanwege "prestatieproblemen". Het is niet ongebruikelijk om te lezen dat het beter is om vanille te gebruiken voor loops, over $ .each. Of misschien heb je op een of ander moment gelezen dat het de beste manier is om te gebruiken document.getElementsByClassName via de Sizzle-engine van jQuery, omdat deze sneller is.
Het probleem met tips als deze is dat ze het idee van pre-optimalisatie tot het uiterste nemen en geen rekening houden met verschillende browserinconsistenties - de dingen die jQuery voor ons heeft opgelost! Het uitvoeren van een test en het waarnemen van een besparing van enkele milliseconden gedurende duizenden herhalingen is geen reden om jQuery en de elegante syntax ervan te laten varen. Uw tijd is veel beter geïnvesteerd, het aanpassen van delen van uw toepassing die daadwerkelijk een verschil zullen maken, zoals de grootte van uw afbeeldingen.
Dit tweede anti-patroon was opnieuw het resultaat van de gemeenschap (inclusief de jouwe op een bepaald moment) die niet helemaal begreep wat er onder de jQuery-capuchon plaatsvond. Als zodanig kwam je waarschijnlijk code tegen (of schreef jezelf), die een element talloze malen in een jQuery-object wikkelde binnen een functie.
Accentsconagua
$ ('button.confirm'). on ('klik', functie () // Doe het een keer $ ('. modal'). modal (); // En nog een keer $ ('. modal'). addClass ('actief'); // En nogmaals voor goede maatregel $ ('modal'). css (...);); Hoewel deze code in het begin onschadelijk lijkt (en waarheidsgetrouw in het grote geheel van dingen is), volgen we de slechte gewoonte om meerdere exemplaren van het jQuery-object te maken. Elke keer dat we verwijzen naar $ ( 'Modale'), een nieuw jQuery-object wordt gegenereerd. Is dat slim?
Zie de DOM als een zwembad: elke keer dat u belt
$ ( 'Modale'), jQuery duikt in het zwembad en jaagt de bijbehorende munten (of elementen) af. Wanneer je herhaaldelijk de DOM om dezelfde selector vraagt, gooi je die munten in feite terug in het water, alleen om erin te springen en ze allemaal opnieuw te vinden!
Koppel de selectors altijd als u van plan bent ze meer dan eens te gebruiken. Het vorige codefragment kan worden aangepast aan:
$ ('button.confirm'). on ('klik', functie () $ ('. modal') .modal () .addClass ('active') .css (...);); U kunt ook "caching" gebruiken.
$ ('button.confirm'). on ('click', function () // Doe het ALLEEN eens var modal = $ ('. modal'); modal.modal (); modal.addClass ('active') ; modal.css (...);); Met deze techniek springt jQuery in de DOM-pool in totaal één keer in plaats van drie.
Er wordt te veel aandacht besteed aan de prestaties van de selector.
Hoewel het niet zo lang geleden zo alomtegenwoordig was, werd het web gebombardeerd door talloze artikelen over het optimaliseren van de selectorprestaties in jQuery. Is het bijvoorbeeld beter om te gebruiken $ ('div p') of $ ( 'Div'). Vinden ( 'p')?
Klaar voor de waarheid? Het maakt niet echt uit. Het is zeker een goed idee om een basiskennis te hebben van de manier waarop de Sizzle-engine van jQuery je selectiequery's van rechts naar links parseert (wat betekent dat het beter is om specifieker te zijn aan het einde van je selector, in plaats van het begin). En, natuurlijk, hoe specifieker je kunt zijn, hoe beter. Duidelijk, $ ( 'A.button') is beter voor prestaties dan $ ( 'Button'), vanwege het feit dat jQuery met het eerste, in staat is om het zoeken te beperken tot alleen de ankerelementen op de pagina, in plaats van alle elementen.
Daarbuiten wordt echter te veel aandacht besteed aan de prestaties van de selector. Als u twijfelt, kunt u erop vertrouwen dat het jQuery-team bestaat uit de beste JavaScript-ontwikkelaars in de branche. Als er een prestatieverbetering wordt bereikt in de bibliotheek, hebben ze deze ontdekt. En als dat niet het geval is, zal een van de communityleden een pull-aanvraag indienen.
Houd daarom rekening met je selectors, maar houd je niet te veel bezig met implicaties voor de uitvoering, tenzij je kunt verwoorden waarom dat nodig is.
jQuery heeft het wijdverbreide gebruik van callback-functies aangemoedigd, wat zeker een leuk gemak kan bieden. In plaats van een functie te declareren, gebruikt u gewoon een callback-functie. Bijvoorbeeld:
$ ('a.external'). on ('klik', functie () // deze callback-functie wordt geactiveerd // wanneer .extern wordt geklikt); Je hebt zeker veel code geschreven die er precies zo uitziet; Ik weet dat ik het heb! Wanneer spaarzaam gebruikt, dienen anonieme callback-functies als nuttige voorzieningen. De wrijving komt langs de lijn, wanneer we binnenkomen ... terugbellen hel (trigger bliksemschicht geluid)!
Terugbellen in de hel is wanneer uw code zich vele keren inspringt, terwijl u callback-functies blijft nesten.
Beschouw de volgende vrij algemene code hieronder:
$ ('a.data'). on ('klik', functie () var anchor = $ (this); $ (this) .fadeOut (400, function () $ .ajax (// ... success: function (data) anchor.fadeIn (400, function () // je hebt zojuist callback hell);););); Als basis vuistregel geldt dat hoe meer uw code is ingesprongen, hoe waarschijnlijker het is dat er een codegeur is. Of, beter nog, vraag jezelf af, ziet mijn code eruit als de Mighty Ducks Flying V?
Wanneer u een dergelijke code naspeurt, moet u uzelf de vraag stellen: "Hoe kan dit worden getest?" Binnen dit schijnbaar eenvoudige stukje code is een gebeurtenislistener gebonden aan een link, vervaagt het element, wordt een AJAX-aanroep uitgevoerd, bij succes vervaagt het element terug, vermoedelijk zullen de resulterende gegevens ergens worden toegevoegd. Dat is veel om te testen!
Zou het niet beter zijn om deze code in meer beheersbare en toetsbare stukken te splitsen? Zeker. Hoewel het volgende verder kan worden geoptimaliseerd, kan een eerste stap om deze code te verbeteren zijn:
var updatePage = function (el, data) // voeg de opgehaalde gegevens toe aan DOM; var fetch = function (ajaxOptions) ajaxOptions = ajaxOptions || // url: ... // dataType: ... succes: updatePage; return $ .ajax (ajaxOptions); ; $ ('a.data'). on ('klik', functie () $ (this) .fadeOut (400, fetch);); Nog beter: als je verschillende acties hebt om te activeren, moet je de relevante methoden in een object bevatten.
Bedenk hoe in een fastfoodrestaurant, zoals McDonalds, elke werknemer verantwoordelijk is voor één taak. Joe doet de patat, Karen registreert klanten en Mike grilt burgers. Als alle drie de personeelsleden alles zouden doen, zou dit een verscheidenheid aan onderhoudsproblemen met zich meebrengen. Wanneer veranderingen moeten worden geïmplementeerd, moeten we een afspraak maken met elke persoon om deze te bespreken. Als we Joe bijvoorbeeld alleen maar gefocust houden op de patat, moeten we de instructies voor het bereiden van friet aanpassen, we hoeven alleen met Joe en niemand anders te praten. Je zou een vergelijkbare benadering van je code moeten volgen; elke functie is verantwoordelijk voor één taak.
In de bovenstaande code, de halen functie activeert alleen een AJAX-oproep naar de opgegeven URL. De updatePage functie accepteert sommige gegevens en voegt deze toe aan de DOM. Als we nu een van deze functies willen testen om er zeker van te zijn dat deze werkt zoals verwacht, bijvoorbeeld de updatePage methode, kunnen we het data-object bespotten en doorsturen naar de functie. Gemakkelijk!
Het is belangrijk om te onthouden dat het jQuery-ecosysteem de laatste jaren enorm is gerijpt. De kans is groot dat als je een bepaald onderdeel nodig hebt, iemand anders het al heeft gebouwd. Zeker, blijf plug-ins bouwen om je begrip van de jQuery-bibliotheek te vergroten (in feite zullen we er een in dit artikel schrijven), maar voor real-world gebruik, refereer je naar eventuele bestaande plug-ins voordat je het wiel opnieuw uitvindt.
Heeft u bijvoorbeeld een datumkiezer nodig voor een formulier? Bespaar uzelf het beenwerk en profiteer in plaats daarvan van de community-driven - en zeer geteste - jQuery UI-bibliotheek.
Als u eenmaal naar de benodigde jQuery UI-bibliotheek en het bijbehorende stylesheet verwijst, is het proces van het toevoegen van een datumkiezer aan een invoer net zo eenvoudig als:
Of, hoe zit het met een accordeon? Natuurlijk kun je die functionaliteit zelf schrijven, of, in plaats daarvan, opnieuw profiteren van de gebruikersinterface van jQuery.
Creëer eenvoudig de noodzakelijke markup voor uw project.
Hoofdstuk 1
Een beetje tekst.
Hoofdstuk 2
Een beetje tekst.
Hoofdstuk 3
Een beetje tekst.
Sectie 4
Een beetje tekst.
Dan, automagisch verander het in een accordeon.
$ (function () $ ("# accordeon"). accordeon ();); 
Wat als u in dertig seconden tabbladen zou kunnen maken?
Maak de markup:
- Over ons
- Onze missie
- Neem contact op
Over ons tekst.
Onze missietekst.
Neem contact op met de tekst.
En activeer de plug-in.
$ (function () $ ("# tabs"). tabs ();); Gedaan! Het vereist zelfs geen opvallend begrip van JavaScript.
Laten we nu een paar praktische tips voor het bouwen van jQuery-plug-ins bekijken, die u op een bepaald moment in uw ontwikkelingscarrière zult moeten doen.
We zullen een relatief eenvoudige gebruiken Berichten box plugin als demo voor ons leren. Voel je vrij om mee te werken; in feite, alsjeblieft!
De opdracht: implementeer de nodige functionaliteit om dialoogvensters weer te geven, met behulp van de syntaxis, $ .message ('ZEG NAAR DE GEBRUIKER'). Op deze manier, bijvoorbeeld voordat een record definitief wordt verwijderd, kunnen we de gebruiker vragen om de actie te bevestigen, in plaats van zijn toevlucht te nemen tot inflexibele en lelijke alarm dozen.
De eerste stap is om erachter te komen hoe "activeren" $ .message. In plaats van het prototype van jQuery uit te breiden, hoeven we voor de vereisten van deze plug-in alleen maar een methode aan de jQuery-naamruimte toe te voegen.
(function ($) $ .message = function (text) console.log (text);;) (jQuery);
Het is zo eenvoudig als dat; ga je gang, probeer het! Wanneer je belt $ .bericht ('Hier is mijn bericht'), die string moet worden vastgelegd in de browser console (Shift + Command + i, in Google Chrome).
Hoewel er niet genoeg ruimte is om het proces van het testen van de plug-in te bespreken, is dit een belangrijke stap die u moet onderzoeken. Er is een verbazingwekkend gevoel van zekerheid dat optreedt wanneer de geteste code wordt herschreven.
Als we bijvoorbeeld de testreeks van jQuery, QUnit, gebruiken, kunnen we de code uit stap 1 testen door te schrijven:
module ('jQuery.message', test ('is beschikbaar in de jQuery-naamruimte', 1, functie () ok ($. bericht, 'berichtmethode zou moeten bestaan'););); De OK functie, beschikbaar via QUnit, beweert eenvoudig dat het eerste argument een waarheidswaarde is. Als het bericht methode bestaat niet in de jQuery-naamruimte vals wordt teruggestuurd, in welk geval de test mislukt.
Na het door testen aangestuurde ontwikkelingspatroon zou deze code de eerste stap zijn. Zodra u hebt vastgesteld dat de test mislukt, is de volgende stap om de test toe te voegen bericht methode, dienovereenkomstig.
Hoewel dit artikel om kortheidshalve niet verder ingaat op het proces van testgestuurde ontwikkeling in JavaScript, wordt u aangemoedigd om naar de GitHub-repo voor dit project te verwijzen om alle tests voor de plug-in te bekijken: https: // github .com / JeffreyWay / MessageBox / blob / master / test / MessageBox_test.js
EEN bericht methode die niets doet, helpt niemand! Laten we het meegeleverde bericht nemen en het aan de gebruiker tonen. In plaats van een grote hoeveelheid code in te bedden in de $ .message methode gebruiken we in plaats daarvan gewoon de functie om een a te initialiseren en te initialiseren Bericht voorwerp.
(functie ($) "gebruik strict"; var Message = initialize: function (text) this.text = text; return this;; $ .message = function (text) // Heeft polyfill nodig voor IE8- - return Object.create (Message) .initialize (text);;) (jQuery);
Niet alleen maakt deze aanpak het opnieuw Bericht object meer testbaar, maar het is ook een schonere techniek, die, onder andere, weer terugbellen hel beschermt. Denk hier eens aan Bericht object als de weergave van een enkel berichtvenster.
Als Bericht staat voor een enkel bericht, wat is de HTML voor één? Laten we een maken div met een klasse van berichten box, en maak het beschikbaar voor de Bericht bijvoorbeeld via een el eigendom.
var Message = initialize: function (text) this.el = $ ('', ' class ':' message-box ',' style ':' display: none '); this.text = tekst; geef dit terug; ; Het object heeft nu een directe verwijzing naar de verpakking div voor het berichtenvenster. Om toegang te krijgen, kunnen we het volgende doen:
var msg = Object.create (Message) .initialize (); // [â € <] console.log (msg.el);
Vergeet niet dat we nu een HTML-fragment hebben, maar dit is nog niet in de DOM ingevoegd. Dit betekent dat we ons geen zorgen hoeven te maken over onnodige terugbetalingen bij het toevoegen van inhoud aan de div.
Stap 5
De volgende stap is om de meegeleverde berichtstring op te nemen en in de .stack te plaatsen div. Dat is eenvoudig!
initialiseren: functie (tekst) // ... this.el.html (this.text); // [â € <]
Het is echter onwaarschijnlijk dat we de tekst rechtstreeks in de map willen invoegen div. Realistischer is dat het berichtvenster een sjabloon heeft. We kunnen de gebruiker van de plug-in een sjabloon laten maken en ernaar verwijzen, maar laten we de dingen eenvoudig houden en de sjabloon beperken tot de sjabloon Bericht voorwerp.
var Message = template: function (text, buttons) return [''+ tekst +'
','', toetsen, ''] .join ("); // ...;
In situaties waarin u geen andere keus heeft dan HTML te nestelen in uw JavaScript, is een populaire methode om de HTML-fragmenten op te slaan als items in een array en deze vervolgens samen te voegen in één HTML-tekenreeks.
In dit fragment hierboven wordt de tekst van het bericht nu ingevoegd in een alinea met een klasse van message-box-text. We hebben ook een plaats voor de knoppen ingesteld, die we binnenkort zullen implementeren.
Nu de initialiseren methode kan worden bijgewerkt naar:
initialize: function (text) // ... this.el.html (this.template (text, buttons));
Wanneer geactiveerd, bouwen we de structuur voor het berichtenvenster:
Hier is een belangrijk bericht.
Stap 6
Om het berichtenvenster zo flexibel mogelijk te maken, moet de gebruiker van de plug-in de mogelijkheid hebben om onder andere te specificeren welke knoppen aan de gebruiker moeten worden getoond - zoals "Oké", "Annuleren", "Ja , "enz. We zouden de volgende code moeten kunnen toevoegen:
$ .message ('Weet je het zeker?', buttons: ['Yes', 'Cancel']); ... en genereer een berichtenvenster met twee knoppen.
Om deze functionaliteit te implementeren, moet u eerst de $ .message definitie.
$ .message = function (text, settings) var msg = Object.create (Message); msg.initialiseren (tekst, instellingen); return msg; ;
Nu de instellingen object wordt doorgegeven aan de initialiseren methode. Laten we het updaten.
initialiseren: functie (tekst, instellingen) this.el = $ ('', ' class ':' message-box ',' style ':' display: none '); this.text = tekst; this.settings = instellingen this.el.html (this.template (text, buttons)); Niet slecht, maar wat als de plugin-gebruiker geen instellingen opgeeft? Overweeg altijd de verschillende manieren waarop uw plug-in kan worden gebruikt.
Stap 7
We gaan ervan uit dat de gebruiker van de plug-in zal beschrijven welke knoppen hij moet presenteren, maar om veilig te zijn, is het belangrijk om een reeks standaardwaarden aan te bieden, wat een goede praktijk is bij het maken van plug-ins.
$ .message = function (text, settings) var msg = Object.create (Message); msg.initialiseren (tekst, instellingen); return msg; ; $ .message.defaults = icon: 'info', buttons: ['Okay'], callback: null;
Met deze aanpak moet de gebruiker van de plug-in de standaardinstellingen wijzigen, hij hoeft alleen maar bij te werken $ .message.defaults, zoals nodig. Onthoud: verberg nooit de standaardwaarden van de gebruiker. Maak ze beschikbaar voor 'de buitenkant'.
Hier hebben we een paar standaardinstellingen ingesteld: het pictogram, de knoppen en een callback-functie die moet worden geactiveerd zodra de gebruiker op een van de knoppen in het berichtvenster heeft geklikt.
jQuery biedt een handige manier om de standaardopties voor een plug-in (of een object, echt), via de uitbreiden methode.
initialize: function (text, buttons) // ... this.settings = $ .extend (, $ .message.defaults, settings);
Met deze wijziging, this.settings zal nu gelijk zijn aan een nieuw object. Als de plugin-gebruiker instellingen opgeeft, overschrijven deze de plug-ins defaults voorwerp.
Stap 8
Als we een aangepast pictogram aan het berichtvak willen toevoegen, is het afhankelijk van de actie noodzakelijk om een CSS-klasse aan het element toe te voegen en de gebruiker toe te staan een achtergrondafbeelding toe te passen.
Binnen de initialiseren methode, voeg toe:
this.el.addClass ('message-box-' + this.settings.icon); Als er geen pictogram is opgegeven in de instellingen object, de standaard, info, is gebruikt: .message-box-info. Nu kunnen we een verscheidenheid aan CSS-klassen bieden (buiten het bestek van deze zelfstudie), die verschillende pictogrammen voor het berichtenvenster bevatten. Hier zijn enkele voorbeelden om u op weg te helpen.
.message-box-info background: url (pad / naar / info / icon.png) geen herhaling; . bericht-box-waarschuwing background: url (path / to / warning / icon.png) no-repeat;
In het ideale geval wilt u, als onderdeel van uw MessageBox-plug-in, een externe stylesheet toevoegen met basisstyling voor het berichtvak, deze klassen en een handvol pictogrammen.
Stap 9
De plug-in accepteert nu een reeks knoppen die op de sjabloon moeten worden toegepast, maar we hebben de functionaliteit nog niet geschreven om die informatie bruikbaar te maken. De eerste stap is om een reeks knopwaarden te nemen en die naar de benodigde HTML-invoer te vertalen. Maak een nieuwe methode op de Bericht object om deze taak af te handelen.
createButtons: function (buttons)
jQuery.map is een handige methode die een functie toepast op elk item in een array en een nieuwe array retourneert met de toegepaste wijzigingen. Dit is perfect voor onze behoeften. Voor elk item in de knoppenarray, zoals ['Ja nee'], we willen de tekst vervangen door een HTML-invoer, met de ingestelde waarde dienovereenkomstig.
createButtons: function (buttons) return $ .map (knoppen, functie (button) return ''; ). join ("); Werk vervolgens het initialiseren methode om deze nieuwe methode te noemen.
initialiseren: functie (tekst, instellingen) this.el = $ ('', ' class ':' message-box ',' style ':' display: none '); this.text = tekst; this.settings = $ .extend (, $ .message.defaults, settings); var buttons = this.createButtons (this.settings.buttons); this.el.html (this.template (tekst, knoppen)); geef dit terug;
Stap 10
Wat heb je aan een knop, als er niets gebeurt wanneer de gebruiker erop klikt? Een goede plek om alle gebeurtenislisteners op te slaan voor een weergave, is binnen een special events methode op het bijbehorende object, zoals dit:
initialize: function () // ... this.el.html (this.template (text, buttons)); this.events (); , events: function () var self = this; this.el.find ('input'). on ('klik', functie () self.close (); if (typeof self.settings.callback === 'function') self.settings.callback.call (zelf, $ (dit) .val ());); Deze code is iets complexer, omdat de gebruiker van de plug-in de mogelijkheid moet hebben om zijn eigen callback-functie te activeren, wanneer op een knop op het berichtvenster wordt geklikt. De code bepaalt eenvoudig of een Bel terug functie is geregistreerd en zo ja, activeert deze en verzendt de waarde van de geselecteerde knop. Stel je voor dat een berichtvenster twee knoppen biedt: "Accepteren" en "Annuleren". De gebruiker van de plug-in moet een manier hebben om de waarde van de aangeklikte knop vast te leggen en dienovereenkomstig te reageren.
Let op waar we bellen self.close ()? Die methode, die nog moet worden aangemaakt, is verantwoordelijk voor één ding: het sluiten en verwijderen van het berichtenvenster van de DOM.
close: function () this.el.animate (top: 0, opacity: 'hide', 150, function () $ (this) .remove (););
Om een beetje flair toe te voegen, na het verbergen van het berichtenvenster, vervagen we in de loop van 150 milliseconden de box en verplaatsen deze naar boven.
Stap 11
De functionaliteit is geïmplementeerd! De laatste stap is om het berichtvenster aan de gebruiker te presenteren. We voegen nog een laatste toe laten zien methode op de Bericht object, dat het berichtvenster in de DOM zal invoegen en positioneren.
show: function () this.el.appendTo ('body'). animeren (top: $ (window) .height () / 2 - this.el.outerHeight () / 2, opacity: 'show', 300); Het kost slechts een eenvoudige berekening om het kader verticaal in het midden van het browservenster te plaatsen. Met dat op zijn plaats, is de plug-in voltooid!
$ .message = function (text, settings) var msg = Object.create (Message) .initialize (text, settings); msg.show (); return msg; ;
Stap 12
Als u uw nieuwe plug-in wilt gebruiken, belt u gewoon $ .Message (), en passeren een bericht en alle toepasselijke instellingen, zoals:
$ .message ('De rij is bijgewerkt.'); 
Of om bevestiging te vragen voor een destructieve actie:
$ .message ('Wilt u dit record echt verwijderen?', buttons: ['Yes', 'Cancel'], icon: 'alert', callback: function (buttonText) if (buttonText === 'Ja ') // ga door en verwijder record); 
Gedachten sluiten
Voor meer informatie over jQuery-ontwikkeling, wordt u aangemoedigd om te verwijzen naar mijn cursus op deze site, "30 Days to Learn jQuery."
In de loop van het bouwen van dit monster Berichten box plugin is een aantal best practices ontstaan, zoals het vermijden van callback hell, het schrijven van testbare code, het beschikbaar maken van de standaardopties voor de plugingebruiker en ervoor zorgen dat elke methode verantwoordelijk is voor precies één taak.
Hoewel je zeker hetzelfde effect kunt bereiken door talloze callback-functies in te bedden $ .message, dat doen is zelden een goed idee en wordt zelfs als een antipatroon beschouwd.
Onthoud de drie sleutels voor onderhoudbare code en flexibele jQuery-plug-ins en scripts:
- Kan ik dit testen? Zo niet, refactor en splitst u de code in chunks.
- Heb ik de mogelijkheid geboden om mijn standaardinstellingen te overschrijven?
- Volg ik slechte praktijken of maak ik aannames?
Voor meer informatie over jQuery-ontwikkeling, wordt u aangemoedigd om te verwijzen naar mijn cursus screencast op deze site, "30 Days to Learn jQuery."
