Share
Bei so vielen Leuten, die jQuery-Plugins entwickeln, ist es nicht ungewöhnlich, auf eines zu stoßen, das einfach - mangels besserer Wörter - scheiße ist. Es gibt keine Beispiele oder Dokumentation, das Plugin befolgt keine Best Practices usw. Aber Sie sind einer der Glücklichen: In diesem Artikel werden die Fehler beschrieben, die Sie vermeiden müssen.
jQuery ist denjenigen von Ihnen, die häufig Nettuts + besuchen, kein Fremder. Jeffrey Way's tolle 30 Tage zum Lernen jQuery (und verschiedene andere Tutorials hier und anderswo) haben uns alle den Weg zu Sizzle-Awesomesauce geführt. Bei all dem Hype (und vielen Sprüngen bei der Einführung von JavaScript durch Entwickler und Browser-Anbieter) sind viele Plugins aufgetaucht. Aus diesem Grund ist jQuery die beliebteste verfügbare JavaScript-Bibliothek! Das einzige Problem ist, dass viele von ihnen nicht so toll sind.
In diesem Artikel konzentrieren wir uns weniger auf das JavaScript als vielmehr auf bewährte Vorgehensweisen für die Plugin-Bereitstellung.
Es gibt einige Muster, die mehr oder weniger allgemein als "The Right Way" akzeptiert werden, um jQuery-Plugins zu erstellen. Wenn Sie diese Konventionen nicht befolgen, kann Ihr Plugin… saugen! Betrachten Sie eines der häufigsten Muster:
(Funktion ($, window, undefined) $ .fn.myPlugin = Funktion (Optionen) var defaults = // Festlegen der Standardwerte für Optionen // // Erweitern Sie die Optionen mit den Benutzeroptionen var options = $ .extend (Standardeinstellungen, Optionen || ); return this.each (function () // jQuery-Kettenfähigkeit // do plugin stuff);) (jQuery, window);
Erstens erstellen wir eine anonyme Funktion, die sich selbst ruft, um uns vor der Verwendung globaler Variablen zu schützen. Wir gehen rein $, Fenster, und nicht definiert. Die Argumente, mit denen die selbstaufrufende Funktion aufgerufen wird, sind jQuery und Fenster; Für undefined wird nichts übergeben. Wenn Sie also das undefined-Schlüsselwort im Plugin verwenden, ist "undefined" tatsächlich undefiniert.
Dies schützt vor anderen Skripts, die möglicherweise einen schädlichen Wert zuweisen
nicht definiert, sowiewahr!
$ wird als jQuery übergeben; Wir tun dies auf diese Weise, um sicherzustellen, dass außerhalb der anonymen Funktion, $ kann sich immer noch auf etwas anderes beziehen, z. B. auf Prototyp.
Übergeben der Variablen für den global zugänglichen Fenster object ermöglicht mehr komprimierten Code durch die Minifizierungsprozesse (was Sie auch tun sollten).
Als Nächstes verwenden wir das jQuery-Plugin-Muster, $ .fn.PluginName. Dies ist eine Möglichkeit, Ihr Plugin für die Verwendung mit zu registrieren $ (Selektor) .Methode () Format. Es erweitert einfach den Prototyp von jQuery um Ihre neue Methode. Wenn Sie stattdessen ein Plugin erstellen möchten, das eine Funktion für das jQuery-Objekt definiert, fügen Sie es wie folgt direkt hinzu:
$ .PluginName = Funktion (Optionen) // Optionen erweitern, Plugin erledigen
Diese Art von Plug-In kann nicht verkettet werden, da Funktionen, die als Eigenschaften des jQuery-Objekts definiert sind, das jQuery-Objekt normalerweise nicht zurückgeben. Betrachten Sie zum Beispiel den folgenden Code:
$ .splitInHalf = Funktion (stringToSplit) var length = stringToSplit.length; var stringArray = stringToSplit.split (stringToSplit [Math.floor (Länge / 2)]); return stringArray;
Hier geben wir ein Array von Strings zurück. Es ist sinnvoll, dies einfach als Array zurückzugeben, da dies wahrscheinlich von den Benutzern verwendet wird (und sie können es problemlos in das jQuery-Objekt einschließen, wenn sie möchten). Betrachten Sie das folgende Beispiel:
$ .getOddEls = function (jQcollection) // return jQcollection.filter (function (index) var i = index + 1; return (index% 2! = 0););
In diesem Fall erwartet der Benutzer wahrscheinlich, dass das jQuery-Objekt zurückgegeben wird $ .getOddEls; Daher geben wir die Filtermethode zurück, die die von der übergebenen Funktion definierte jQuery-Auflistung zurückgibt. Eine gute Faustregel besteht darin, die zurückgegebenen Elemente in die jQuery-Funktion einzubinden, insbesondere wenn sie verkettet werden können. Wenn Sie Arrays, Strings, Zahlen, Funktionen oder andere Datentypen zurückgeben, lassen Sie sie unverpackt.
Das Wichtigste, was Sie bei der Veröffentlichung Ihres Codes tun können, ist das Hinzufügen der erforderlichen Dokumentation. Die Lücke zwischen dem, was Sie den Entwicklern erklären, und dem, was der Code tatsächlich tut oder tun kann, ist die Zeit, die Benutzer nicht damit verbringen wollen, die Besonderheiten Ihres Codes herauszufinden.
Dokumentation ist eine Praxis, die keine harten Regeln hat. Es ist jedoch allgemein anerkannt, dass je mehr (gut organisierte) Dokumentation Sie haben, desto besser.
Dieser Prozess sollte sowohl eine interne Übung (innerhalb / durch Ihren Code verteilt) als auch eine externe Übung sein (wobei jede öffentliche Methode, Option und mehrere Anwendungsfälle gründlich in einem Wiki oder Readme erläutert werden)..
Die am häufigsten verwendeten Plugins bieten vollständigen Zugriff auf Variablen (die meisten Plugins beziehen sich auf "Options" -Objekte), die ein Benutzer möglicherweise steuern möchte. Sie können auch viele verschiedene Konfigurationen des Plugins anbieten, so dass es in vielen verschiedenen Kontexten wiederverwendbar ist. Betrachten wir zum Beispiel ein einfaches Slider-Plugin. Zu den Optionen, die der Benutzer möglicherweise steuern möchte, gehören Geschwindigkeit, Typ und Verzögerung der Animation.
Es empfiehlt sich, dem Benutzer auch Zugriff auf Klassennamen / ID-Namen zu gewähren, die den DOM-Elementen hinzugefügt werden, die vom Plugin eingefügt oder bearbeitet werden. Darüber hinaus möchten sie möglicherweise auch auf eine Rückruffunktion zugreifen, wenn die Folie wechselt oder wenn die Folie an den Anfang zurückkehrt (ein vollständiger "Zyklus")..
Es ist Ihre Aufgabe, über alle möglichen Verwendungen und Bedürfnisse des Plugins nachzudenken.
Betrachten wir ein anderes Beispiel: Ein Plugin, das eine API aufruft, sollte den Zugriff auf das zurückgegebene Objekt der API ermöglichen. Nehmen Sie das folgende Beispiel für ein einfaches Plugin-Konzept:.
$ .fn.getFlickr = function (opts) return this.each (function () // jQuery chainability var defaults = // Einstellung Ihrer Standardoptionen cb: function (data) , flickrUrl: // ein Standardwert für einen API-Aufruf // Erweitern Sie die Optionen von den Standardeinstellungen mit den Benutzeroptionen. var options = $ .extend (default, opts || ); // rufen Sie die async-Funktion auf und rufen dann das // Callback-Objekt auf, das übergeben wird $ .ajax wurde zurückgegeben (flickrUrl, Funktion (dataReturned) options.cb.call (this, dataReturned);););
Dies erlaubt uns, etwas zu tun in Richtung:
$ (Selektor) .getFlickr (Funktion (fdata) // Flickr-Daten befinden sich im fdata-Objekt);
Eine andere Möglichkeit, dies zu veröffentlichen, besteht darin, "Haken" als Optionen anzubieten. Ab jQuery 1.7.1 können wir verwenden .ein (eventName, function () ) nach unserem Plugin-Aufruf, um das Verhalten in ihre eigenen Funktionen zu trennen. Mit dem obigen Plugin können wir beispielsweise den Code folgendermaßen ändern:
Accentsconagua
$ .fn.getFlickr = Funktion (Optionen) return this.each (Funktion (i, el) var $ this = el; var defaults = // Einstellung Ihrer Standardoptionen flickrUrl: "http://someurl.com" // ein Standardwert für einen API-Aufruf var options = $ .extend (default, opts || ); // die async-Funktion aufrufen und dann den Callback // aufrufen, der das api-Objekt übergeben hat, das $ .ajax zurückgegeben hat (flickrUrl, Funktion (dataReturned) // erledige etwas $ this.trigger ("callback", dataReturned);). error (function () $ this.trigger ("error", dataReturned);); ); Dies erlaubt uns, die getFlickr Plugin und Verkettung anderer Verhaltenshandler.
$ (Selektor) .getFlickr (Optionen) .on ("Rückruf", Funktion (Daten) // do stuff). on ("error", function () // Fehler behandeln); Sie können sehen, dass das Angebot dieser Art von Flexibilität absolut wichtig ist. Je komplexer die Aktionen Ihrer Plugins sind, desto komplexer sollte die Kontrolle sein, die verfügbar sein sollte.
Ok, Tipp Nummer drei schlug vor, dass die komplexeren Aktionen, die Ihre Plugins haben, die komplexere Steuerung, die sein sollte verfügbar. Ein großer Fehler ist jedoch, dass zu viele Optionen für die Plugin-Funktionalität erforderlich sind. Beispielsweise ist es für UI-basierte Plugins ideal, ein Standardverhalten ohne Argumente zu verwenden.
$ (Selektor) .myPlugin ();
Gewiss ist dies manchmal nicht realistisch (da Benutzer beispielsweise einen bestimmten Feed abrufen). In diesem Fall sollten Sie einige der schweren Übungen für sie durchführen. Sie haben mehrere Möglichkeiten, Optionen an das Plugin zu übergeben. Nehmen wir an, wir haben ein einfaches Tweet-Abruf-Plugin. Es sollte ein Standardverhalten dieses Tweet-Abrufers mit einer einzigen erforderlichen Option (dem Benutzernamen, von dem Sie abrufen möchten) vorhanden sein..
$ (Selektor) .fetchTweets ("jcutrell"); Die Standardeinstellung kann zum Beispiel einen einzelnen Tweet erfassen, ihn in ein Absatz-Tag einschließen und das Auswahlelement mit dieser HTML-Datei füllen. Dies ist die Art von Verhalten, die die meisten Entwickler erwarten und schätzen. Die granularen Optionen sollten genau das sein: Optionen.
Abhängig von der Art des Plugins ist es natürlich unvermeidlich, dass Sie eine CSS-Datei hinzufügen müssen, wenn sie stark auf UI-Manipulationen basiert. Dies ist im Allgemeinen eine akzeptable Lösung für das Problem; Die meisten Plugins werden mit Bildern und CSS geliefert. Aber vergessen Sie nicht Tipp Nummer zwei - Die Dokumentation sollte auch die Verwendung / Referenzierung der Stylesheets und Bilder enthalten. Entwickler möchten keine Zeit damit verbringen, Ihren Quellcode zu durchsuchen, um diese Dinge herauszufinden.
Dinge sollten nur… funktionieren.
Mit dieser Aussage ist es auf jeden Fall eine bewährte Methode, entweder injizierte Styles (die über Plugin-Optionen gut zugänglich sind) oder Klassen- / ID-basierte Stile zu verwenden. Diese IDs und Klassen sollten auch über die oben genannten Optionen zugänglich sein. Inline-Stile überschreiben jedoch externe CSS-Regeln. Es wird davon abgeraten, die beiden zu mischen, da ein Entwickler möglicherweise lange Zeit benötigt, um herauszufinden, warum seine CSS-Regeln von Elementen, die von Ihrem Plugin erstellt werden, nicht beachtet werden. Verwenden Sie in diesen Fällen Ihr bestes Urteilsvermögen.
Als Faustregel gilt, dass Inline-CSS schlecht ist - es sei denn, sie ist so klein, dass sie kein eigenes externes Stylesheet erfordert.
Der Beweis liegt im Pudding: Wenn Sie kein praktisches Beispiel dafür geben können, was Ihr Plugin mit dem zugehörigen Code macht, werden die Benutzer schnell von der Verwendung Ihres Plugins abgeschaltet. So einfach ist das. Sei nicht faul.
Eine gute Vorlage für Beispiele:
Wie jede gute Code-Bibliothek wächst auch jQuery mit jeder Version. Die meisten Methoden werden beibehalten, auch wenn der Support nicht mehr unterstützt wird. Neue Methoden werden jedoch hinzugefügt; Ein perfektes Beispiel dafür ist die .auf() Diese Methode ist die neue All-in-One-Lösung von jQuery für die Delegierung von Ereignissen. Wenn Sie ein Plugin schreiben, das verwendet .auf(), Menschen, die jQuery 1.6 oder eine frühere Version verwenden, haben kein Glück. Nun schlage ich nicht vor, dass Sie für den kleinsten gemeinsamen Nenner kodieren, aber erläutern Sie in Ihrer Dokumentation unbedingt, welche Version von jQuery Ihr Plugin unterstützt. Wenn Sie ein Plugin mit Unterstützung für jQuery 1.7 einführen, sollten Sie unbedingt die Unterstützung für 1.7 in Betracht ziehen, auch wenn 1.8 herauskommt. Sie sollten auch in Betracht ziehen, die neuen / besseren / schnelleren Funktionen in jQuery zu nutzen, sobald diese herauskommen.
Ermutigen Sie Entwickler zu einem Upgrade, aber brechen Sie Ihr Plugin nicht zu oft! Eine Option besteht darin, eine veraltete, nicht unterstützte Version Ihres Plugins "veraltet" anzubieten.
Es ist an der Zeit, die Kugel zu beißen, wenn Sie noch nicht mit der Versionskontrolle vertraut sind.
Neben der Unterstützung der jQuery-Version / Kompatibilität als Teil Ihrer Dokumentation sollten Sie auch in der Versionskontrolle arbeiten. Die Versionskontrolle (speziell über GitHub) ist weitgehend das Zuhause von Social Coding. Wenn Sie ein Plugin für jQuery entwickeln, das Sie schließlich im offiziellen Repository veröffentlichen möchten, muss es trotzdem in einem GitHub-Repository gespeichert werden. Es ist an der Zeit, die Kugel zu beißen, wenn Sie nicht gelernt haben, wie Sie die Versionskontrolle verwenden. Die Versionskontrolle bietet unzählige Vorteile, die alle über den Rahmen dieses Artikels hinausgehen. Einer der Hauptvorteile besteht jedoch darin, dass Benutzer die Änderungen, Verbesserungen und Kompatibilitätskorrekturen anzeigen können, die Sie vornehmen, und wann sie vorgenommen werden. Dies eröffnet auch die Grundlage für den Beitrag und die Anpassung / Erweiterung der Plugins, die Sie schreiben.
Die Welt braucht kein weiteres Slider-Plugin.
Ok, wir haben es hier lange genug ignoriert: Einige "Plugins" sind nutzlos oder zu flach, um den Namen "Plugin" zu rechtfertigen. Die Welt braucht kein weiteres Slider-Plugin! Es ist jedoch zu beachten, dass interne Teams eigene Plugins für ihre eigenen Zwecke entwickeln können, was völlig in Ordnung ist. Wenn Sie jedoch hoffen, Ihr Plugin in die soziale Kodierungssphäre zu integrieren, sollten Sie einen Grund finden, mehr Code zu schreiben. Wie das Sprichwort sagt, gibt es keinen Grund, das Rad neu zu erfinden. Nimm stattdessen das Rad einer anderen Person und baue einen Rennwagen. Natürlich gibt es manchmal neue und bessere Möglichkeiten, die gleichen Dinge zu tun, die bereits gemacht wurden. Zum Beispiel könnten Sie sehr wahrscheinlich ein neues Slider-Plugin schreiben, wenn Sie schnellere oder neue Technologien verwenden.
Dies ist ziemlich einfach: Bieten Sie eine reduzierte Version Ihres Codes an. Dies macht es kleiner und schneller. Es stellt auch sicher, dass Ihr Javascript beim Kompilieren fehlerfrei ist. Vergessen Sie bei der Minimierung des Codes nicht, auch die unkomprimierte Version anzubieten, damit Ihre Kollegen den zugrunde liegenden Code überprüfen können. Für Frontend-Entwickler aller Erfahrungsstufen gibt es kostenlose und kostengünstige Tools.
Informationen zu einer automatisierten Lösung finden Sie unter Tipp Nummer 13.
Wenn Sie ein Plugin schreiben, soll es von anderen verwendet werden, oder? Aus diesem Grund ist der effektivste Quellcode gut lesbar. Wenn Sie unzählige clevere Einzeiler-Lambda-Funktionen schreiben oder Ihre Variablennamen nicht semantisch sind, wird es schwierig sein, Fehler zu debuggen, wenn sie unvermeidlich auftreten. Befolgen Sie die Anweisungen in Tipp Nummer neun (Minify!), Anstatt kurze Variablennamen zu schreiben, um Platz zu sparen. Dies ist ein weiterer Teil einer guten Dokumentation. Anständige Entwickler sollten in der Lage sein, Ihren Code zu überprüfen und zu verstehen, was er tut, ohne zu viel Energie aufwenden zu müssen.
Wenn Sie sich Variablen nennen "
ein" oder "x", Du machst es falsch.
Darüber hinaus, wenn Sie sich in der Dokumentation befinden, um sich daran zu erinnern dein eigenes Seltsam aussehender Code ist wahrscheinlich weniger prägnant und erklärender. Beschränken Sie die Anzahl der Zeilen in jeder Funktion auf so wenig wie möglich. Wenn sie sich über dreißig oder mehr Zeilen erstrecken, könnte ein Codegeruch auftreten.
So sehr wir alle mit jQuery lieben, ist es wichtig zu wissen, dass es sich um eine Bibliothek handelt, und dies ist mit geringen Kosten verbunden. Im Allgemeinen müssen Sie sich nicht allzu viele Gedanken über die Leistung von jQuery Selector machen. Seien Sie nicht abstoßend, und es geht Ihnen gut. jQuery ist stark optimiert. Wenn der einzige Grund für die Verwendung von jQuery (oder eines Plugins) darin besteht, einige Abfragen im DOM auszuführen, sollten Sie die Abstraktion vollständig entfernen und stattdessen Vanille-JavaScript oder Zepto verwenden.
Hinweis: Wenn Sie sich für Vanilla JavaScript entscheiden, stellen Sie sicher, dass Sie Methoden verwenden, die browserübergreifend sind. Möglicherweise benötigen Sie eine kleine Füllmenge für die neueren APIs.
Verwenden Sie Grunt. Zeitraum.
Grunt ist ein "aufgabenbasiertes Befehlszeilentool für JavaScript-Projekte", das kürzlich auf Nettuts + ausführlich behandelt wurde. Damit können Sie folgende Dinge tun:
grunzen init: jquery
Diese (in der Befehlszeile ausgeführte) Zeile fordert Sie auf, eine Reihe von Fragen wie Titel, Beschreibung, Version, Git-Repository, Lizenzen usw. aufzurufen. Diese Informationen helfen bei der Automatisierung des Einrichtens Ihrer Dokumentation, Lizenzierung usw.
Grunt macht weit mehr als nur einen individuellen Boilerplate-Code für Sie. Darüber hinaus bietet es integrierte Tools wie den Code-Interpreter JSHint und kann QUnit-Tests für Sie automatisieren, solange Sie PhantomJS installiert haben (was von Grunt erledigt wird). Auf diese Weise können Sie Ihren Arbeitsablauf rationalisieren, da Tests beim Speichern sofort im Terminal ausgeführt werden.
Oh, übrigens - du tun Testen Sie Ihren Code, richtig? Wenn nicht, wie können Sie sicherstellen, dass Ihr Code wie erwartet funktioniert? Manuelles Testen hat seinen Platz, aber wenn Sie feststellen, dass Sie den Browser unzählige Male pro Stunde aktualisieren, machen Sie es falsch. Erwägen Sie die Verwendung von Werkzeugen wie QUnit, Jasmin oder sogar Mocha.
Das Testen ist besonders nützlich, wenn Sie Pull-Anforderungen auf GitHub zusammenführen. Sie können verlangen, dass alle Anforderungen Tests bereitstellen, um sicherzustellen, dass der neue / geänderte Code Ihr vorhandenes Plugin nicht beschädigt.
Wenn das Konzept des Testens von jQuery-Plugins für Sie völlig neu ist, sollten Sie sich unseren Premium-exklusiven Screencast, Techniques for Test-Driving-jQuery-Plugins, anschauen. Zusätzlich zu dieser Woche starten wir auf der Website einen neuen "JavaScript Testing With Jasmine" -Kurs!
Wir würden Ihnen keinen Gefallen tun, wenn wir Ihnen nur sagen, was Sie falsch machen. Hier sind einige Links, die Ihnen helfen werden, wieder den richtigen Weg zu finden!
Wenn Sie ein jQuery-Plugin schreiben, müssen Sie unbedingt die oben aufgeführten Fallstricke überwinden. Habe ich irgendwelche Schlüsselzeichen eines schlecht ausgeführten Plugins übersehen??
