Share
For lenge siden, i en galakse langt, langt unna, var JavaScript et hatet språk. Faktisk er "hatet" en underdrivelse; JavaScript var et foraktet språk. Som et resultat, utviklere utviklet generelt det som sådan, bare tipping sine tær i JavaScript farvann da de trengte å dryss litt flair i sine applikasjoner. Til tross for at det er mye bra i JavaScript-språket, på grunn av utbredt uvitenhet, tok noen seg tid til å lære det riktig. I stedet, som noen av dere kanskje husker, hadde standard JavaScript-bruk en betydelig kopiering og innlasting.
"Ikke bry deg om å lære hva koden gjør, eller om det følger beste praksis, bare lim det inn!" - Verste råd noensinne
Fordi oppgangen av jQuery reignited interesse for JavaScript-språket, er mye av informasjonen på nettet litt sketchy.
Ironisk nok viser det seg at mye av det utviklingssamfunnet hatet hadde svært lite å gjøre med JavaScript-språket, selv. Nei, den virkelige trusselen under masken var DOM, eller "Document Object Model", som spesielt på den tiden var forferdelig inkonsekvent fra nettleseren til nettleseren. "Det kan sikkert fungere i Firefox, men hva med IE8?" Ok, det kan fungere i IE8, men hva med IE7? " Listen gikk utrættelig!
Heldigvis, begynnelsen for fem år siden, ville JavaScript-samfunnet se en utrolig forandring til det bedre, ettersom bibliotekene som jQuery ble introdusert for publikum. Ikke bare ga disse bibliotekene en uttrykksdyktig syntaks som var spesielt attraktiv for webdesignere, men de klarte også å utjevne spillets følelse, ved å tømme løsningen for de ulike nettleserene i API-en. Avtrekker $ .ajax og la jQuery gjøre den harde delen. Raskt frem til i dag, og JavaScript-fellesskapet er mer levende enn noensinne - hovedsakelig på grunn av jQuery-revolusjonen.
Fordi oppgangen av jQuery reignited interesse for JavaScript-språket, er mye av informasjonen på nettet litt sketchy. Dette er mindre på grunn av forfatterens uvitenhet, og mer et resultat av det faktum at vi alle lærte. Det tar tid for beste praksis å dukke opp.
Heldigvis har samfunnet modnet enormt siden de dagene. Før vi dykker inn i noen av disse beste praksiser, la oss først avsløre noen dårlige råd som har sirkulert rundt på nettet.
Problemet med tips som dette er at de tar ideen om preoptimalisering til en ekstrem.
I likhet med Ruby on Rails var mange utviklere første introduksjon til JavaScript gjennom jQuery. Dette fører til en felles syklus: lære jQuery, bli forelsket, grave i vanilje JavaScript og nivå opp.
Mens det absolutt ikke er noe galt med denne syklusen, banet det veien for utallige artikler, som anbefalte brukerne ikke bruk jQuery i ulike situasjoner, på grunn av "ytelsesproblemer." Det ville ikke være uvanlig å lese at det er bedre å bruke vanilje til løkker, over $ .Hver. Eller på et eller annet tidspunkt har du kanskje lest at det er best praksis å bruke document.getElementsByClassName over jQuery's Sizzle-motor, fordi det er raskere.
Problemet med tips som dette er at de tar ideen om forhåndsoptimalisering til en ekstrem, og ikke tar hensyn til ulike nettleseramotsammenhenger - de tingene som jQuery har løst for oss! Å kjøre en test og observere besparelser på noen millisekunder over tusenvis av repetisjoner, er ikke grunn til å forlate jQuery og dens elegante syntaks. Tiden din er mye bedre investert tilpasning av deler av søknaden din, som faktisk vil gjøre en forskjell, for eksempel størrelsen på bildene dine.
Dette andre antimønsteret var igjen et resultat av fellesskapet (inkludert ditt virkelig på et tidspunkt), ikke fullt ut forstått hva som skjedde under jQuery-hetten. Som sådan kom du sannsynligvis over (eller skrev selv) kode, som innpakket et element i jQuery-objektet utallige ganger i en funksjon.
Accentsconagua
$ ('button.confirm'). på ('klikk', funksjon () // Gjør det en gang $ ('.modal'). modal (); // Og en gang til $ ('.modal'). addClass ('aktiv'); // Og igjen med god verdi $ ('modal'). css (...);); Selv om denne koden kanskje først ser ut til å være harmløs (og sannelig er, i det store ordningen av ting), følger vi den dårlige øvelsen for å skape flere forekomster av jQuery-objektet. Hver gang vi refererer til $ ( 'Modal'), et nytt jQuery-objekt blir generert. Er det smart?
Tenk på DOM som et basseng: hver gang du ringer
$ ( 'Modal'), jQuery dykker inn i bassenget, og jakter ned tilhørende mynter (eller elementer). Når du gjentatte ganger spørre DOM for samme velger, kaster du i utgangspunktet disse mynter tilbake i vannet, bare for å hoppe inn og finne dem igjen!
Kjør alltid selektorer hvis du har tenkt å bruke dem mer enn en gang. Den forrige kodestykket kan refactoreres til:
$ ('button.confirm'). på ('klikk', funksjon () $ ('.modal') .modal () .addClass ('aktiv') .css (...);); Alternativt kan du bruke "caching".
$ ('button.confirm'). på ('klikk', funksjon () // Gjør det bare en gang var modal = $ ('modal'); modal.modal (); modal.addClass ('aktiv') ; modal.css (...);); Med denne teknikken hopper jQuery inn i DOM-bassenget totalt en gang, i stedet for tre.
For mye oppmerksomhet blir utbetalt til valgresultatet.
Selv om det ikke er så allestedsnærværende i disse dager, ikke for lenge siden, ble nettverket bombardert av utallige artikler om optimalisering av valgprestasjoner i jQuery. For eksempel er det bedre å bruke $ ('div p') eller $ ( 'Div'). Finne ( 'p')?
Klar for sannheten? Det spiller ingen rolle. Det er absolutt en god ide å ha en grunnleggende forståelse av måten at jQuery's Sizzle-motoren analyserer dine seleksjonsforespørsler fra høyre til venstre (noe som betyr at det er bedre å være mer spesifikk på slutten av selgeren din, i stedet for begynnelsen). Og selvfølgelig, jo mer spesifikk du kan være, desto bedre. Helt klart, $ ( 'A.button') er bedre for ytelse enn $ ( 'Knappen'), på grunn av det faktum at jQuery med den førstnevnte kan begrense søket til bare ankerelementene på siden, i stedet for alle elementene.
Utover det blir det imidlertid for mye oppmerksomhet til selgerytelsen. Når du er i tvil, legg din tillit til at jQuery-teamet består av de fineste JavaScript-utviklerne i bransjen. Hvis det oppnås en opptreden i biblioteket, har de oppdaget det. Og, om ikke dem, vil en av fellesskapsmedlemmene sende inn en trekkforespørsel.
Med dette i bakhodet, vær oppmerksom på dine valgører, men bekymre deg ikke for mye med prestasjonsimplikasjoner, med mindre du kan verbalisere hvorfor det er nødvendig.
jQuery har oppmuntret utbredt bruk av tilbakeringingsfunksjoner, noe som sikkert kan gi en god bekvemmelighet. I stedet for å deklarere en funksjon, bruk bare en tilbakeringingsfunksjon. For eksempel:
$ ('a.external'). på ('klikk', funksjon () // denne tilbakeringingsfunksjonen utløses // når .external er klikket); Du har sikkert skrevet masse kode som ser ut som dette; Jeg vet jeg har! Når de brukes sparsomt, tjener anonyme tilbakeringingsfunksjoner som nyttige bekvemmeligheter. Gni oppstår nedover linjen, når vi går inn ... callback hell (trigger thunderbolt lyd)!
Tilbakekall helvete er når koden din strekker seg mange ganger, mens du fortsetter å neste tilbakeringingsfunksjoner.
Tenk på følgende ganske vanlig kode nedenfor:
$ ('a.data') på ('klikk', funksjon () var anker = $ (dette); $ (dette) .fadeOut (400, funksjon () $ .ajax (// ... suksess: funksjon (data) anchor.fadeIn (400, funksjon () // du har nettopp angitt tilbakeringing helvete);););); Som en grunnleggende tommelfingerregel, jo mer innrykkede koden din er, jo mer sannsynlig at det er en kode lukt. Eller, bedre enda, spør deg selv, ser koden min ut som Mighty Ducks Flying V?
Når refactoring kode som dette, er nøkkelen å spørre deg selv, "Hvordan kunne dette bli testet?" Innenfor denne tilsynelatende enkle koden er en hendelseslytter bundet til en kobling, elementet fades ut, et AJAX-anrop blir utført. Etter suksess vil elementet falle tilbake, antagelig vil de resulterende dataene bli vedlagt et sted. Det er sikkert mye å teste!
Ville det ikke vært bedre å dele denne koden i mer håndterbare og testbare biter? Sikkert. Selv om følgende kan optimaliseres ytterligere, kan et første skritt for å forbedre denne koden være:
var updatePage = funksjon (el, data) // legge til hentet data til DOM; var hente = funksjon (ajaxOptions) ajaxOptions = ajaxOptions || // url: ... // dataType: ... suksess: updatePage; returnere $ .ajax (ajaxOptions); ; $ ('a.data'). på ('klikk', funksjon () $ (dette) .fadeOut (400, hente);); Enda bedre, hvis du har en rekke handlinger for å utløse, inneholder de relevante metodene i et objekt.
Tenk på hvordan i en fastmatrestaurant, som McDonalds, er hver arbeidstaker ansvarlig for en oppgave. Joe gjør frites, Karen registrerer kunder, og Mike griller burgere. Hvis alle tre medarbeiderne gjorde alt, ville dette introdusere en rekke vedlikeholdsproblemer. Når endringer må gjennomføres, må vi møte hverandre for å diskutere dem. Men hvis vi for eksempel holder Joe utelukkende fokusert på pommes frites, må vi justere instruksjonene for å lage frites, vi trenger bare å snakke med Joe og ingen andre. Du bør ta en lignende tilnærming til koden din; hver funksjon er ansvarlig for en oppgave.
I koden ovenfor er hente funksjon utløser bare et AJAX-anrop til den angitte nettadressen. De updatePage funksjonen aksepterer noen data, og legger den til DOM. Nå, hvis vi vil teste en av disse funksjonene for å sikre at den fungerer som forventet, for eksempel updatePage Metode, vi kan spotse dataobjektet og sende det til funksjonen. Lett!
Det er viktig å huske at jQuery-økosystemet har utviklet seg sterkt de siste årene. Sjansen er, hvis du har behov for en bestemt komponent, har noen andre allerede bygget den. Forsikre deg om at du fortsetter å bygge plugin-moduler for å øke forståelsen av jQuery-biblioteket (faktisk, vi skriver en i denne artikkelen), men for bruk i sanntid, se eventuelle mulige eksisterende plugins før du gjenoppfinner hjulet.
Som et eksempel, trenger du en datovelger for et skjema? Lagre deg på benprosjektet, og bruk istedenfor det community-driven - og svært testet - jQuery UI-biblioteket.
Når du har referert til det nødvendige jQuery UI-biblioteket og tilhørende stilark, er prosessen med å legge til en datovelger til en inngang like enkelt som å gjøre:
Eller hva med et trekkspill? Jo, du kan skrive den funksjonaliteten selv, eller i stedet, igjen, dra nytte av jQuery UI.
Du må bare opprette den nødvendige oppslaget for prosjektet ditt.
Kapittel 1
Noen tekst.
Kapittel 2
Noen tekst.
kapittel 3
Noen tekst.
Seksjon 4
Noen tekst.
Deretter, auto gjør det til et trekkspill.
$ (funksjon () $ ("# trekkspill"). trekkspill ();); 
Hva om du kan lage faner på tretti sekunder?
Lag oppmerkningen:
- Om oss
- Vårt oppdrag
- Ta kontakt
Om oss tekst.
Vår misjonstekst.
Få kontakttekst.
Og aktiver pluggen.
$ (funksjon () $ ("# faner"). faner ();); Ferdig! Det krever ikke en merkbar forståelse av JavaScript.
La oss nå grave inn noen gode fremgangsmåter for å bygge jQuery-plugins, som du er bundet til å gjøre på et tidspunkt i din utviklingskarriere.
Vi vil bruke en relativt enkel Meldingsboks plugin som demo for vår læring. Føl deg fri til å jobbe sammen; Faktisk, vær så snill!
Oppgaven: implementer den nødvendige funksjonaliteten for å vise dialogbokser, ved hjelp av syntaksen, $ .message ("SEG TIL BRUKEREN"). På denne måten, for eksempel før du sletter en plate permanent, kan vi be brukeren om å bekrefte handlingen, i stedet for å bruke ubøyelig og stygg varsling esker.
Det første trinnet er å finne ut hvordan man kan "aktivere" $ .message. I stedet for å utvide jQuery's prototype, for dette pluginens krav, trenger vi bare å legge ved en metode til jQuery navneområdet.
(funksjon ($) $ .message = funksjon (tekst) console.log (text);;) (jQuery);
Det er like enkelt som det; Fortsett, prøv det! Når du ringer $ .message ('Her er min melding'), den strengen skal logges til nettleserens konsoll (Shift + Command + i, i Google Chrome).
Selv om det ikke er nok plass til å dekke prosessen med å teste plugin-modulen, er dette et viktig skritt som du bør undersøke. Det er en fantastisk følelse av trygghet som oppstår, når refactoring testet kode.
For eksempel, når du bruker jQuery's testpakke, QUnit, kunne vi teste kjøre koden fra trinn 1 ved å skrive:
modul ('jQuery.message', test ('er tilgjengelig på jQuery namespace', 1, funksjon () ok $. melding, 'meldingsmetode bør eksistere'););; De ok funksjon, tilgjengelig gjennom QUnit, hevder bare at det første argumentet er en sannhetsverdi. Hvis budskap Metoden eksisterer ikke på jQuery-navneområdet, da falsk vil bli returnert, da testen mislykkes.
Etter det testdrevne utviklingsmønsteret vil denne koden være det første trinnet. Når du har observert testfeilen, ville neste trinn være å legge til budskap metode, tilsvarende.
Selv om denne artikkelen ikke vil fordyre seg videre i prosessen med testdrevet utvikling i JavaScript, er du oppfordret til å henvise til GitHub repo for dette prosjektet for å se gjennom alle tester for plugin: https: // github .com / JeffreyWay / messagebox / klump / master / test / MessageBox_test.js
EN budskap Metode som ikke gjør noe, er ikke til hjelp for noen! La oss ta den medfølgende meldingen og vise den til brukeren. Imidlertid, i stedet for å legge inn en stor glob med kode i $ .message metode, vil vi i stedet bare bruke funksjonen til å instantiere og initialisere en Budskap gjenstand.
(funksjon ($) "bruk strenge"; var Message = initialiser: funksjon (tekst) this.text = text; return dette;;; $ .message = funksjon (tekst) // Trenger polyfill for IE8- - returner Object.create (Message). initialiser (tekst);;) (jQuery);
Ikke bare gjør denne tilnærmingen igjen Budskap gjenstand mer testbar, men det er også en renere teknikk, som blant annet beskytter igjen tilbakekalling helvete. Tenk på dette Budskap objekt som representasjon av en enkelt meldingskasse.
Hvis Budskap representerer en enkelt meldingskasse, hva blir HTML for en? La oss lage en div med en klasse av meldingsboks, og gjør det tilgjengelig for Budskap eksempel via en el eiendom.
var Message = initialiser: funksjon (tekst) this.el = $ ('', ' class ':' message-box ',' style ':' display: none '); this.text = text; returnere dette; ; Nå har objektet en umiddelbar referanse til innpakningen div for meldingsboksen. For å få tilgang til det, kunne vi gjøre:
var msg = Object.create (Message) .initialize (); // [â € "console.log (msg.el);
Husk at vi nå har et HTML-fragment, men det har ikke blitt lagt inn i DOM. Dette betyr at vi ikke trenger å bekymre deg for unødvendige reflows når du legger til innhold i div.
Trinn 5
Det neste trinnet er å ta den angitte meldingsstrengen, og sett den inn i div. Det er enkelt!
initialiser: funksjon (tekst) // ... this.el.html (this.text); // [â € <]
Det er imidlertid lite sannsynlig at vi ønsker å sette inn teksten direkte inn i div. Mer realistisk vil meldingsboksen ha en mal. Mens vi kunne la brukeren av plugin lage en mal og referere den, la oss holde ting enkelt og begrense malen til Budskap gjenstand.
var Message = mal: funksjon (tekst, knapper) return [''+ tekst +'
','', knapper'' ].bli med("); //… ;
I situasjoner, når du ikke har annet valg enn å neste HTML i JavaScript, er en populær tilnærming å lagre HTML-fragmentene som elementer i en matrise, og deretter bli med i en HTML-streng.
I denne teksten ovenfor blir meldingsteksten nå satt inn i et avsnitt med en klasse av message-box-tekst. Vi har også satt et sted for knappene, som vi skal implementere kort tid.
Nå, den initial Metoden kan oppdateres til:
initialiser: funksjon (tekst) // ... this.el.html (this.template (tekst, knapper));
Når utløses, bygger vi strukturen for meldingsboksen:
Her er en viktig melding.
Trinn 6
For at meldingsboksen skal være så fleksibel som mulig, må brukeren av pluginet ha muligheten til å spesifisere blant annet hvilke knapper som skal presenteres for brukeren - for eksempel "OK", "Avbryt", "Ja , "osv. Vi bør kunne legge til følgende kode:
$ .message ('Er du sikker?', knapper: ['Ja', 'Avbryt']); ... og generer en meldingskasse med to knapper.
For å implementere denne funksjonaliteten, må du først oppdatere $ .message definisjon.
$ .message = funksjon (tekst, innstillinger) var msg = Object.create (Melding); msg.initialize (tekst, innstillinger); returner msg; ;
Nå, den innstillinger objektet vil bli sendt videre til initial metode. La oss oppdatere den.
initialiser: funksjon (tekst, innstillinger) this.el = $ ('', ' class ':' message-box ',' style ':' display: none '); this.text = text; this.settings = innstiller this.el.html (this.template (tekst, knapper)); Ikke dårlig, men hva om plugin-brukeren ikke angir noen innstillinger? Overvei alltid de ulike måtene du kan bruke på plugin.
Trinn 7
Vi antar at brukeren av pluginet vil beskrive hvilke knapper som skal presenteres, men for å være trygg, er det viktig å angi et sett av standardinnstillinger, som er en god praksis når du lager plugins.
$ .message = funksjon (tekst, innstillinger) var msg = Object.create (Melding); msg.initialize (tekst, innstillinger); returner msg; ; $ .message.defaults = ikon: 'info', knapper: ['Okay'], tilbakeringing: null;
Med denne tilnærmingen, bør plugin-brukeren endre standardinnstillingene, han trenger bare å oppdatere $ .message.defaults, etter behov. Husk: aldri skjul standardinnstillingene fra brukeren. Gjør dem tilgjengelige for "utsiden".
Her har vi angitt noen standardverdier: ikonet, knappene og en tilbakeringingsfunksjon, som skal utløses, når brukeren har klikket på en av knappene i meldingsboksen.
jQuery tilbyr en nyttig måte å overstyr standardinnstillingene for et plugin (eller noe objekt, egentlig), via sin forlenge metode.
initialiser: funksjon (tekst, knapper) // ... this.settings = $ .extend (, $ .message.defaults, settings);
Med denne modifikasjonen, this.settings vil nå være lik et nytt objekt. Hvis plugin-brukeren angir noen innstillinger, vil de overstyre pluginens mislighold gjenstand.
Trinn 8
Hvis vi har til hensikt å legge til et egendefinert ikon i meldingsboksen, avhengig av handlingen, vil det være nødvendig å legge til en CSS-klasse til elementet, og la brukeren legge til et bakgrunnsbilde tilsvarende.
Innen initial metode, legg til:
this.el.addClass ('message-box-' + this.settings.icon); Hvis ingen ikon er angitt i innstillinger objekt, standard, info, benyttes: .message-box-info. Nå kan vi tilby en rekke CSS-klasser (utenfor omfanget av denne opplæringen), som inneholder forskjellige ikoner for meldingsboksen. Her er et par eksempler for å komme i gang.
.meldingskasse-info bakgrunn: url (sti / til / info / ikon.png) ingen gjentakelse; .message-box-advarsel bakgrunn: url (sti / til / advarsel / icon.png) no-repeat;
Ideelt sett vil du, som en del av MessageBox-pluginet ditt, inkludere et eksternt stilark som inneholder grunnleggende styling for meldingsboksen, disse klassene og en håndfull ikoner.
Trinn 9
Tillegget aksepterer nå en rekke knapper som skal brukes på malen, men vi har ennå ikke skrevet funksjonaliteten for å gjøre denne informasjonen brukbar. Det første trinnet er å ta en rekke knappverdier, og oversette det til de nødvendige HTML-inngangene. Lag en ny metode på Budskap Motta å håndtere denne oppgaven.
createButtons: funksjon (knapper)
jQuery.map er en nyttig metode som gjelder en funksjon for hvert element i en matrise, og returnerer et nytt utvalg med de påførte endringene. Dette er perfekt for våre behov. For hvert element i knappene array, for eksempel ['Ja Nei'], Vi vil erstatte teksten med en HTML-inngang, med verdien satt, tilsvarende.
createButtons: funksjon (knapper) return $ .map (knapper, funksjon (knapp) return ''; ).bli med("); Deretter oppdaterer du initial metode for å ringe denne nye metoden.
initialiser: funksjon (tekst, innstillinger) this.el = $ ('', ' class ':' message-box ',' style ':' display: none '); this.text = text; this.settings = $ .extend (, $ .message.defaults, settings); var knapper = this.createButtons (this.settings.buttons); this.el.html (this.template (tekst, knapper)); returnere dette;
Trinn 10
Hvor god er en knapp, hvis ingenting skjer når brukeren klikker på det? Et godt sted å lagre alle hendelseslyttere for en visning er innenfor en spesiell arrangementer metode på det tilknyttede objektet, slik som dette:
initialiser: funksjon () // ... this.el.html (this.template (tekst, knapper)); this.events (); , hendelser: funksjon () var selv = dette; this.el.find ('input'). på ('klikk', funksjon () self.close (); if (typeof self.settings.callback === 'funksjon') self.settings.callback.call (selv, $ (dette) .val ());); Denne koden er litt mer kompleks, fordi brukeren av pluginet må ha muligheten til å utløse sin egen tilbakeringingsfunksjon, når en knapp klikkes på meldingsboksen. Koden bestemmer bare om a Ring tilbake funksjonen ble registrert, og i så fall utløser den, og sender gjennom den valgte knappens verdi. Tenk deg at en meldingskasse har to knapper: "Godta" og "Avbryt". Brukeren av pluginet må ha en måte å fange den klikkte knappens verdi på, og svare på det.
Legg merke til hvor vi ringer self.close ()? Denne metoden, som ennå ikke er opprettet, er ansvarlig for en ting: lukking og fjerning av meldingsboksen fra DOM.
lukk: funksjon () this.el.animate (top: 0, opacity: 'hide', 150, funksjon () $ (dette) .remove (););
For å legge til litt flair, ved å gjemme meldingsboksen, vi, i løpet av 150 millisekunder, fade ut boksen og overgang den oppover.
Trinn 11
Funksjonaliteten er implementert! Det siste trinnet er å presentere meldingsboksen til brukeren. Vi legger til en siste vise fram metode på Budskap objekt, som vil sette inn meldingsboksen i DOM, og plassere den.
vis: funksjon () this.el.appendTo ('body'). animate (top: $ (vindu) .height () / 2 - this.el.outerHeight () / 2, opacity: 'show', 300); Det tar bare en enkel beregning å plassere boksen vertikalt i midten av nettleservinduet. Med det på plass, er pluginet fullført!
$ .message = funksjon (tekst, innstillinger) var msg = Object.create (Message). initialisere (tekst, innstillinger); msg.show (); returner msg; ;
Trinn 12
For å bruke det nye pluginet, ring bare $ .Message (), og passere gjennom en melding og eventuelle gjeldende innstillinger, slik som:
$ .message ('Raden har blitt oppdatert.'); 
Eller, for å be om bekreftelse for noen destruktiv handling:
$ .message ('Vil du virkelig slette denne posten?', knapper: ['Ja', 'Avbryt'], ikon: 'varsling', tilbakeringing: funksjon (buttonText) if (buttonText === 'Ja ') // fortsett og slett rekord); 
Avsluttende tanker
For å lære mer om jQuery-utvikling, oppfordres du til å referere til kurset mitt på dette nettstedet, "30 dager for å lære jQuery."
I løpet av byggingen av denne prøven Meldingsboks plugin, en rekke beste fremgangsmåter har dukket opp, for eksempel å unngå tilbakeringing i helvete, skrive testbar kode, å gjøre standardalternativene tilgjengelige for plugin-brukeren og sikre at hver metode er ansvarlig for nøyaktig én oppgave.
Mens man sikkert kunne oppnå samme effekt ved å inkludere utallige tilbakeringingsfunksjoner innenfor $ .message, å gjøre det er sjelden en god ide, og er selv betraktet som et anti-mønster.
Husk de tre tastene til vedlikeholdsbar kode og fleksible jQuery-plugins og skript:
- Kan jeg teste dette? Hvis ikke, refactor og del koden i biter.
- Har jeg tilbudt muligheten til å overstyre standardinnstillingene mine?
- Følger jeg dårlige rutiner eller antagelser?
Hvis du vil lære mer om jQuery-utvikling, oppfordres du til å referere til mitt screencast-kurs på dette nettstedet, "30 dager for å lære jQuery."
