Ich programmiere seit zwölf Jahren und habe mit vielen Sprachen gearbeitet. Dazu gehören C , C++ , Java , Python , C# und schließlich JavaScript . Jede Sprache oder jedes Framework hat ihre eigenen Regeln. Beispielsweise verwendet Rust für Funktionsnamen die Groß-/Kleinschreibung .
Allerdings gibt es bestimmte Regeln, Werkzeuge und Muster, die ich mittlerweile zu schätzen weiß. Diese baue ich in meine Frontend-Anwendungen ein. Diese Regeln finden bei mir einfach mehr Anklang und machen das Codieren zu einem reibungsloseren Prozess. Hier sind einige, die mir besonders gut gefallen:
Mein erster Tipp kommt von C, der ersten Sprache, die ich gelernt habe. Erinnern Sie sich, als wir React mit Klassen geschrieben haben? Wenn ich nur daran denke, bekomme ich Gänsehaut. Als React auf funktionale Komponenten umstieg, wurde der Code nicht nur einfacher zu lesen, sondern auch einfacher zu testen.
Es stimmt auch besser mit den Prinzipien der funktionalen Programmierung überein.
Dieser Ansatz eignet sich hervorragend für Frontend-Frameworks, da diese sich häufig auf die Erstellung wiederverwendbarer Codeteile konzentrieren. Der Einsatz funktionaler Programmierung in der Frontend-Entwicklung war für mich schon immer eine hilfreiche Strategie, um dieses Konzept zu verstehen und auch neue Frontend-Funktionen zu entwickeln.
Das Befolgen der Prinzipien der funktionalen Programmierung ist ein Muss in jeder meiner Frontend-Anwendungen.
Wenn Sie mit funktionaler Programmierung nicht vertraut sind, empfehle ich Ihnen dringend, sich weiter damit zu befassen. Dieser Punkt steht nicht ohne Grund am Anfang dieser Liste. Die Vorteile, die es für Ihren Entwicklungsprozess mit sich bringen kann, sind erheblich.
Als ich zum ersten Mal mit dem Programmieren begann, habe ich der Codeformatierung nicht viel Aufmerksamkeit geschenkt. Ich schätze, alles begann an der Universität, wo ich C++ auf meiner coolen CodeBlocks-IDE mit einem weißen Thema lernte.
Wenn ich mir meinen alten Code von 2016 auf GitHub ansehe, kann ich erkennen, dass ich zur Formatierung nur Leerzeichen verwendet habe. Ich habe keine Tools verwendet, um das automatisch zu erledigen.
Jetzt ist mir klar, dass das ein Fehler war. Wenn Sie in Ihrem Projekt etwas automatisieren können, sollten Sie das auf jeden Fall tun. Jetzt richte ich Prettier und ESLint immer zu Beginn jedes Projekts ein. Wer dafür nicht viel Zeit aufwenden möchte, kann auf vorgefertigte Konfigurationen wie die von Airbnb zurückgreifen.
Vertrauen Sie mir, Sie werden es nicht bereuen!
Oh, und vergessen Sie nicht, in Ihrer IDE eine automatische Formatierung beim Speichern von Dateien einzurichten!
Da Sie nun über fantastische Formatierer verfügen, lasst uns diese automatisieren! Ich kann mich nicht genau erinnern, wann ich angefangen habe, Pre-Commit-Hooks zu verwenden, aber sie waren eine große Hilfe in meinen Projekten. Warum manuell formatieren, wenn es vor jedem Commit automatisiert werden kann? Tools wie Husky und Lint-Staging machen diese Automatisierung möglich.
Auch wenn Angular viele Fans und Kritiker hat, konzentriere ich mich gerne auf das Positive. Angular ist oft die erste Wahl für große Unternehmen und große Anwendungen. Ich denke, dass viele der in Angular getroffenen Entscheidungen darauf abzielten, die Wartung zu vereinfachen.
Deshalb habe ich mich entschieden, kebab-case für alle meine Frontend-Projekte zu verwenden. Es bietet einige Vorteile, wie zum Beispiel:
'unicorn/filename-case': [ 'error', { case: 'kebabCase', }, ],
Ich mag es, die Dinge einfach zu halten. Wenn ich mein Leben einfacher machen und einige Vorteile daraus ziehen kann, bin ich dafür.
Eine andere Sache, die ich von Angular übernommen habe, ist die Benennung von Dateien. Angular empfiehlt, Dateien so zu benennen, dass sie ihre Funktion und ihren Typ widerspiegeln. Ich finde, dass es mir dadurch leichter fällt, mich in der Struktur eines Projekts zurechtzufinden und es zu verstehen. In Angular besteht der Dateiname normalerweise aus drei Teilen: dem Funktionsbereich, der Rolle der Datei und dem Dateityp.
heroes.component.ts
zeigt beispielsweise, dass die Datei eine Komponente für die heroes
Funktion und eine TypeScript-Datei ist. heroes.service.ts
ist ein Dienst für heroes
.
Ich bin kein großer Fan von services
, verwende aber eine ähnliche Struktur für meine React-Komponenten. Hier ist ein Beispiel:
my-component ├── my-component.component.tsx ├── my-component.type.ts ├── my-component.style.css ├── my-component.spec.tsx └── my-component.story.mdx
Ich verwende dieses Muster auch für meine Hooks und Funktionen. Dieses Muster lehrt mich auch, meine Tests neben den zugehörigen Dateien zu platzieren.
Das zuvor erwähnte Muster ist sehr hilfreich, aber wir können es durch Automatisierung noch besser machen. Angular CLI ermöglicht es Benutzern, Code automatisch zu generieren , und ich verwende immer plop , um dasselbe zu tun. Das Vorlagensystem von Plop ist sehr leistungsfähig, aber vor allem spart es Zeit.
Durch die Automatisierung muss ich nicht viel Zeit damit verbringen, über die Grundstruktur einer Komponente nachzudenken. Diese Aufgabe kann automatisiert werden, sodass ich mich auf das konzentrieren kann, was ich wirklich tun möchte.
Ich werde hier nicht im Detail erklären, was eine domain
ist. Wenn Sie mehr darüber erfahren möchten, empfehle ich Ihnen, diesen Artikel zu lesen. Im Moment arbeite ich mit einem Team von Full-Stack-Entwicklern und wir haben festgestellt, dass es wirklich nützlich ist, eine Domänenschicht in unserem Frontend-Projekt zu haben.
Hier platzieren wir alle unsere Haupttypen und Operationen. Es dient als „Quelle der Wahrheit“ in unserer App.
Wenn Sie sehen möchten, wie ich in meinen Apps mit „Domänen“ umgehe, können Sie sich diesen Artikel ansehen. Ich verbringe dort viel Zeit damit, dieses Thema zu beschreiben.
Bei unserer Arbeit mit Kotlin sind wir einmal auf ein Problem gestoßen, bei dem die Logik über mehrere Ebenen hinweg verwechselt wurde, etwa bei der Verwendung eines im Repository innerhalb unserer Domäne definierten Typs. Aus Sicht einer sauberen Architektur ist das ein No-Go, aber jeder macht Fehler.
Da entdeckten wir ArchUnit , ein Tool zum Unit-Testen unserer Architektur. Es prüft grundsätzlich, ob wir unsere Architektur korrekt einhalten.
Wenn Sie eine bestimmte Architektur beibehalten, kann es nützlich sein, über ein Tool zu verfügen, mit dem Sie überprüfen können, ob diese nicht irgendwann kaputt gegangen ist. Ein Tool wie Dependency-Cruiser kann in dieser Hinsicht von unschätzbarem Wert sein.
Und damit ist meine wesentliche Liste von Mustern aus anderen Sprachen und Frameworks zur Verbesserung Ihrer Frontend-Projekte abgeschlossen. Ich hoffe, dass Sie diese Informationen hilfreich fanden und dass mindestens eine dieser Strategien Sie dazu inspiriert hat, sie in Ihrer eigenen Arbeit umzusetzen!