🧔 🤖 👨‍🔬 Warum ist es ein Anti-Muster? 🆒 🚚 ⛲️

Hallo. Im September werden bei OTUS mehrere Kurse zur JS-Entwicklung gleichzeitig gestartet, nämlich: JavaScript Developer. Professioneller JavaScript-Entwickler. Basic und React.js Entwickler. Im Vorfeld des Beginns dieser Kurse haben wir eine weitere interessante Übersetzung für Sie vorbereitet und bieten außerdem an, sich für kostenlose Demo-Lektionen zu folgenden Themen anzumelden:

Fahren wir nun mit dem Artikel fort.

Als ich anfing, React zu lernen, gab es einige Dinge, die ich nicht verstand. Und ich denke, fast jeder, der mit React vertraut ist, stellt die gleichen Fragen. Ich bin mir dessen sicher, weil die Leute ganze Bibliotheken erstellen, um dringende Probleme zu lösen. Hier sind zwei Hauptfragen, die fast jeden React-Entwickler zu interessieren scheinen:

Wie greift eine Komponente auf Informationen (insbesondere eine Statusvariable) zu, die sich in einer anderen Komponente befinden? Wie ruft eine Komponente eine Funktion auf, die sich in einer anderen Komponente befindet?

JavaScript-Entwickler im Allgemeinen (und React-Entwickler im Besonderen) tendieren in letzter Zeit zunehmend dazu, sogenannte reine Funktionen zu schreiben. Funktionen, die nicht mit Statusänderungen verknüpft sind. Funktionen, die keine externen Datenbankverbindungen benötigen. Funktionen, die unabhängig davon sind, was außerhalb von ihnen geschieht.

Natürlich sind reine Funktionen ein vorrangiges Ziel. Wenn Sie jedoch eine mehr oder weniger komplexe Anwendung entwickeln, können Sie nicht jede Funktion sauber machen. Es wird sicherlich eine Zeit kommen, in der Sie mindestens einige Komponenten erstellen müssen , die in irgendeiner Weise mit anderen Komponenten zusammenhängen. Der Versuch, dies zu vermeiden, ist lächerlich. Diese Verbindungen zwischen Komponenten werden als Abhängigkeiten bezeichnet .

Im Allgemeinen sind Abhängigkeiten schlecht und werden am besten nur bei Bedarf verwendet. Wenn Ihre Anwendung jedoch gewachsen ist, hängen einige ihrer Komponenten notwendigerweise voneinander ab. Natürlich wissen die React-Entwickler dies und haben herausgefunden, wie eine Komponente wichtige Informationen oder Funktionen an ihre untergeordneten Komponenten weitergeben kann.

Standardansatz: Verwenden Sie Requisiten, um Werte zu übergeben

Jeder Statuswert kann über Requisiten an eine andere Komponente übergeben werden. Jede Funktion kann über dieselben Requisiten an untergeordnete Komponenten übergeben werden. Auf diese Weise wissen Nachkommen, welche Statuswerte im Baum gespeichert sind, und können möglicherweise Aktionen in übergeordneten Komponenten aufrufen. Das alles ist natürlich gut. Die Entwickler von React sind jedoch besorgt über ein bestimmtes Problem.

Die meisten Anwendungen sind geschichtet. In komplexen Anwendungen können Strukturen sehr tief verschachtelt sein. Die allgemeine Architektur könnte ungefähr so aussehen:

App→ bezieht sich auf → ContentArea

ContentArea→ bezieht sich auf → MainContentArea

MainContentArea→ bezieht sich auf → MyDashboard

MyDashboard→ bezieht sich auf → MyOpenTickets

MyOpenTickets→ bezieht sich auf → TicketTable

TicketTable→ bezieht sich auf eine Sequenz → TicketRow

Jeder TicketRow→ bezieht sich auf →TicketDetail

Theoretisch kann diese Girlande lange umwickelt werden. Alle Komponenten sind Teil des Ganzen. Genauer gesagt, Teil einer Hierarchie. Hier stellt sich jedoch die Frage:

Kann die Komponente TicketDetailim obigen Beispiel die darin gespeicherten Statuswerte lesen ContentArea? Oder. Kann eine Komponente TicketDetailFunktionen aufrufen, die sich in befinden ContentArea?

Die Antwort auf beide Fragen lautet ja. Theoretisch können alle Nachkommen alle Variablen kennen, die in den übergeordneten Komponenten gespeichert sind. Sie können auch Ahnenfunktionen aufrufen - allerdings mit einer großen Einschränkung. Dies ist nur möglich, wenn solche Werte (Status- oder Funktionswerte) explizit über Requisiten an Nachkommen übergeben werden. Andernfalls stehen die Status- oder Funktionswerte der Komponente der untergeordneten Komponente nicht zur Verfügung.

In kleinen Anwendungen und Dienstprogrammen spielt dies keine besondere Rolle. Wenn eine Komponente beispielsweise TicketDetailauf die darin gespeicherten Statusvariablen zugreifen muss TicketRow, reicht es aus, die Komponente TicketRow→ diese Werte TicketDetailüber eine oder mehrere Requisiten an ihren Nachkommen zu übergeben → . Das gleiche gilt, wenn eine Komponente TicketDetaileine Funktion aufrufen muss, die sich in befindet TicketRow. Komponente TicketRow→ übergibt diese Funktion TicketDetailüber Prop an ihren Nachkommen → . Die Kopfschmerzen beginnen, wenn eine Komponente weit unten im Baum auf den Status oder die Funktion der Komponente oben in der Hierarchie zugreifen muss.

Um dieses Problem in React zu lösen, werden Variablen und Funktionen traditionell auf allen Ebenen weitergegeben. Dies überfrachtet jedoch den Code, beansprucht Ressourcen und erfordert eine ernsthafte Planung. Wir müssten Werte an viele Ebenen wie diese übergeben:

ContentArea→ MainContentArea→ MyDashboard→ MyOpenTickets→ TicketTable→ TicketRow→ TicketDetail

Das heißt, um eine Zustandsvariable von ContentAreabis zu übergeben TicketDetail, müssen wir viel Arbeit leisten. Erfahrene Entwickler wissen, dass es eine hässliche lange Kette von Werten und Funktionen in Form von Requisiten durch Zwischenstufen von Komponenten gibt. Die Lösung ist so umständlich, dass ich es sogar ein paar Mal aufgegeben habe, React zu lernen.

Das Monster namens Redux

Ich bin nicht der einzige, der der Meinung ist, dass es sehr unpraktisch ist , alle Zustandswerte und alle Funktionen, die Komponenten gemeinsam haben, durch Requisiten zu übergeben . Es ist unwahrscheinlich, dass Sie eine komplexe React-Anwendung finden, die nicht über ein Statusverwaltungstool verfügt. Es gibt nicht so wenige solcher Werkzeuge. Ich persönlich liebe MobX. Leider gilt Redux als "Industriestandard".

Redux ist die Idee der Schöpfer des React-Kerns. Das heißt, sie haben zuerst eine wunderbare React-Bibliothek erstellt. Aber sie erkannten sofort, dass es fast unmöglich war, den Staat mit ihren Mitteln zu verwalten. Wenn sie keinen Weg gefunden hätten, die inhärenten Probleme dieser (ansonsten großartigen) Bibliothek zu lösen, hätten viele von uns nie von React gehört.

Also haben sie sich Redux ausgedacht.

Wenn React Mona Lisa ist, ist Redux ein Schnurrbart. Wenn Sie Redux verwenden, haben Sie eine schreiben Tonne in fast jede Projektdatei Standardcode. Fehlerbehebung und Lesen von Code werden zur Hölle. Geschäftslogik wird in den Hinterhof gebracht. Der Code enthält Verwirrung und Schwanken.

Wenn Entwickler jedoch die Wahl haben: React + Redux oder React ohne Zustandsverwaltungstools von Drittanbietern , wählen sie fast immer React + Redux. Da die Redux-Bibliothek von den React-Kernautoren entwickelt wurde, wird sie standardmäßig als genehmigte Lösung angesehen. Und die meisten Entwickler bevorzugen Lösungen, die stillschweigend so genehmigt wurden.

Natürlich wird Redux ein ganzes Netz von Abhängigkeiten erstellenin Ihrer React-Anwendung. Aber fairerweise wird jedes generische State-Management-Tool dasselbe tun. Das Statusverwaltungstool ist ein gemeinsames Repository von Variablen und Funktionen. Solche Funktionen und Variablen können von jeder Komponente verwendet werden, die Zugriff auf den gemeinsam genutzten Speicher hat. Dies hat einen offensichtlichen Nachteil: Alle Komponenten werden von gemeinsam genutztem Speicher abhängig .

Die meisten der mir bekannten React-Entwickler, die versucht haben, sich der Verwendung von Redux zu widersetzen, gaben schließlich auf. (Weil ... Widerstand nutzlos ist.) Ich kenne viele Leute, die Redux sofort hassen. Aber als sie vor der Wahl standen - Redux oder "Wir werden einen anderen React-Entwickler finden" - warfen sie sichhaben zugestimmt, Redux als integralen Bestandteil ihres Lebens zu betrachten. Es ist wie Steuern. Wie eine rektale Untersuchung. Als würde ich zum Zahnarzt gehen.

Gemeinsame Werte in Reaktion reagieren

Ich bin zu stur, um so leicht aufzugeben. Nachdem ich mir Redux angesehen hatte, wurde mir klar, dass ich nach anderen Lösungen suchen musste. Ich kann Redux verwenden. Und ich habe in Teams gearbeitet, die diese Bibliothek genutzt haben. Im Allgemeinen verstehe ich, was sie tut. Das heißt aber nicht, dass ich Redux mag.

Wie ich bereits sagte, wenn Sie nicht auf ein separates Statusverwaltungstool verzichten können, ist MobX ungefähr ... eine Million Mal besser als Redux! Aber ich werde von einer ernsteren Frage gequält . Es berührt den kollektiven Verstand der React-Entwickler:

Warum greifen wir immer zuerst zu einem State-Management-Tool?

Als ich anfing, mit React zu entwickeln, suchte ich viele Nächte nach alternativen Lösungen. Und ich habe einen Weg gefunden, den viele React-Entwickler vernachlässigen, aber keiner von ihnen kann sagen, warum . Erklären wollen.

Stellen Sie sich vor, wir erstellen in der hypothetischen Anwendung, über die ich oben geschrieben habe, eine Datei wie die folgende:

// components.js
let components = {};
export default components;

Und alle. Nur zwei kurze Codezeilen. Wir erstellen ein leeres Objekt - ein gutes altes JS-Objekt . Wir exportieren es standardmäßig mit export default.

Nun wollen wir sehen, wie der Code in der Komponente aussehen könnte <ContentArea>:

// content.area.js
import components from './components';
import MainContentArea from './main.content.area';
import React from 'react';

export default class ContentArea extends React.Component {
   constructor(props) {
      super(props);
      components.ContentArea = this;
   }

   consoleLog(value) {
      console.log(value);
   }

   render() {
      return <MainContentArea/>;
   }
}

Zum größten Teil sieht es aus wie eine ganz normale klassenbasierte React-Komponente. Wir haben eine einfache Funktion render(), die auf die nächste Komponente im Baum zugreift. Wir haben eine kleine Funktion console.log(), die das Ergebnis der Codeausführung an die Konsole druckt, und einen Konstruktor. Aber ... es gibt einige Nuancen im Konstruktor .

Zu Beginn haben wir ein einfaches Objekt importiert components. Anschließend haben wir im Konstruktor dem Objekt eine neue Eigenschaft componentsmit dem Namen der aktuellen React-Komponente ( this) hinzugefügt . In dieser Eigenschaft verweisen wir auf die Komponente this. Jedes Mal, wenn wir auf das Komponentenobjekt zugreifen, haben wir direkten Zugriff auf die Komponente <ContentArea>.

Mal sehen, was am Ende der Hierarchie passiert. Die Komponente <TicketDetail>kann folgendermaßen aussehen:

// ticket.detail.js
import components from './components';
import React from 'react';

export default class TicketDetail extends React.Component {
   render() {
      components.ContentArea.consoleLog('it works');
      return <div>Here are the ticket details.</div>;
   }
}

Folgendes passiert: Jedes Mal, wenn die Komponente gerendert wird, wird die in der Komponente gespeicherte TicketDetailFunktion aufgerufen . Beachten Sie, dass die Funktion nicht über Requisiten durch die gesamte Hierarchie geleitet wird. Tatsächlich wird die Funktion nirgendwo - nirgendwo - an eine Komponente übergeben. Und doch kann es die Funktion aufrufen , die in gespeichert ist , weil wir zwei Dinge getan haben:consoleLog()ContentArea

consoleLog()consoleLog()

TicketDetailconsoleLog()ContentArea

ContentAreaBeim Laden fügte die Komponente einen Link zu dem gemeinsam genutzten Objekt der Komponente hinzu.
TicketDetailBeim Laden importierte die Komponente ein freigegebenes Objekt components, dh sie hatte direkten Zugriff auf die Komponente ContentArea, obwohl die Eigenschaften ContentAreanicht TicketDetailüber Requisiten an die Komponente übergeben wurden .

Dieser Ansatz funktioniert nicht nur mit Funktionen / Rückrufen. Es kann verwendet werden, um die Werte von Zustandsvariablen direkt abzufragen. Stellen wir uns vor, wie das <ContentArea>aussieht:

// content.area.js
import components from './components';
import MainContentArea from './main.content.area';
import React from 'react';

export default class ContentArea extends React.Component {
   constructor(props) {
      super(props);
      this.state = { reduxSucks:true };
      components.ContentArea = this;
   }

   render() {
      return <MainContentArea/>;
   }
}

Dann können wir so schreiben <TicketDetail>:

// ticket.detail.js
import components from './components';
import React from 'react';

export default class TicketDetail extends React.Component {
   render() {
      if (components.ContentArea.state.reduxSucks === true) {
         console.log('Yep, Redux is da sux');
      }
      return <div>Here are the ticket details.</div>;
   }
}

Jedes Mal, wenn die Komponente gerendert <TicketDetailwird, sucht sie nach dem Wert der Variablen state.reduxSucksin <ContentArea>. Wenn die Variable einen Wert zurückgibt true, console.log()druckt die Funktion eine Nachricht an die Konsole. Dies ist auch dann der Fall, wenn der Wert der Variablen ContentArea.state.reduxSucksnoch nie über Requisiten an den Baum - an eine der Komponenten - weitergegeben wurde. Mit einem einfachen zugrunde liegenden JS-Objekt, das außerhalb des Standard-React-Lebenszyklus liegt, können wir es so gestalten, dass jeder Nachkomme Statusvariablen direkt von jedem übergeordneten Element lesen kann, das in das Komponentenobjekt geladen wird. Wir können sogar Funktionen der übergeordneten Komponente in ihrem Nachkommen aufrufen.

Die Möglichkeit, eine Funktion direkt in untergeordneten Komponenten aufzurufen, bedeutet, dass wir den Status übergeordneter Komponenten direkt von ihren untergeordneten Komponenten aus ändern können. Zum Beispiel so.

Zunächst <ContentArea>erstellen wir in der Komponente eine einfache Funktion, die den Wert einer Variablen ändert reduxSucks.

// content.area.js
import components from './components';
import MainContentArea from './main.content.area';
import React from 'react';

export default class ContentArea extends React.Component {
   constructor(props) {
      super(props);
      this.state = { reduxSucks:true };
      components.ContentArea = this;
   }

   toggleReduxSucks() {
      this.setState((previousState, props) => {
         return { reduxSucks: !previousState.reduxSucks };
      });
   }

   render() {
      return <MainContentArea/>;
   }
}

Dann <TicketDetail>rufen wir in der Komponente diese Methode über das Objekt auf components:

// ticket.detail.js
import components from './components';
import React from 'react';

export default class TicketDetail extends React.Component {
   render() {
      if (components.ContentArea.state.reduxSucks === true) {
         console.log('Yep, Redux is da sux');
      }
      return (
         <>
            <div>Here are the ticket details.</div>
            <button onClick={() => components.ContentArea.toggleReduxSucks()}>Toggle reduxSucks</button>
         </>
      );
   }
}

Jetzt kann der <TicketDetail>Benutzer nach jedem Rendern einer Komponente eine Taste drücken, die den Wert der Variablen ContentArea.state.reduxSucksin Echtzeit ändert (umschaltet) , selbst wenn die Funktion ContentArea.toggleReduxSucks()noch nie über Requisiten an den Baum weitergegeben wurde.

Bei diesem Ansatz kann die übergeordnete Komponente die Funktion direkt von ihrem untergeordneten Element aus aufrufen. Hier erfahren Sie, wie es geht. Die aktualisierte Komponente <ContentArea>sieht folgendermaßen aus:

// content.area.js
import components from './components';
import MainContentArea from './main.content.area';
import React from 'react';

export default class ContentArea extends React.Component {
   constructor(props) {
      super(props);
      this.state = { reduxSucks:true };
      components.ContentArea = this;
   }

   toggleReduxSucks() {
      this.setState((previousState, props) => {
         return { reduxSucks: !previousState.reduxSucks };
      });
      components.TicketTable.incrementReduxSucksHasBeenToggledXTimes();
   }

   render() {
      return <MainContentArea/>;
   }
}

Fügen wir nun der Komponente Logik hinzu <TicketTable>. So:

// ticket.table.js
import components from './components';
import React from 'react';
import TicketRow from './ticket.row';

export default class TicketTable extends React.Component {
   constructor(props) {
      super(props);
      this.state = { reduxSucksHasBeenToggledXTimes: 0 };
      components.TicketTable = this;
   }

   incrementReduxSucksHasBeenToggledXTimes() {
      this.setState((previousState, props) => {
         return { reduxSucksHasBeenToggledXTimes: previousState.reduxSucksHasBeenToggledXTimes + 1};
      });      
   }

   render() {
      const {reduxSucksHasBeenToggledXTimes} = this.state;
      return (
         <>
            <div>The `reduxSucks` value has been toggled {reduxSucksHasBeenToggledXTimes} times</div>
            <TicketRow data={dataForTicket1}/>
            <TicketRow data={dataForTicket2}/>
            <TicketRow data={dataForTicket3}/>
         </>
      );
   }
}

Infolgedessen hat sich die Komponente <TicketDetail>nicht geändert. Es sieht immer noch so aus:

// ticket.detail.js
import components from './components';
import React from 'react';

export default class TicketDetail extends React.Component {
   render() {
      if (components.ContentArea.state.reduxSucks === true) {
         console.log('Yep, Redux is da sux');
      }
      return (
         <>
            <div>Here are the ticket details.</div>
            <button onClick={() => components.ContentArea.toggleReduxSucks()}>Toggle reduxSucks</button>
         </>
      );
   }
}

Haben Sie die Seltsamkeit bemerkt, die mit diesen drei Klassen verbunden ist? In der Hierarchie unserer Anwendung ContentAreaist dies die übergeordnete Komponente für TicketTable, die die übergeordnete Komponente für ist TicketDetail. Dies bedeutet , dass , wenn wir eine Komponente montieren ContentArea, ist es noch nicht „wissen“ , um seine Existenz TicketTable. Und die Funktion toggleReduxSucks()geschrieben in ContentAreaimplizit ruft das Kind Funktion :. Es

incrementReduxSucksHasBeenToggledXTimes()stellt sich heraus , dass der Code wird nicht funktionieren , nicht wahr?

Aber nein.

Aussehen. Wir haben mehrere Ebenen in der Anwendung erstellt, und es gibt nur eine Möglichkeit, die Funktion aufzurufen toggleReduxSucks(). So.

Wir montieren und rendern ContentArea.
Während dieses Vorgangs wird ein Verweis auf die Komponenten in das Komponentenobjekt geladen ContentArea.
Das Ergebnis wird gemountet und gerendert TicketTable.
Während dieses Vorgangs wird ein Verweis auf die Komponenten in das Komponentenobjekt geladen TicketTable.
Das Ergebnis wird gemountet und gerendert TicketDetail.
« reduxSucks» (Toggle reduxSucks).
« reduxSucks».
toggleReduxSucks(), ContentArea.
incrementReduxSucksHasBeenToggledXTimes() TicketTable .
, , « reduxSucks», TicketTable components. toggleReduxSucks() ContentArea incrementReduxSucksHasBeenToggledXTimes(), TicketTable, components.

Es stellt sich heraus, dass die Hierarchie unserer Anwendung es uns ermöglicht, der Komponente einen ContentAreaAlgorithmus hinzuzufügen, der eine Funktion von der untergeordneten Komponente aufruft, obwohl die Komponente beim ContentAreaMounten nichts über die Existenz der Komponente wussteTicketTable .

Wealth Management Tools - Dump

Wie ich bereits erklärt habe, bin ich zutiefst davon überzeugt, dass Redux MobX nicht gewachsen ist. Und wenn ich das Privileg habe, von Grund auf an einem Projekt zu arbeiten (leider nicht oft), mache ich immer Kampagnen für MobX. Nicht für Redux. Wenn ich jedoch meine eigenen Anwendungen entwickle , verwende ich selten Zustandsverwaltungstools von Drittanbietern - fast nie . Stattdessen speichere ich Objekte / Komponenten, wann immer dies möglich ist. Und wenn dieser Ansatz nicht funktioniert, greife ich häufig auf die Standardlösung in React zurück, dh ich übergebe nur Funktionen / Statusvariablen über Requisiten.

Bekannte "Probleme" mit diesem Ansatz

Mir ist klar, dass meine Idee, das zugrunde liegende Objekt zwischenzuspeichern, componentsnicht immer zur Lösung gemeinsamer Status- / Funktionsprobleme geeignet ist. Manchmal kann dieser Ansatz ... einen grausamen Witz spielen . Oder es könnte überhaupt nicht funktionieren . Hier ist etwas zu beachten.

Es funktioniert am besten mit Singles .

In unserer Hierarchie enthält die <TicketTable> -Komponente beispielsweise <TicketRow> -Komponenten mit einer Null-zu-Viele-Beziehung. Wenn Sie den Verweis auf jede potenzielle Komponente in den <TicketRow> -Komponenten (und deren untergeordneten <TicketDetail> -Komponenten) im Komponentencache zwischenspeichern möchten, müssen Sie sie in einem Array speichern. Dies kann schwierig werden. Ich habe das immer vermieden.
components , / , components. .

, . , , . / , , components.
, components, ( setState()), setState(), .

Nachdem ich meinen Ansatz und einige seiner Einschränkungen erläutert habe, muss ich Sie warnen. Seit ich diesen Ansatz entdeckt habe, teile ich ihn mit Leuten, die sich als professionelle React-Entwickler betrachten. Jedes Mal antworten sie dasselbe:

Hmm ... Tu das nicht. Sie runzeln die Stirn und tun so, als hätte ich nur die Luft durcheinander gebracht. Etwas in meiner Herangehensweise scheint ihnen ... falsch . Gleichzeitig hat mir noch niemand aufgrund seiner reichen praktischen Erfahrung erklärt, was genau falsch ist. Es ist nur so, dass jeder über meinen Ansatz nachdenkt ... Blasphemie .

Selbst wenn Ihnen dieser Ansatz gefällt oder wenn er Ihnen in bestimmten Situationen bequem erscheint, empfehle ich ihn daher nichtSprechen Sie in einem Interview darüber, wenn Sie einen Job als React-Entwickler bekommen möchten. Ich denke, selbst wenn Sie nur mit anderen React-Entwicklern sprechen , müssen Sie eine Million Mal nachdenken, bevor Sie über diese Methode sprechen , oder vielleicht ist es besser, überhaupt nichts zu sagen.

Ich habe festgestellt, dass JS-Entwickler - und insbesondere React-Entwickler - übermäßig kategorisch sein können . Manchmal erklären sie , warum Ansatz A „falsch“ und Ansatz B „richtig“ ist. In den meisten Fällen sehen sie sich jedoch nur einen Code an und erklären ihn für „schlecht“, auch wenn sie selbst nicht erklären können, warum.

Warum ist dieser Ansatz für React-Entwickler so ärgerlich?

Wie gesagt, keiner meiner Kollegen konnte vernünftigerweise antworten, warum meine Methode schlecht ist. Und wenn jemand bereit ist, mich mit einer Antwort zu ehren , ist dies normalerweise eine der folgenden Ausreden (es gibt nur wenige davon).

, .

.... , , Redux ( MobX, ) / React-. , . — . , /, . : , components. , / components, / , components. /, components , components . , , . , , Redux, MobX, - .
React « ». … .

… . ? , . — - « » « », , , . React, . , . . « », . , React 100 %, ( ) , .

, ?

Ich habe diesen Beitrag geschrieben, weil ich diesen Ansatz seit Jahren verwende (in persönlichen Projekten). Und es funktioniert großartig . Aber jedes Mal, wenn ich aus meiner persönlichen Blase herauskrieche und versuche, mit anderen React-Entwicklern von Drittanbietern ein intelligentes Gespräch über diesen Ansatz zu führen, stoße ich nur auf kategorische Aussagen und dumme Urteile über "Industriestandards". Ist

dieser Ansatz wirklich schlecht ? Nun, wirklich. Ich möchte wissen. Wenn dies wirklich ein "Anti-Muster" ist, werde ich denen sehr dankbar sein, die seine Unrichtigkeit rechtfertigen. Die Antwort "Ich bin daran nicht gewöhnt" passt nicht zu mir. Nein, ich bin nicht mit dieser Methode fest. Ich behaupte nicht, dass dies ein Allheilmittel für React-Entwickler ist. Und ich gebe zu, dass es nicht in allen Situationen funktioniert. Aber vielleichtKann mir jemand erklären, was daran falsch ist?

Ich möchte wirklich Ihre Meinung zu diesem Thema wissen - auch wenn Sie mich in Stücke reißen.

Warum ist es ein Anti-Muster?