Das Material, dessen Übersetzung wir heute veröffentlichen, zeigt die Ansätze des Autors bei der Strukturierung von React-Anwendungen. Insbesondere werden wir hier die verwendete Ordnerstruktur, die Benennung von Entitäten, die Orte, an denen sich die Testdateien befinden, und andere ähnliche Dinge diskutieren.
Eine der angenehmsten Eigenschaften von React ist, dass diese Bibliothek den Entwickler nicht zwingt, bestimmte Konventionen bezüglich der Struktur des Projekts strikt einzuhalten. Vieles davon liegt im Ermessen des Programmierers. Dieser Ansatz unterscheidet sich von dem, der beispielsweise in den Ember.js- oder Angular-Frameworks verwendet wird. Sie bieten Entwicklern mehr Standardfunktionen. Diese Frameworks enthalten Konventionen zur Struktur von Projekten und Regeln zum Benennen von Dateien und Komponenten.
Persönlich mag ich den Ansatz von React. Tatsache ist, dass ich es vorziehe, etwas selbst zu kontrollieren, ohne mich auf bestimmte „Vereinbarungen“ zu verlassen. Der Ansatz zur Strukturierung von Projekten, den Angular bietet, bietet jedoch viele Vorteile. Die Wahl zwischen Freiheit und mehr oder weniger strengen Regeln hängt davon ab, was Ihnen und Ihrem Team näher kommt.
In den Jahren der Arbeit mit React habe ich viele verschiedene Möglichkeiten ausprobiert, um Anwendungen zu strukturieren. Einige der Ideen, die ich angewendet habe, erwiesen sich als erfolgreicher als andere. Deshalb werde ich hier über alles sprechen, was sich in der Praxis gut gezeigt hat. Ich hoffe, Sie finden hier etwas, das Ihnen nützlich ist.
Ich versuche hier nicht, eine "nur richtige" Art der Strukturierung von Anwendungen aufzuzeigen. Sie können einige meiner Ideen aufgreifen und an Ihre Bedürfnisse anpassen. Sie können mir durchaus widersprechen, wenn Sie weiterarbeiten wie zuvor. Unterschiedliche Teams erstellen unterschiedliche Anwendungen und verwenden unterschiedliche Mittel, um ihre Ziele zu erreichen.
Es ist wichtig zu beachten, dass Sie, wenn Sie sich die
Thread- Website ansehen, an der ich beteiligt bin, und das Gerät der Benutzeroberfläche ansehen, Orte finden, an denen die Regeln, über die ich sprechen werde, nicht eingehalten werden. Tatsache ist, dass alle „Regeln“ in der Programmierung nur als Empfehlungen und nicht als umfassende Standards verstanden werden sollten, die in jeder Situation gültig sind. Und wenn Sie der Meinung sind, dass eine Art von "Regeln" nicht zu Ihnen passt, sollten Sie die Kraft finden, von diesen "Regeln" abzuweichen, um die Qualität Ihrer Arbeit zu verbessern.
Eigentlich biete ich Ihnen jetzt ohne weiteres meine Geschichte über die Strukturierung von React-Anwendungen an.
Mach dir keine Sorgen über die Regeln.
Vielleicht entscheiden Sie, dass die Empfehlung, dass Sie sich nicht zu viele Gedanken über die Regeln machen, zu Beginn unseres Gesprächs seltsam erscheint. Aber genau das meine ich, wenn ich sage, dass der Hauptfehler, den Programmierer bei der Einhaltung der Regeln haben, darin besteht, dass die Programmierer den Regeln zu viel Bedeutung beimessen. Dies gilt insbesondere zu Beginn der Arbeit an einem neuen Projekt. Zum Zeitpunkt der Erstellung der ersten
index.jsx einfach unmöglich zu wissen, was für dieses Projekt am besten ist. Während sich das Projekt entwickelt, werden Sie natürlich zu einer Art Datei- und Ordnerstruktur kommen, die für dieses Projekt wahrscheinlich recht gut ist. Wenn sich während der Fortsetzung der Arbeit herausstellt, dass die vorhandene Struktur etwas erfolglos ist, kann sie verbessert werden.
Wenn Sie dies lesen und sich denken, dass in Ihrer Anwendung nichts besprochen wird, ist dies kein Problem. Jede Anwendung ist einzigartig, es gibt keine zwei absolut identischen Entwicklungsteams. Daher trifft jedes Team, das an einem Projekt arbeitet, einige Vereinbarungen hinsichtlich seiner Struktur und Arbeitsweise. Dies hilft den Teammitgliedern, produktiv zu arbeiten. Versuchen Sie nicht, sich sofort vorzustellen, nachdem Sie erfahren haben, wie jemand etwas tut. Versuchen Sie nicht, in Ihre Arbeit das einzuführen, was in bestimmten Materialien genannt wird, und auch dies ist der "effektivste Weg", ein Problem zu lösen. Ich habe mich in Bezug auf solche Empfehlungen immer an die folgende Strategie gehalten und diese eingehalten. Ich habe meine eigenen Regeln, aber wenn ich lese, wie andere in bestimmten Situationen handeln, wähle ich, was mir erfolgreich und für mich geeignet erscheint. Dies führt dazu, dass sich meine Arbeitsmethoden im Laufe der Zeit verbessern. Gleichzeitig habe ich keine Schocks und es besteht keine Lust, alles von Grund auf neu zu schreiben.
Wichtige Komponenten befinden sich in separaten Ordnern
Der Ansatz zum Platzieren von Komponentendateien in Ordnern, zu denen ich gekommen bin, besteht darin, dass diejenigen Komponenten, die im Anwendungskontext als "wichtig", "grundlegend", "grundlegend" angesehen werden können, in separaten Ordnern abgelegt werden. Diese Ordner befinden sich wiederum im
components . Wenn es sich beispielsweise um eine Anwendung für ein elektronisches Geschäft handelt, kann die zur Beschreibung des Produkts verwendete
<Product> -Komponente als ähnliche Komponente erkannt werden. Folgendes meine ich:
- src/ - components/ - product/ - product.jsx - product-price.jsx - navigation/ - navigation.jsx - checkout-flow/ - checkout-flow.jsx
In diesem Fall befinden sich die "sekundären" Komponenten, die nur von bestimmten "Haupt" -Komponenten verwendet werden, im selben Ordner wie diese "Haupt" -Komponenten. Dieser Ansatz hat sich in der Praxis bewährt. Tatsache ist, dass aufgrund seiner Anwendung eine bestimmte Struktur im Projekt angezeigt wird, die Ebene der Ordnerverschachtelung jedoch nicht zu groß ist. Seine Anwendung führt nicht zum Erscheinen von etwas wie
../../../ in den Komponentenimportbefehlen, es macht es nicht schwierig, sich im Projekt zu bewegen. Mit diesem Ansatz können Sie eine klare Hierarchie von Komponenten erstellen. Diese Komponente, deren Name mit dem Namen des Ordners übereinstimmt, wird als "grundlegend" betrachtet. Andere Komponenten, die sich im selben Ordner befinden, dienen dazu, die "Basiskomponente" in Teile zu unterteilen, was die Arbeit mit dem Code dieser Komponente und ihrer Unterstützung vereinfacht.
Obwohl ich das Vorhandensein einer bestimmten Ordnerstruktur im Projekt unterstütze, glaube ich, dass das Wichtigste die Auswahl guter Dateinamen ist. Ordner selbst sind weniger wichtig.
Verwenden von Unterordnern für Unterkomponenten
Einer der Nachteile des obigen Ansatzes besteht darin, dass seine Verwendung dazu führen kann, dass Ordner mit „grundlegenden“ Komponenten angezeigt werden, die viele Dateien enthalten. Betrachten Sie beispielsweise die Komponente
<Product> . CSS-Dateien werden daran angehängt (wir werden später darauf eingehen), Testdateien, viele Unterkomponenten und möglicherweise andere Ressourcen - wie Bilder und SVG-Symbole. Diese Liste der "Ergänzungen" ist nicht beschränkt. All dies wird in den gleichen Ordner wie die "Basis" -Komponente fallen.
Das interessiert mich wirklich nicht wirklich. Dies passt zu mir, wenn die Dateien gut durchdachte Namen haben und leicht zu finden sind (mithilfe der Dateisuchwerkzeuge im Editor). Wenn dies der Fall ist, tritt die Ordnerstruktur in den Hintergrund.
Hier ist ein Tweet zu diesem Thema.
Wenn Sie jedoch eine umfangreichere Struktur Ihres Projekts bevorzugen, ist es nicht schwierig, Unterkomponenten in ihre eigenen Ordner zu verschieben:
- src/ - components/ - product/ - product.jsx - ... - product-price/ - product-price.jsx
Testdateien befinden sich an derselben Stelle wie die Dateien der zu testenden Komponenten.
Wir beginnen diesen Abschnitt mit einer einfachen Empfehlung: Die Testdateien sollten an derselben Stelle abgelegt werden wie die Dateien mit dem Code, den sie mit ihrer Hilfe überprüfen. Ich werde auch darüber sprechen, wie ich die Komponenten lieber strukturiere, um sicherzustellen, dass sie nahe beieinander liegen. Aber jetzt kann ich sagen, dass ich es bequem finde, die Testdateien in denselben Ordnern wie die Komponentendateien abzulegen. In diesem Fall sind die Namen der Dateien mit den Tests identisch mit den Namen der Dateien mit dem Code. Zu den
.test vor der Dateinamenerweiterung nur das Suffix
.test hinzugefügt:
- Name der Komponentendatei:
auth.js - Name der
auth.test.js : auth.test.js
Dieser Ansatz hat mehrere Stärken:
- Es macht es einfach, Testdateien zu finden. Auf einen Blick können Sie verstehen, ob es einen Test für die Komponente gibt, mit der ich arbeite.
- Alle notwendigen Importbefehle sind sehr einfach. Um den getesteten Code zu importieren, müssen Sie im Test keine Strukturen erstellen, die beispielsweise den Ausstieg aus dem Ordner
__tests__ . Solche Teams sehen extrem einfach aus. Beispiel: import Auth from './auth' .
Wenn während des Tests einige Daten verwendet werden, z. B. API-Anforderungs-Mocks, legen wir sie in demselben Ordner ab, in dem sich die Komponente und ihr Test bereits befinden. Wenn alles, was benötigt wird, in einem Ordner liegt, trägt dies zur Steigerung der Produktivität bei. Wenn Sie beispielsweise eine verzweigte Ordnerstruktur verwenden und der Programmierer sicher ist, dass eine bestimmte Datei vorhanden ist, sich aber nicht an ihren Namen erinnern kann, muss der Programmierer in vielen Unterverzeichnissen nach dieser Datei suchen. Schauen Sie sich bei dem vorgeschlagenen Ansatz nur den Inhalt eines Ordners an, und alles wird klar.
CSS-Module
Ich bin ein großer Fan von
CSS-Modulen . Wir haben festgestellt, dass sie sich hervorragend zum Erstellen modularer CSS-Regeln für Komponenten eignen.
Außerdem mag ich die
Styled-Components- Technologie sehr. Bei der Arbeit an Projekten, an denen viele Entwickler beteiligt waren, stellte sich jedoch heraus, dass das Vorhandensein realer CSS-Dateien im Projekt die Benutzerfreundlichkeit erhöht.
Wie Sie wahrscheinlich bereits vermutet haben, befinden sich unsere CSS-Dateien wie andere Dateien neben den Komponentendateien in denselben Ordnern. Dies vereinfacht das Verschieben zwischen Dateien erheblich, wenn Sie die Bedeutung einer Klasse schnell verstehen müssen.
Eine allgemeinere Empfehlung, deren Kern das gesamte Material durchdringt, lautet, dass der gesamte Code für eine bestimmte Komponente in demselben Ordner aufbewahrt werden sollte, in dem sich diese Komponente befindet. Vorbei sind die Zeiten, in denen separate Ordner zum Speichern von CSS- und JS-Code, Testcode und anderen Ressourcen verwendet wurden. Die Verwendung komplexer Ordnerstrukturen erschwert das Verschieben zwischen Dateien und hat keinen offensichtlichen Vorteil, außer dass es hilft, "den Code zu organisieren". Bewahren Sie miteinander verbundene Dateien im selben Ordner auf. Dies bedeutet, dass Sie während der Arbeit weniger Zeit zwischen Ordnern wechseln müssen.
Wir haben sogar einen Webpack-Loader für CSS erstellt, dessen Funktionen den Funktionen unserer Arbeit entsprechen. Es überprüft die deklarierten Klassennamen und gibt einen Fehler in der Konsole aus, wenn auf eine Klasse verwiesen wird, die nicht vorhanden ist.
Fast immer wird nur ein Komponentencode in einer Datei abgelegt
Meine Erfahrung zeigt, dass Programmierer normalerweise zu streng an der Regel festhalten, dass der Code für eine und nur eine React-Komponente in einer Datei enthalten sein sollte. Gleichzeitig unterstütze ich voll und ganz die Idee, dass es sich nicht lohnt, zu viele Komponenten in einer Datei zu platzieren (stellen Sie sich nur die Schwierigkeiten vor, solche Dateien zu benennen!). Ich glaube jedoch, dass es nichts Falsches ist, den Code einer bestimmten „großen“ Komponente und den Code der damit verbundenen „kleinen“ Komponente in derselben Datei zu platzieren. Wenn ein solcher Schritt dazu beiträgt, die Reinheit des Codes zu erhalten, wenn die "kleine" Komponente nicht zu groß ist, um sie in einer separaten Datei abzulegen, schadet dies niemandem.
Wenn ich beispielsweise eine
<Product> -Komponente erstelle und einen kleinen Code zur Anzeige des Preises benötige, kann ich Folgendes tun:
const Price = ({ price, currency }) => ( <span> {currency} {formatPrice(price)} </span> ) const Product = props => {
Das Gute an diesem Ansatz ist, dass ich keine separate Datei für die
<Price> -Komponente erstellen musste und dass diese Komponente ausschließlich für die
<Product> -Komponente verfügbar ist. Wir exportieren diese Komponente nicht, daher kann sie nicht an anderer Stelle in der Anwendung importiert werden. Dies bedeutet, dass Sie auf die Frage, ob
<Price> in eine separate Datei eingefügt werden soll, eine klare, positive Antwort geben können, wenn Sie sie an einen anderen Ort importieren müssen. Andernfalls können Sie auf den Code
<Price> , der in einer separaten Datei gespeichert wird.
Separate Ordner für universelle Komponenten
Wir haben kürzlich universelle Komponenten verwendet. Sie bilden zwar unser Designsystem (das wir eines Tages veröffentlichen wollen), aber bisher haben wir klein angefangen - mit Komponenten wie
<Button> und
<Logo> . Eine Komponente wird als „universell“ betrachtet, wenn sie nicht an einen bestimmten Teil der Site gebunden ist, sondern einer der Bausteine der Benutzeroberfläche ist.
Ähnliche Komponenten befinden sich in Ihrem eigenen Ordner (
src/components/generic ). Dies vereinfacht die Arbeit mit allen universellen Komponenten erheblich. Sie sind an einem Ort - es ist sehr praktisch. Mit dem Wachstum des Projekts planen wir im Laufe der Zeit die Entwicklung eines
Styleguides (wir sind große Fans von
React-Styleguidist ), um die Arbeit mit universellen Komponenten weiter zu vereinfachen.
Verwenden von Aliasen zum Importieren von Entitäten
Die relativ flache Ordnerstruktur in unseren Projekten stellt sicher, dass die Importbefehle keine zu langen Strukturen wie
../../ . Aber es ist schwer, ohne sie auszukommen. Daher haben wir
babel-plugin-module-resolver verwendet , um Aliase zu konfigurieren, die Importbefehle vereinfachen.
Sie können dasselbe mit Webpack tun, aber dank des Babel-Plugins können dieselben Importbefehle in Tests verwendet werden.
Wir haben dies mit zwei Aliasen konfiguriert:
{ components: './src/components', '^generic/([\\w_]+)': './src/components/generic/\\1/\\1', }
Der erste ist sehr einfach. Sie können jede Komponente importieren und den Befehl mit den Wortkomponenten starten. Im normalen Ansatz sehen Importbefehle ungefähr so aus:
import Product from '../../components/product/product'
Stattdessen können wir sie so schreiben:
import Product from 'components/product/product'
Beide Befehle importieren dieselbe Datei. Dies ist sehr praktisch, da Sie nicht an die Ordnerstruktur denken müssen.
Der zweite Alias ist etwas komplizierter:
'^generic/([\\w_]+)': './src/components/generic/\\1/\\1',
Wir verwenden hier Regex. Es werden Importbefehle gefunden, die mit
generic beginnen (mit dem Zeichen
^ am Anfang des Ausdrucks können Sie nur die Befehle auswählen, die mit
generic beginnen), und es wird erfasst, was nach
generic/ in der Gruppe steht. Danach verwenden wir das erfasste Fragment (
\\1 ) im Konstrukt
./src/components/generic/\\1/\\1 .
Daher können wir die Importbefehle für universelle Komponenten dieser Art verwenden:
import Button from 'generic/button'
Sie werden in die folgenden Befehle konvertiert:
import Button from 'src/components/generic/button/button'
Dieser Befehl dient beispielsweise zum Importieren einer JSX-Datei, die eine universelle Schaltfläche beschreibt. Wir haben dies alles getan, weil dieser Ansatz den Import universeller Komponenten erheblich vereinfacht. Darüber hinaus wird es uns gute Dienste leisten, wenn wir uns entscheiden, die Struktur der Projektdateien zu ändern (dies ist durchaus möglich, da unser Designsystem wächst).
An dieser Stelle möchte ich darauf hinweisen, dass Sie beim Arbeiten mit Pseudonymen vorsichtig sein sollten. Wenn Sie nur wenige davon haben und diese zur Lösung von Standardimportproblemen entwickelt wurden, ist alles in Ordnung. Aber wenn Sie viele von ihnen haben, können sie mehr Verwirrung als Nutzen bringen.
Universeller lib-Ordner für Dienstprogramme
Ich möchte die Zeit, die ich damit verbracht habe, den perfekten Ort für Code zu finden, der kein Komponentencode ist, wiedererlangen. Ich teilte dies alles nach verschiedenen Prinzipien und hob den Code der Dienstprogramme, Dienste und Hilfsfunktionen hervor. All dies hat so viele Namen, dass ich nicht alle erwähnen werde. Jetzt versuche ich nicht, den Unterschied zwischen dem "Dienstprogramm" und der "Hilfsfunktion" herauszufinden, um den richtigen Ort für eine bestimmte Datei zu finden. Jetzt benutze ich einen viel einfacheren und verständlicheren Ansatz: All dies fällt in einen einzigen
lib Ordner.
Auf lange Sicht kann sich herausstellen, dass der Ordner so groß ist, dass Sie ihn irgendwie strukturieren müssen, aber das ist völlig normal. Es ist immer einfacher, etwas mit einer bestimmten Struktur auszustatten, als Fehler übermäßiger Strukturierung zu beseitigen.
In unserem Thread-Projekt enthält der
lib Ordner ungefähr 100 Dateien. Sie sind ungefähr zu gleichen Teilen in Dateien mit der Implementierung bestimmter Funktionen und in Testdateien unterteilt. Es gab keine Schwierigkeiten, die erforderlichen Dateien zu finden. Dank der intelligenten Suchmaschinen
lib/name_of_thing die in den meisten Editoren integriert sind, muss ich fast immer so etwas wie
lib/name_of_thing , und was ich brauche, wird gefunden.
Darüber hinaus verfügen wir über einen Alias, der den Import aus dem
lib Ordner vereinfacht und es Ihnen ermöglicht, Befehle dieser Art zu verwenden:
import formatPrice from 'lib/format_price'
Lassen Sie sich nicht von den flachen Ordnerstrukturen beunruhigen, die dazu führen können, dass mehrere Dateien in einem Ordner gespeichert werden. Normalerweise reicht eine solche Struktur für ein bestimmtes Projekt aus.
Ausblenden von Bibliotheken von Drittanbietern hinter nativen APIs
Ich mag das
Sentry Bug Monitoring System sehr. Ich habe es oft verwendet, wenn ich Server- und Client-Teile von Anwendungen entwickelt habe. Mit seiner Hilfe können Sie Ausnahmen abfangen und Benachrichtigungen über deren Auftreten erhalten. Dies ist ein großartiges Tool, mit dem wir uns über die auf der Website aufgetretenen Probleme auf dem Laufenden halten können.
Wenn ich in meinem Projekt eine Bibliothek eines Drittanbieters verwende, denke ich darüber nach, wie ich sie so gestalten kann, dass sie bei Bedarf so einfach wie möglich durch etwas anderes ersetzt werden kann. Wie bei demselben Sentry-System, das wir wirklich mögen, ist dies oft nicht erforderlich. Aber nur für den Fall, es tut nie weh, einen Weg zu finden, um die Verwendung eines bestimmten Dienstes zu vermeiden oder ihn in etwas anderes zu ändern.
Die beste Lösung für dieses Problem besteht darin, eine eigene API zu entwickeln, die die Tools anderer Personen verbirgt. Dies ist so etwas wie das Erstellen eines
lib/error-reporting.js reportError() lib/error-reporting.js Moduls, das die Funktion
reportError() exportiert. Der Kern dieses Moduls verwendet Sentry. Sentry wird jedoch nur in diesem Modul und nirgendwo anders direkt importiert. Dies bedeutet, dass das Ersetzen von Sentry durch ein anderes Tool sehr einfach aussieht. Dazu reicht es aus, eine Datei an einem Ort zu ändern. Solange die öffentliche API dieser Datei unverändert bleibt, weiß der Rest des Projekts nicht einmal, dass beim Aufrufen von
reportError() nicht Sentry verwendet wird, sondern etwas anderes.
Bitte beachten Sie, dass die öffentliche API des Moduls als die exportierten Funktionen und deren Argumente bezeichnet wird. Sie werden auch als öffentliche Schnittstelle des Moduls bezeichnet.
Verwenden von PropTypes (oder Tools wie TypeScript oder Flow)
Wenn ich programmiere, denke ich an drei Versionen von mir:
- Jack aus der Vergangenheit und der Code, den er geschrieben hat (manchmal zweifelhafter Code).
- Der heutige Jack und der Code, den er jetzt schreibt.
- Jack aus der Zukunft. Wenn ich selbst über diese Zukunft nachdenke, frage ich mich in der Gegenwart, wie ich Code schreiben kann, der mir in Zukunft das Leben leichter macht.
Es mag seltsam klingen, aber ich fand es nützlich, über das Schreiben von Code nachzudenken und die folgende Frage zu stellen: "Wie wird es in sechs Monaten wahrgenommen?".
Eine einfache Möglichkeit, sich präsent und produktiver zu machen, besteht darin, die von den Komponenten verwendeten Eigenschaftstypen (
PropTypes ) anzugeben. Dies spart Zeit bei der Suche nach möglichen Tippfehlern. Dies schützt Sie vor Situationen, in denen bei Verwendung der Komponente Eigenschaften der falschen Typen angewendet werden oder die Übertragung von Eigenschaften vollständig vergessen wird. In unserem Fall ist die
Regel eslint-react / prop-types eine gute Erinnerung an die Notwendigkeit,
PropTypes zu verwenden.
Wenn Sie noch weiter gehen, wird empfohlen, die Eigenschaften so genau wie möglich zu beschreiben. Zum Beispiel können Sie dies tun:
blogPost: PropTypes.object.isRequired
Aber es wäre viel besser, dies zu tun:
blogPost: PropTypes.shape({ id: PropTypes.number.isRequired, title: PropTypes.string.isRequired,
Im ersten Beispiel wird die minimal erforderliche Prüfung durchgeführt. Im zweiten Schritt erhält der Entwickler viel nützlichere Informationen. Sie sind beispielsweise sehr nützlich, wenn jemand ein bestimmtes Feld vergisst, das im Objekt verwendet wird.
Bibliotheken von Drittanbietern werden nur verwendet, wenn sie wirklich benötigt werden.
Dieser Tipp ist mit dem Aufkommen von
React-Hooks relevanter denn je. Zum Beispiel war ich an einer großen Änderung eines Teils der Thread-Site beteiligt und habe beschlossen, der Verwendung von Bibliotheken von Drittanbietern besondere Aufmerksamkeit zu widmen. , , . ( ), .
, React-. — , , React API Context, .
, , Redux, . , ( , ). , , , .
— , , . .
, . , . , « ». , , , . . «» - , . , , .
Redux. . , . , ,
user_add_to_cart , . . , , Redux, . , Redux , .
, , , , :
- , , . .
- , , . , .
- , - , . , , .
- , . , , . , , , «» .
, , API Context
- .
, (, ,
). : , .
, , , . :
const wrapper = mount( <UserAuth.Provider value=> <ComponentUnderTest /> </UserAuth.Provider> )
:
const wrapper = mountWithAuth(ComponentUnderTest, { name: 'Jack', userId: 1, })
:
- . — , , , .
- —
mountWithAuth . , .
,
test-utils.js . , — . .
Zusammenfassung
. , , , , . , , . , : . . - , .
Liebe Leser! React-?
