Die umfassendste Möglichkeit, React-Komponenten zu erstellen-js-Tutorial-php.cn

Ich verwende React sehr gerne, weil der größte Vorteil meiner Meinung nach darin besteht, dass es einfach genug ist. Es gibt einen Unterschied zwischen einfach und leicht, und ich meine, React ist auch einfach. Natürlich braucht es einige Zeit, um es zu verstehen. Sobald Sie den Kerninhalt beherrschen, wird sich alles andere von selbst ergeben. Die schwierigeren Teile werden weiter unten behandelt.

Kopplung und Kohäsion

Diese Indikatoren (Kopplung und Kohäsion) stellen uns mehr oder weniger vor Herausforderungen bei der Änderung unserer Programmiergewohnheiten. Sie werden häufig in der klassenbasierten objektorientierten Programmierung verwendet. Wir werden uns auch beim Schreiben von React-Komponenten auf dieselben Regeln beziehen und diese anwenden.

Kopplung bezieht sich auf die Verbindungen und Abhängigkeiten zwischen Elementen. Wenn Sie ein Element ändern und ein anderes Element synchron aktualisieren müssen, nennen wir dies enge Kopplung. Lose Kopplung bedeutet, dass beim Ändern eines Elements kein anderes Element geändert werden muss. Zeigen Sie beispielsweise die Funktion „Überweisungsbetrag“ an. Wenn der angezeigte Betrag auf Wechselkursberechnungen beruht, wird der angezeigte Code aktualisiert, wenn sich die interne Umrechnungsstruktur ändert. Wenn wir ein lose gekoppeltes System basierend auf einer Elementschnittstelle entwerfen, haben Änderungen am Element keinen Einfluss auf die Anzeige der Ansichtsebene. Offensichtlich sind lose gekoppelte Komponenten einfacher zu verwalten und zu kontrollieren.

Zusammenhalt ist, ob eine Komponente nur für eine Sache verantwortlich ist. Dieser Indikator folgt dem Single-Prinzip und dem Unix-Prinzip: Konzentrieren Sie sich auf eine Sache und machen Sie sie gut. Wenn die formatierte Anzeige von Kontoständen die Berechnung relevanter Wechselkurse und die Prüfung, ob die Berechtigung zur Einsicht in die Historie vorhanden ist, erfordert, dann beinhaltet dies viele funktionale Verantwortlichkeiten, und diese Funktionen sind nicht voneinander abhängig. Möglicherweise sollten Berechtigungsverwaltung und Wechselkurse unterschiedliche Komponenten sein. Wenn andererseits mehrere Komponenten vorhanden sind, eine für den ganzzahligen Teil, eine für den Dezimalteil und eine für die Währungsanzeige, und der Programmierer den Kontostand anzeigen möchte, muss er alle Komponenten zum Zusammenbauen finden. Die Herausforderung besteht darin, hochkohäsive Komponenten zu schaffen.

Bauteile

Es gibt viele Möglichkeiten, Bauteile zu erstellen. Wir wollen, dass Komponenten in einem angemessenen Umfang wiederverwendbar sind. Wir wollen auch kleine Komponenten bauen, die in größeren Komponenten verwendet werden können. Idealerweise möchten wir lose gekoppelte und stark aggregierte Komponenten aufbauen, damit unser System einfacher zu verwalten und zu skalieren ist. Requisiten in React-Komponenten ähneln Parametern in Funktionen und können auch als Komponenten mit zustandslosen Funktionen betrachtet werden. Wir müssen darüber nachdenken, wie Requisiten in Komponenten definiert werden und wie Komponenten wiederverwendet werden können.

Als nächstes verwenden wir das Ausgabenverwaltungssystem als Hintergrund, analysieren das detaillierte Ausgabenformat und stellen vor, wie Komponenten erstellt werden:

type Expense {
      description: string
      category: string
      amount: number
      doneAt: moment
    }

Nach dem Login kopieren

Gemäß dem Modell gibt es die folgenden Mehrere Möglichkeiten, Ausgabenformate programmgesteuert zu modellieren:

Keine Requisiten
Ein Ausgabenobjekt übergeben
Übergeben Sie die erforderlichen Attribute
Übergeben Sie eine Karte aller Attribute
Übergeben Sie ein formatiertes Unterobjekt

Die Vor- und Nachteile der Verwendung der oben genannten Übertragungsmethoden werden im Folgenden erläutert. Sie müssen jedoch immer auf die Verwendung einer der oben genannten Methoden achten, abhängig vom Nutzungsszenario und den abhängigen Systemen. Das ist es auch, was wir tun, entsprechend abstrakte Szenen zu bauen.

Keine Requisiten

Dies ist die einfachste Lösung, die oft darin besteht, eine Komponente zu erstellen, die statische Daten schreibt.

const ExpenseDetails = () => (
      <p className=&#39;expense-details&#39;>
         <p>Category: <span>Food</span></p>
         <p>Description: <span>Lunch</span></p>
         <p>Amount: <span>10.15</span></p>
         <p>Date: <span>2017-10-12</span></p>
      </p>
    )

Nach dem Login kopieren

Ohne die Weitergabe von Requisiten erhalten wir keine Flexibilität und die Komponente kann nur in einem einzigen Szenario verwendet werden. Im Kostendetailbeispiel können wir sehen, dass die Komponente zunächst einige Requisiten akzeptieren muss. In manchen Szenarien ist es jedoch auch eine gute Lösung, auf Requisiten zu verzichten. Erstens können wir einige Komponenten verwenden, deren Requisiten Inhalte enthalten, die nicht einfach geändert werden können, z. B. Marken, Logos oder Unternehmensinformationen.

const Logo = () => (
      <p className=&#39;logo&#39;>
       <img src=&#39;/logo.png&#39; alt=&#39;DayOne logo&#39;/>
      </p>
    )

Nach dem Login kopieren

Das Schreiben von Komponenten so klein wie möglich macht die Wartung des Systems einfacher. Behalten Sie Informationen an einem Ort und müssen Sie sie nur an einem Ort ändern. Schreiben Sie keinen doppelten Code an mehreren Stellen.

Ausgabenobjekt übergeben

Wenn die Ausgabendetails ermittelt sind, müssen wir Daten an die Komponente übergeben. Zuerst müssen wir ein Ausgabenobjekt übergeben.

const ExpenseDetails = ({ expense }) => (
      <p className=&#39;expense-details&#39;>
         <p>Category: <span>{expense.category}</span></p>
         <p>Description: <span>{expense.description}</span></p>
         <p>Amount: <span>{expense.amount}</span></p>
         <p>Date: <span>{expense.doneAt}</span></p>
      </p>
    )

Nach dem Login kopieren

Es ist sinnvoll, das Spesenobjekt an die Spesendetailskomponente zu übergeben. Das Format der Spesendetails ist äußerst konsistent und zeigt Spesendaten an. Wann immer Sie das Format ändern müssen, ist dies der einzige Ort, an dem Sie es ändern können. Das Ändern des Formats der Spesendetails hat keine Nebenwirkungen auf das Spesenobjekt selbst.

Diese Komponente ist eng mit dem Kostenobjekt verknüpft. Ist das eine schlechte Sache? Natürlich nicht, aber wir müssen uns darüber im Klaren sein, welche Auswirkungen dies auf unsere Systeme hat. Wenn ein Objekt als Requisiten übergeben wird, stützt sich die Spesendetailskomponente auf die interne Spesenstruktur. Wenn wir die interne Struktur der Ausgaben ändern, müssen wir auch die Komponente mit den Ausgabendetails ändern. Natürlich müssen wir es nur an einer Stelle ändern.

Wie passt sich dieses Design an zukünftige Änderungen an? Wenn wir ein Feld hinzufügen, ändern oder löschen, müssen wir nur eine Komponente ändern. Was ist, wenn wir eine weitere formatierte Kalenderanzeige hinzufügen müssen? Wir können eine neue Requisite für die Kalenderformatierung hinzufügen.

const ExpenseDetails = ({ expense, dateFormat }) => (
      <p className=&#39;expense-details&#39;>
         <p>Category: <span>{expense.category}</span></p>
         <p>Description: <span>{expense.description}</span></p>
         <p>Amount: <span>{expense.amount}</span></p>
         <p>Date: <span>{expense.doneAt.format(dateFormat)}</span></p>
      </p>
    )

Nach dem Login kopieren

我们开始增加属性来使组件更加灵活。如果只有几个选项，那么一切都是很ok的。系统业务开始扩展后问题就来了，在不同的场景下我们需要维护大量的props。

const ExpenseDetails = ({ expense, dateFormat, withCurrency, currencyFormat, isOverdue, isPaid ... })

Nach dem Login kopieren

增加props可以使得组件重用性更好，但你可能设计了多重功能职责的组件。这种规则也同样在函数写法中运用。可以用多个参数来创建一个函数，当参数的数目超过3个或者4个时候，意味着这个函数在做很多事情了，也许这时候应该将函数拆成更小的函数来的更加简单。

随着组件props的增加，我们将其拆分成定义明确的组件，比如：OverdueExpenseDetails, PaidExpenseDetails等。

只传递必要的属性

为了减少对象自身的内容，我们可以只传递必要的属性值。

const ExpenseDetails = ({ category, description, amount, date }) => (
      <p className=&#39;expense-details&#39;>
         <p>Category: <span>{category}</span></p>
         <p>Description: <span>{description}</span></p>
         <p>Amount: <span>{amount}</span></p>
         <p>Date: <span>{date}</span></p>
      </p>
    )

Nach dem Login kopieren

我们分别传递属性，这样我们将一部分工作责任转移给了组件使用者。如果费用的内部结构发生变化，他将不会影响费用明细的格式化。但可能影响每个使用组件的地方，因为我们可能需要修改props。当我们以独立的属性传递props时候，一个组件将更加抽象了。

只传递需要的字段对未来设计改动是如何影响的？增加、更新或者删除字段将不会很容易。无论何时我们要增加一个字段，我们不仅仅要改变费用细节的实现，也需要改变每个使用组件的地方。另外一个方面，支持多种日历格式化几乎是现成的，我们可以传递日历作为prop，也可以传递格式化后的日历。

<ExpenseDetails 
      category={expense.category} 
      description={expense.description}
      amount={expense.amount}
      date={expense.doneAt.format(&#39;YYYY-MM-DD&#39;)}
    />

Nach dem Login kopieren

决定如何展示特定的字段应该在掌握在具体使用组件的人手中，这将不是费用明细组件关心的内容。

传递map或者array的属性

为了达到组件抽象化，我们可以传递一个map的属性值。

const ExpenseDetails = ({ expense }) => (
      <p class=&#39;expense-details&#39;>
      {
        _.reduce(expense, (acc, value, key) => {
          acc.push(<p>{key}<span>{value}</span></p>)
        }, [])
      }
      </p>
    )

Nach dem Login kopieren

使用组件的人控制费用明细的格式化，传递给组件的对象格式则必须正确。

const expense = {
      "Category": "Food",
      "Description": "Lunch",
      "Amount": 10.15,
      "Date": 2017-10-12
    }

Nach dem Login kopieren

这个方案有很多缺陷，我们很难控制组件展示的样式，并且展示顺序也没有指定。因此，如果我们需要某种顺序的话，可以采用array代替map来解决这个问题。但是仍然还有缺陷。

传递map 和array作为props 不与费用耦合，也根本与它不一致。增加和删除新属性虽然只改变了prop，但是我们无法控制组件本身的格式。如果我们只改变类别的格式化，这不是一个可行的办法。（确切地说，总有一个办法来解决，例如，传递另外一个格式化后的props。这个解决方案似乎不再简单了。）

传递一个格式化的子对象

我们也可以只通过直接传对一个子对象，这样就能考虑更少的组件内需要如何展示。

const ExpenseDetails = ({ children }) => (
      <p class=&#39;expense-details&#39;>
        { children }
      </p>
    )

Nach dem Login kopieren

在这种情况下，费用明细只是一个提供结构和样式的容器。展示所有信息则是使用组件的人必须提供的。

<ExpenseDetails>
      <p>Category: <span>{expense.category}</span></p>
      <p>Description: <span>{expense.description}</span></p>
      <p>Amount: <span>{expense.amount}</span></p>
      <p>Date: <span>{expense.doneAt}</span></p>
    </ExpenseDetails>

Nach dem Login kopieren

在费用明细这个案例中，我们需要重复许多工作，因此这也许不是一个好的解决方案。尽管如此，灵活性则是巨大的，因为有可能有很多不同的格式化操作。增删改只需要改变使用组件时候传入的值。日期格式也是一样的，我们虽然失去了功能内聚的特点，但这也是我们不得不付出的代价。