Für diejenigen, die keine langen Intros mögen, lassen Sie uns gleich zu den Schlussfolgerungen kommen - schreiben Sie Tests für Ihre Komponenten. Im Ernst, das ist alles, was ich sagen möchte. Aber nehmen wir das nicht zu ernst. Stellen Sie sich vor, dies sind die Schlussfolgerungen eines Theorems, eines Frontend-Theorems. Und jetzt müssen wir Beweise vorlegen.
Stellen wir uns also vor. Was ist in der IT-Entwicklung nicht nur im Frontend, im Backend oder im Design, in den Programmiersprachen, im Management, in den Methoden und so weiter üblich? Ich denke, es gibt das eine Hauptprinzip - Zersetzung und Bestandteile.
Ob wir es wollen oder nicht, ob wir verstehen, was wir schreiben oder nicht, wir arbeiten mit Komponenten, wir zerlegen Aufgaben immer in kleinere.
Und als ich zum millionsten Mal zusammenkam, um die nächste Implementierung der Tabelle für unser wunderschönes UI-Kit zu schreiben, dachte ich: Welche Vorarbeit muss ich tun? Was genau soll geschrieben werden? Und wo soll ich anfangen?
Nachdem ich mit Teamkollegen gesprochen hatte, hörte ich ein paar Tipps. Ich mochte nur eine. Da ich ein Fan von Singularität und ein bisschen Graphql bin, wurde ich gebeten, überhaupt nichts zu schreiben. Verwenden Sie das Tag {table}, und ein neuronales Netzwerk verarbeitet diese Tabelle, erstellt eine graphql-Abfrage und füllt die Tabelle mit Daten. Einfach :).
Aber wie sie sagen - "es gibt einen fatalen Fehler in jedem System", begann ich darüber nachzudenken, "wie ich mein eigenes Rad erfinden kann". Und kluge Köpfe haben sich schon alles ausgedacht. Wir, die Millennials, können nur die Platten neu anordnen und die Dinge anders benennen.
Ich bin bereit, meine eigenen Prinzipien für das Prototyping von UI-Kits vorzustellen - IDOLS! Lassen Sie uns einen Blick darauf werfen!
Ich stehe für Interface Segregation, D steht für Dependency Inversion, O steht ... nur ein Scherz, natürlich ist es SOLID
Alle Versuche, die Arbeit mit Komponenten zu formalisieren, beschränken sich darauf. Diese Prinzipien können auf unbestimmte Zeit erweitert werden, aber alles ist immer das Endergebnis, das auf diese fünf reduziert wird. Wenn wir natürlich über OOP oder CBP (Component-based Programming) sprechen.
Laden wir diese Prinzipien in unser „RAM“ und gehen wir die Punkte durch.
S - Einzelverantwortung
Hmm, bitte nicht ...
Verwenden Sie für verschiedene Fälle eine spezielle Komponente. Sie sollten KEINE Komponente herstellen, die gleichzeitig etwas abschneiden und abreißen kann. Bilden Sie zwei verschiedene Stücke.
O - Offen / Geschlossen
Das Prinzip besagt, dass Ihre Komponenten offen für Verbesserungen und geschlossen für Änderungen sein sollten. Mit anderen Worten, Sie können Ihre Komponente innerhalb einer anderen Komponente wiederverwenden, aber Sie sollten Ihre Komponente nicht ändern, wenn sie bereits dem Prinzip der Einzelverantwortung entspricht.
L - Liskov-Substitution
Als kleine Erweiterung des vorherigen Prinzips kann jede Instanz einer Unterklasse anstelle einer Instanz der Basisklasse verwendet werden. Ich bin mir nicht sicher, wie dieses Prinzip zum Kontext der Komponenten passt. Höchstwahrscheinlich handelt es sich nur um eine Kopie des vorherigen Prinzips.
I - Schnittstellentrennung
Wir werden darüber noch weiter reden, jetzt können wir sagen, dass es besser ist, dem anderen Entwickler viele kleine Schnittstellen als eine große zu geben, aber für alles. Vergleichen wir die folgenden Beispiele.
Alles wird an einem Ort konfiguriert, nicht wartbar, nicht wiederverwendbar ...
Alles als Konstrukteur, nach Belieben und bequem zusammenbauen
D - Abhängigkeitsinversion
Das Prinzip, dass die verschiedenen Teile der Anwendung nichts voneinander wissen sollten und nur über gemeinsame Schnittstellen vererbt werden sollten. Hier geht es mehr um die Wiederverwendung und Reduzierung der Vernetzung von Komponenten. Die Komponente der Tabelle muss nicht wissen, woher und wie die Daten stammen, sondern muss nur den bedingten DataLoader kennen, der alles Mögliche sein kann.
Aber eine Sichtweise reicht uns nicht aus. Da es in dieser Situation sehr leicht ist, eine Geisel dieser Idee zu werden. Daher betrachten wir die Entwicklung von Bauteilen andererseits von der Konstruktionsseite.
In diesem Fall betrachten wir einen der immer beliebter werdenden Designansätze, nämlich das atomare Design. Relativ gesehen ist das atomare Design eine weitere Möglichkeit, UI-Elemente zu zerlegen, indem sie mit einer Hierarchie aus Physik und Biologie verglichen werden.
Schauen wir uns also an, was Atomic Design ist.
Tokens
Das erste Level sind Token, jemand nimmt dies in das Modell auf, jemand nicht, aber es ist erwähnenswert. Tokens (Farben, Schriftgrößen, Abstände, Animationen) sind alles Grundelemente, die wir auf jeder Plattform wiederverwenden können.
Es ist erwähnenswert, dass die Wiederverwendbarkeit umso mehr abnimmt, je höher wir in der Hierarchie des atomaren Designs sind. Aber dazu später mehr.
Atome
Als nächstes kommen die Atome (einfache Komponenten ohne Logik, Eingänge, Tasten). Die erste Ebene ist, wo die Komponenten erscheinen und was sie ausgeben. Atome haben keinen Status, zeigen nur statische Markups.
Moleküle
Die Atome bauen sich dann zu Molekülen zusammen (komplexere Komponentenbindungen). Moleküle können einen eigenen Status haben, dies ist jedoch kein Geschäftsstatus, sondern ein Konfigurationsstatus (wie isOpen). Wir können vermuten, dass Moleküle eher ein Stellvertreter zwischen dem Top-Geschäftszustand und der Ausrichtung unserer Atome oder des Kindergehalts in Abhängigkeit von diesem Zustand sind.
Moleküle sind die letzte Ebene, auf der wir uns mit Styling treffen können.
Organismen
Moleküle bilden Organismen (integrale Arbeitsgruppen von Komponenten), zum Beispiel eine Kopfzeile, Fußzeile und so weiter. Organismen wissen nichts über andere Organismen und Stile, dies ist unser "Container der DNA", unsere Geschäftslogik, die weiß, wie man dies zeigt und wann es geändert werden sollte.
Vorlagen / Seiten
Die letzte Ebene des atomaren Designs. Diese Ebene repräsentiert die Organismengruppen, die auf der aktuellen Seite enthalten sind.
Wir können die Zusammensetzung der Organismen auf der Seite über Moleküle bestimmen und diese Seite dann als „Layout“ bezeichnen und wiederverwenden, um unsere Organismen darin zu verändern.
Mit diesen beiden Ansätzen (SOLID und Atomic) werden wir versuchen, einige Empfehlungen für die Entwicklung von Komponenten zu formulieren. Diese Empfehlungen sind also erforderlich, damit wir verstehen, was genau wir tun, wenn wir sagen, dass wir eine weitere Komponente erstellen.
In Anbetracht dessen, dass diese Komponenten mit anderen Entwicklern zusammenarbeiten werden, werden wir dies berücksichtigen, wenn wir die Schnittstelle und die API verlegen.
Wir können mit der Entwicklung unserer idealen Schnittstelle beginnen.
Zunächst muss nicht mit der Entwicklung einer idealen Benutzeroberfläche begonnen werden. Die ideale Schnittstelle ist das Fehlen. Eine Schnittstelle ist ein Hindernis zwischen dem, was Sie getan haben, und dem Zeitpunkt, an dem sie zu funktionieren beginnt. Dies ist ein Schmerz, der vermieden werden muss.
Die beste Lösung wäre also:
Dies bringt uns reibungslos zu Folgendem:
1. Bestimmen Sie den Status der Komponente
Wenn ein Entwickler, der diese Komponente zum ersten Mal verwendet, sie sieht, nehmen Sie etwas Zeit für die Integration, übersetzen Sie die Komponente in neue Zustände, wenn die Komplexität der Einstellungen zunimmt, und informieren Sie den Entwickler darüber.
Die Zustände können zu unterschiedlichen Zeiten völlig unterschiedlich sein.
Leer → Laden → Laden → Anderes Teil laden → Vollständig geladen → Fehler usw.
Führen Sie die Entwickler durch alle möglichen Kombinationen von Zuständen und bringen Sie ihnen bei, während sie arbeiten.
Wenn es um Zustandsfragen geht, stößt man unfreiwillig auf das Problem der Ausfallzustände. Deswegen die zweite Empfehlung.
2. Definieren Sie Standardwerte
Mit diesem Element können Sie zwei Fliegen mit einer Klappe schlagen. Sie geben dem Entwickler nicht nur grundlegende Informationen darüber, was mit der Anwendung geschieht, sondern für Sie ist das Fehlen der einen oder anderen Variablen auch keine Überraschung, die alles kaputt macht. Auch hässliche Überprüfungen auf deren Vorhandensein sind grundsätzlich nicht erforderlich.
Wenn der Entwickler weiterhin Einstellungen hinzufügen möchte, ist es erforderlich, ihm dabei zu helfen und sich nicht einzumischen.
Angesichts der Theorie von Richard Gregory erkunden die Menschen die Welt um sich herum auf der Grundlage früherer visueller Erfahrungen. Und wenn Ihre Komponente etwas unter der Haube ändert und Sie den Entwickler darüber informieren möchten, rufen Sie Ihre Hooks und Rückrufe vorhersehbar auf.
3. Das Rad muss nicht neu erfunden werden
Nicht changePasswordInputValue, sondern onChange, denn wenn es sich um Ihr "Molekül" handelt, ist immer klar, wie sich der Wert ändert.
Versuchen Sie, die allgemeinen Namensregeln, das Präfix on für Ereignisse und die Verben für Aktionen zu befolgen. Wenn Sie das Boolesche Flag isDisabled an einer Stelle verwenden, müssen Sie es nicht mehr überall verwenden, isEnabled muss konsistent sein.
Das nächste, worauf Sie achten sollten, ist, dass andere Entwickler weiter daran arbeiten, wenn Sie mit der Arbeit an der Komponente fertig sind und sie weitergeben. Und wenn mit Ihrer Komponente etwas schief geht, müssen Sie einen neuen Entwicklungskreislauf einleiten: Der Entwickler findet einen Fehler oder kann nicht das tun, was er will → öffnet ein Problem → Sie suchen nach einer Zeit, um es zu beheben → die Konsistenz zu berücksichtigen → zu beheben → Pakete aktualisieren → Entwickler benachrichtigen → Pakete aktualisieren → vor einer Woche versuchen, das zu tun, was sie wollten.
4. Versuchen Sie, den Entwicklern so viel Kontrolle wie möglich zu geben
Als ob sie diese Komponente gerade geschrieben hätten - eine direkte Schlussfolgerung aus einem der Prinzipien von SOLID
Angenommen, Sie lassen zu, dass ein Textabschnitt an Ihre Komponente übergeben wird. Wenn dieser Text vorhanden ist, wird er angezeigt. Sie erinnern sich jedoch auch an die Regel zu Standardzuständen und schreiben die Bedingung, dass der Standardtext angezeigt wird, wenn der Text nicht übertragen wird. In einem guten Ton wird der Entwickler explizit darauf hinweisen, dass der Text hier nicht benötigt wird.
Nun, wenn Sie bedenken, dass wir in erster Linie mit atomaren Komponenten arbeiten, dann kommt die folgende Empfehlung von hier.
5. Halten Sie Ihre Komponenten sauber und trocken, damit keine Abstraktionen austreten (KISS).
Wie folgt man dem? - Schreiben Sie ganz einfach keinen Code in Ihre Komponente. Nur die Vorlage und wie sie die Eingabedaten zeichnet. Wenn Sie eine Karte erstellen, filtern und die Daten reduzieren müssen, Sie Konstanten haben, die außerhalb nicht neu definiert werden können, verwendet Ihre Vorlage Literale, was falsch ist - es ist kein Atom mehr, aber etwas anderes, es ist schwieriger zu pflegen. Dies muss vermieden werden.
Wir haben also eine kurze Liste mit Empfehlungen erhalten, denen wir gerne folgen würden.
- Zustand definieren
- Standardwert definieren
- Das Rad nicht neu erfinden
- Lass sie (Entwickler) herrschen
- Halte es einfach, dumm (KISS)
Unser Gehirn ist jedoch so organisiert, dass wir nach dem Schreiben einiger drei Komponenten zu der Annahme kommen, dass wir nicht in diese Liste schauen müssen, um alle Punkte zu überprüfen. Und wir wissen, dass wir unter den komplexeren und einfacheren Aufgaben immer die einfachere wählen, weil es so funktioniert. Wir lieben es, unsere Energie zu sparen, wir brauchen sie in Reserve. Daher gehen solche Listen bis zu besseren Zeiten immer in der Konfluenz verloren, und wir reparieren weiterhin Fehler beim Master.
Nur wenn wir verstehen, dass es im Allgemeinen einfacher ist, es für uns weise zu machen, als zwei Wochen hintereinander nicht zu schlafen und Fehler in der Produktion zu beheben, werden wir die Aufgabe schwieriger (aus objektiven Gründen) und einfacher (für uns) machen Gründe).
Wie können wir dann unser Gehirn täuschen und Empfehlungen abgeben?
Versuchen wir das zu automatisieren.
Automatisierung
Wir können das eslint + lefthook-Bundle oder jedes andere Git-Hook-Tool verwenden.
Wir beschreiben die Regeln, wie wir unsere Variablen sehen möchten und wie unser Code gestaltet werden soll. Wir verbieten magische Zahlen und Literale in Vorlagen, wir erwarten von uns, dass wir sofort Docks für unseren Code schreiben. Wir hängen diese Überprüfungen für einen Git-Hook auf und erhalten automatische Benachrichtigungen, dass unser Code schlecht ist und aktualisiert werden sollte.
Dies ist jedoch keine Wunderwaffe, und wir können nicht alle Empfehlungen erfüllen. Nur ein Teil.
Auf diese Weise können wir nicht mit unseren möglichen Zuständen umgehen und können nicht garantieren, dass andere Entwickler das bekommen, was sie wollen. Wir können zum Beispiel davon ausgehen, dass sowieso etwas zurückkommt (auch Standardwert genannt), aber nicht mehr.
Dann können Sie einen anderen Weg versuchen. Entwickeln Sie unsere Komponenten über SDD. Storybook Driven Development.
Storybook-getriebene Entwicklung
Wir haben eine Story-Datei in der Form, in der wir alle möglichen Zustände der Komponente beschreiben. Und ein Bilderbuch, das diese Geschichten sammelt.
Unsere Geschichten über Komponenten
Wie das Bilderbuch uns Geschichten zeigt
Die Entwicklung Ihrer Komponenten isoliert von der Arbeitsumgebung ist nicht nur ein Plus für die Reinheit der Komponenten, sondern ermöglicht es Ihnen auch, sofort zu erkennen, welche Zustände von den Tests nicht erfasst werden und welche im Prinzip nicht vorhanden sind.
Letztendlich wird uns das aber auch nicht alles geben, was wir wollen.
Daher bleibt nur eines übrig.
Tests und Schnappschüsse
Da es sich bei unseren Komponenten um Atome und Moleküle handelt, ist es ein Vergnügen, Komponententests zu schreiben. Jede Komponente ist für eine Funktion verantwortlich, die wir einfach testen können, indem Sie mehrere Elemente aus der Liste der Empfehlungen auf einmal streichen.
Wir können Snapshot-Checks einrichten, mit denen wir den Zustand unserer Komponenten überwachen und alle zukünftigen Änderungen erfahren können.
Wir können ein Bündel mit einem Enzym verwenden, um unsere Erwartungen während der Entwicklung zu kontrollieren. Und seltsamerweise können, wenn es um Empfehlungen geht, in denen wir etwas von einem Entwickler erwarten, der Code schreibt, nur Tests und deren Schreiben am besten passen. Sie wurden buchstäblich dafür erfunden.
Und los geht's ...
Schreiben Sie Tests für Ihre Komponenten. Vielen Dank