Schreiben einer API für React-Komponenten, Teil 1: Erstellen Sie keine widersprüchlichen Requisiten
Schreiben einer API für Reaktionskomponenten, Teil 2: Geben Sie dem Verhalten Namen, nicht der Interaktion
Schreiben einer API für React-Komponenten, Teil 3: Die Reihenfolge der Requisiten ist wichtig
Schreiben einer API für React Components, Teil 4: Vorsicht vor der Apropacalypse!
Schreiben einer API für Reaktionskomponenten, Teil 5: Verwenden Sie einfach die Komposition
Wir schreiben API für React-Komponenten, Teil 6: Wir erstellen die Kommunikation zwischen Komponenten
Dieser Beitrag ist eine Übersetzung des ersten Artikels in einer Reihe von Artikeln der Writing Good Component API , die von @Sid verfasst wurde. Bei der Übersetzung werde ich mich in jeder unverständlichen Situation an der offiziellen Übersetzung der React JS-Dokumentation ins Russische orientieren
Wenn es um React-Komponenten geht, sind Ihre Requisiten Ihre API.
Eine gute API sollte verständlich sein, damit der Entwickler selbst herausfinden kann, wie er damit arbeiten soll. Dies gilt nicht nur für die Entwicklung von Komponentenbibliotheken, sondern auch für die Anwendungsentwicklung. Es ist wichtig, dass Sie und Ihr Team mit der Verwendung von Komponenten und deren APIs vertraut sind.
Diese Artikelserie ist inspiriert von Artikeln und Vorträgen von Sebastian Markbåge , Brent Jackson , Jenn Creighton und A. Jesse Jiryu Davis .
Nachdem ich viele Artikel + Vorträge gelesen und mehr als ein Jahr lang das Design des Kosmos- Systems entworfen hatte, kam ich zu diesen Entwicklungsprinzipien.
Beginnen wir mit einem einfachen.
Wir haben einen Knopf:
<Button>Click me</Button>
Möglicherweise benötigen Sie auch die Hauptschaltfläche, die für die Hauptaktion auf der Seite benötigt wird. Früher habe ich die API gerne erstellt, als könnte ich sagen: "Gib mir den Hauptknopf":
<Button>Click me</Button> <Button primary>Click me</Button>
Jetzt, wie es normalerweise bei Schaltflächen der Fall ist, benötigen Sie einige weitere Optionen. Hier ist eine Tabelle mit mehreren Requisiten für Knöpfe:
Es gibt verschiedene Requisiten, mit denen Sie das Erscheinungsbild einer Schaltfläche ändern können. Was passiert, wenn jemand sie zusammen benutzt?
<Button primary destructive> Click me </Button>
Wird einer von ihnen gewinnen? Wovon hängt es ab? Aus der Bestellung?
Warum sollte jemand das schreiben? Gibt es einen realen Fall, in dem Sie sagen müssen "Geben Sie mir einen primary destructive Knopf"?
In den meisten Fällen ist dies ein Fehler. Aber wenn Entwickler überhaupt solche Fragen stellen müssen (wie die oben genannten), ist dies wahrscheinlich keine sehr gute API.
Für diejenigen, die entscheiden, wie die API aussehen soll, ist es wichtig:
- Fehler minimieren
- Minimieren Sie die Verwirrung um die API
Hier ist also Tipp 1: Erstellen Sie keine widersprüchlichen Requisiten.
Wir können den obigen Code ganz einfach mit prop reparieren, wodurch Sie eine Liste von Optionen erhalten. Nennen wir es appearance
<Button appearance="default">Click me</Button> <Button appearance="primary">Click me</Button> <Button appearance="destructive">Click me</Button>
Wir können eine Liste der unterstützten Optionen für das appearance mithilfe von Requisitentypen hinzufügen.
Button.PropTypes = { appearance: PropTypes.oneOf(['default', 'primary', 'secondary', 'link', 'destructive']) }
Selbst wenn der Entwickler einen Fehler macht, wird er in seinem Entwicklungstool darüber gewarnt.
<Button appearance="danger">Click me</Button>
: : `prop` `appearance` `danger` `Button`, : `["default", "primary", "secondary", "link", "destructive"]`
Dieser Tipp ist recht einfach zu implementieren, erleichtert jedoch die Verwendung (und Unterstützung) Ihrer API erheblich.
Von einem Übersetzer - Ich werde die Liste der Artikel in dieser Reihe (zu Beginn) aktualisieren, sobald weitere Artikel übersetzt werden und neue verfügbar werden.