paint-brush
Muster aus anderen Sprachen und Frameworks zur Verbesserung Ihrer Frontend-Projektevon@playerony
6,172 Lesungen
6,172 Lesungen

Muster aus anderen Sprachen und Frameworks zur Verbesserung Ihrer Frontend-Projekte

von Paweł Wojtasiński5m2023/05/18
Read on Terminal Reader
Read this story w/o Javascript

Zu lang; Lesen

Ich programmiere seit zwölf Jahren und habe mit vielen Sprachen gearbeitet. Es gibt bestimmte Regeln, Werkzeuge und Muster, die ich zu schätzen gelernt habe. Diese Regeln finden bei mir einfach mehr Anklang und machen das Codieren zu einem reibungsloseren Prozess. Mit diesem Artikel möchte ich einige davon teilen.
featured image - Muster aus anderen Sprachen und Frameworks zur Verbesserung Ihrer Frontend-Projekte
Paweł Wojtasiński HackerNoon profile picture
0-item
1-item

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:

Funktionale Programmierung

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.

Codeformatierer

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!

Vorab festgeschriebene Aktionen

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.

Kebab-Fall für Dateinamen

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:


  • Einfachheit : Ich muss mir keine Gedanken darüber machen, ob ich Pascal-Case, Camel-Case oder Snake-Case (falls Sie es vorziehen) verwenden soll. Beim Dönerkoffer gibt es nur eine Möglichkeit.


  • Konsistenz : Wenn Sie in einem Team arbeiten, kann die Übernahme einer einzigen Namenskonvention wie „kebab-case“ dazu beitragen, dass alle auf dem gleichen Stand sind und das Projekt organisiert bleibt. Vergessen Sie nicht, dass Sie die Verwendung von kebab-case über die Eslint-Regel mithilfe des Unicorn- Pakets erzwingen können:


 'unicorn/filename-case': [ 'error', { case: 'kebabCase', }, ],


  • Plattformübergreifende Kompatibilität : Verschiedene Betriebssysteme gehen unterschiedlich mit Dateinamen um. Beispielsweise ist Windows die Groß- und Kleinschreibung egal, Linux hingegen schon. Durch die Verwendung von „kebab-case“, das Kleinbuchstaben und Bindestriche verwendet, vermeide ich Probleme.


  • Keine Git-Probleme : Es gibt ein Problem beim Umbenennen einer Datei von Kleinbuchstaben in Großbuchstaben in Git. Mit der Dönerhülle muss ich mir darüber keine Sorgen machen.


Kent C. Dodds postet auf Twitter, warum er für alle Akten Kebab-Case verwendet.


Ich mag es, die Dinge einfach zu halten. Wenn ich mein Leben einfacher machen und einige Vorteile daraus ziehen kann, bin ich dafür.

Verwenden von Tags für Dateitypen

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.

Automatisieren Sie die Codegenerierung

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.

Verwenden einer „Domain“

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.

Testen Sie Ihre Architektur

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!