Skip to main content
Dieses Dokument enthält die Regeln, die beim Schreiben von Code beachtet werden müssen. Das Ziel ist es, eine konsistente Codebasis zu haben, die leicht lesbar und einfach zu warten ist. Hierfür ist es besser, etwas ausführlicher zu sein als zu knapp. Denken Sie daran, dass Code häufiger gelesen als geschrieben wird, insbesondere bei einem Open-Source-Projekt, zu dem jeder beitragen kann. Es gibt viele Regeln, die hier nicht definiert sind, die aber automatisch durch Linters überprüft werden.

React

Verwenden Sie funktionale Komponenten

Verwenden Sie immer TSX-Funktionskomponenten. Vermeiden Sie import mit const, da es schwieriger zu lesen und schwerer mit Code-Vervollständigung zu importieren ist.

Props

Erstellen Sie den Typ der Eigenschaften (props) und nennen Sie ihn (ComponentName)Props, wenn es nicht notwendig ist, ihn zu exportieren. Verwenden Sie Destrukturierung der Props.

Vermeiden Sie die Verwendung von React.FC oder React.FunctionComponent, um Prop-Typen zu definieren

Kein einzelnes Variablen-Propspreading in JSX-Elementen

Vermeiden Sie das Propspreading einzelner Variablen in JSX-Elementen, wie {...props}. Diese Praxis führt oft zu weniger lesbarem und schwer wartbarem Code, da unklar ist, welche Props die Komponente erhält.
Rational
  • Auf einen Blick ist klarer, welche Props der Code übergibt, was das Verständnis und die Wartung erleichtert.
  • Es verhindert eine enge Kopplung von Komponenten über ihre Props.
  • Linting-Tools erleichtern das Erkennen falsch geschriebener oder unbenutzter Props, wenn Sie Props explizit auflisten.

JavaScript

Verwenden Sie den Nullish-Coalescing-Operator ??

Verwenden Sie optionales Chaining ?.

TypeScript

Verwenden Sie type anstelle von interface

Verwenden Sie immer type anstelle von interface, da sie fast immer überlappen und type flexibler ist.

Verwenden Sie String-Literale anstelle von Enums

String-Literale sind die bevorzugte Methode, um enum-ähnliche Werte in TypeScript zu handhaben. Sie sind einfacher mit Pick und Omit zu erweitern und bieten eine bessere Entwicklererfahrung, vor allem mit Code-Vervollständigung. Warum TypeScript empfiehlt, Enums zu vermeiden, sehen Sie hier.

GraphQL und interne Bibliotheken

Sie sollten die von GraphQL Codegen generierten Enums verwenden. Es ist auch besser, ein Enum zu verwenden, wenn eine interne Bibliothek verwendet wird, damit die interne Bibliothek keinen String-Literal-Typ freigeben muss, der nicht zur internen API gehört. Beispiel:

Styling

Verwenden Sie StyledComponents

Stylen Sie die Komponenten mit Linaria styled.
Prefixen Sie stilisierte Komponenten mit “Styled”, um sie von “echten” Komponenten zu unterscheiden.

Themenbindung

Die Nutzung des Themas für den Großteil der Komponenten-Styling ist der bevorzugte Ansatz.

Einheiten von Messungen

Vermeiden Sie die Verwendung direkter px- oder rem-Werte innerhalb der gestylten Komponenten. Die erforderlichen Werte sind in der Regel bereits im Thema definiert, daher wird empfohlen, das Thema für diese Zwecke zu nutzen.

Farben

Vermeiden Sie es, neue Farben einzuführen; verwenden Sie stattdessen die vorhandene Palette aus dem Thema. Sollte es eine Situation geben, in der die Palette nicht übereinstimmt, hinterlassen Sie bitte einen Kommentar, damit das Team dies korrigieren kann.

Durchsetzung von No-Type Imports

Vermeiden Sie Typ-Importe. Um diesen Standard durchzusetzen, überprüft eine Oxlint-Regel alle Typ-Importe und meldet sie. Dies trägt zur Konsistenz und Lesbarkeit des TypeScript-Codes bei.

Warum keine Typ-Importe?

  • Konsistenz: Durch das Vermeiden von Typ-Importen und die Verwendung eines einzigen Ansatzes für sowohl Typ- als auch Wertimporte bleibt die Modulimportstruktur der Codebasis konsistent.
  • Lesbarkeit: Keine Typ-Importe verbessern die Lesbarkeit des Codes, da klar wird, wann Werte oder Typen importiert werden. Dies reduziert die Zweideutigkeit und erleichtert das Verständnis des Zwecks der importierten Symbole.
  • Wartbarkeit: Es verbessert die Wartbarkeit der Codebasis, da Entwickler Typ-Only-Imports beim Überprüfen oder Ändern von Code identifizieren und lokalisieren können.

Oxlint-Regel

Eine Oxlint-Regel, typescript/consistent-type-imports, setzt den No-Type-Import-Standard durch. Diese Regel generiert Fehler oder Warnungen bei Verstößen gegen Typ-Importe. Bitte beachten Sie, dass diese Regel speziell seltene Randfälle behandelt, in denen unbeabsichtigte Typ-Importe auftreten. TypeScript selbst lehnt diese Praxis ab, wie in den TypeScript 3.8 Release Notes erwähnt. In den meisten Situationen sollten Typ-Only-Imports nicht benötigt werden. Um sicherzustellen, dass Ihr Code mit dieser Regel übereinstimmt, achten Sie darauf, Oxlint als Teil Ihres Entwicklungsworkflows auszuführen.