Ich liebe es. Die Reduzierung der Bündelgröße und der „Klassen“-Requisite sind Änderungen, die sehr willkommen sein werden.

Gute Arbeit!

🙂

Bibliotheksautoren aufgepasst! 🤣

Toll!

className → Klasse ist fantastisch

Was ist mit all den anderen? Scheint seltsam, immer noch clipPath , htmlFor , tabIndex usw. zu machen.

Die Einführung class ist ein großer Durchbruch, um die Bibliothek für Anfänger benutzerfreundlicher zu machen. Glückwünsche.

Das ist fantastisch. Ich bin so gespannt, wie der Wechsel zu class tatsächlich mit Requisiten funktioniert.

Anscheinend würde ({ class }) => <div class={class} /> anfänglich ein Problem mit reservierten Keywords darstellen?

Das sind fantastische Neuigkeiten, danke @gaearon!

Ich liebe jeden dieser Punkte, außer der Änderung className . Es scheint geradezu widersprüchlich zu dem Ziel zu sein, das die anderen Punkte verfolgen (Ausrichtung auf die DOM-API). React bindet an DOM-Eigenschaften, nicht an HTML-Attribute (dies wurde sogar im ersten Punkt artikuliert). Die Eigenschaft des DOM-Elements heißt className , nicht class . Warum also sollte es in React class heißen?

Fantastisch! Haben Sie ein Ziel für die Reduzierung der Bündelgröße?

👏

Was ist mit all den anderen? Scheint seltsam, immer noch clipPath, htmlFor, tabIndex usw. zu machen.

Ich bin offen für Diskussionen, aber ich würde argumentieren, dass diese Änderungen es nicht wert sind (außer vielleicht for ).

Ich denke, eine Neufassung des Ereignissystems ist der interessanteste Aspekt davon. Es gibt erhebliche Möglichkeiten, die Paketgröße zu reduzieren und Community-Beiträge zu erleichtern.

Machen wir das!

Ich frage mich, ob es sich lohnen würde, gleichzeitig auch an der Veröffentlichung von JSX 2.0 zu arbeiten? Die Leute werden sowieso eine Handvoll Dinge neu lernen müssen. Vielleicht ist es besser, ein paar Dinge auf einmal neu zu lernen, als ein paar Dinge zweimal über einen bestimmten Zeitraum? Nur ein Gedanke, der mir beim Lesen kam.

Ich liebe jeden dieser Punkte, außer der Änderung des Klassennamens. Es scheint geradezu widersprüchlich zu dem Ziel zu sein, das die anderen Punkte verfolgen (Ausrichtung auf die DOM-API). React bindet an DOM-Eigenschaften, nicht an HTML-Attribute (dies wurde sogar im ersten Punkt artikuliert).

Und doch, wenn wir ein unbekanntes Schlüssel/Wert-Paar übergeben, wird es seit React 16 als Attribut behandelt. Wir sind also bereits inkonsistent. Außerdem ging es in meinem Kommentar darum, dass Benutzer falsch erwartet haben, dass React das Attribut value setzt. Ob die React-API den Attributnamen oder den Eigenschaftsnamen in ihrer API verwendet, ist völlig orthogonal.

Ich habe Ihre Seite dieses Arguments jahrelang verteidigt, aber ich denke jetzt, dass dies eine Reibung ist, die es einfach nicht wert ist. Du gewinnst nichts davon. Die Leute einfach class verwenden zu lassen, hat keine negativen Auswirkungen, außer dass es nicht mit der Destrukturierung und den Migrationskosten funktioniert. Jeder beschwert sich darüber, wenn er React lernt. Ich denke, das zu tun, was die Leute in diesem Fall erwarten, ist wichtiger als pedantisch zu sein. Und da wir sowieso andere DOM-Sachen ändern, fassen wir das zusammen.

Solange React Fire schnell lodert.... 👍

Diese Veränderungen sind alle fantastisch. Ich bin sehr aufgeregt darüber und seine Auswirkungen auf react-testing-library . Insbesondere Ereignisse, die an die React-Root gebunden sind (oder vielleicht sogar die Ereignisdelegierung ganz aufheben, da dies in modernen Umgebungen möglicherweise nicht mehr erforderlich ist?), möglicherweise synthetische Ereignisse entfernen/umschreiben und onChange -> onInput wird die Implementierung von react-testing-library und die Erfahrung bei der Verwendung des Tools erheblich verbessern.

Ich würde gerne Feedback dazu geben, während es implementiert wird.

Eventuell sogar ganz auf die Delegierung von Ereignissen verzichten, da dies in modernen Umgebungen möglicherweise nicht mehr erforderlich ist

Wir haben dies in Betracht gezogen, denken aber, dass dies eine zu starke Vereinfachung sein könnte. Durch die Ereignisdelegierung können wir das Einrichten einer Reihe von Listenern für jeden Knoten beim anfänglichen Rendern vermeiden. Und sie bei Updates austauschen. Diese Aspekte sollten nicht außer Acht gelassen werden. Es ist wahrscheinlich, dass dort mehr Benchmarking durchgeführt werden muss.

@tannerlinsley ({ class: className }) => <div class={className} /> Leider wird dies die jsx 2.0-Objektkurzschreibweise ( <div class /> ) beenden, aber sei es so ...

Es wäre super, super nett, wenn class neben Strings endlich auch Objekte und Arrays aufnehmen könnte.

Haben Sie ein Ziel für die Reduzierung der Bündelgröße?

Es wäre schön, ein Drittel von React DOM fallen zu lassen. Wir werden sehen. Es ist schwer zu früh zu sagen, aber wir werden unser Bestes geben.

Wow, das ist eine Aufzählung fast aller Designentscheidungen, die ich erwähne, wenn Leute mich nach den Nachteilen von React fragen.

Liebe die Richtung, in die das geht.

Wie sieht der Upgrade-Pfad für Bibliotheken aus, die className verwenden und mehrere Versionen von React unterstützen möchten?

@gaearon Vielleicht ist es keine große Sache, heute ist es schön zu sagen "Requisiten sind DOM-Eigenschaften, keine HTML-Attribute", jetzt wird es "außer Klassenname, das ist der HTML-Name" sein. Ich würde auch gerne in der Lage sein, SVG zu kopieren/einzufügen, ohne 10 Minuten mit Attributen herumzuspielen, um sie mit Reacts abzugleichen

Was ist mit htmlFor ?

Es fühlt sich so an, als ob der Übergang className -> class sehr sorgfältig durchgeführt werden muss, wahrscheinlich über einen längeren Zeitraum. Es wird viele Probleme für das Ökosystem verursachen, da praktisch jede Komponente geändert werden muss – sogar sehr triviale. Dies ist meistens in Ordnung, wenn Sie den Code "besitzen" und es einen Codemod gibt, aber wenn Sie von Bibliotheken von Drittanbietern abhängig sind, sind Sie weitgehend den Betreuern ausgeliefert.

Der Rest der Änderungen scheint aus Sicht des Ökosystems relativ risikoarm zu sein, aber className loszuwerden, wird wirklich viel Schmerz verursachen. Es scheint, als sollte es möglich sein, dies in eine separate Ausgabe aufzuteilen und nach einem anderen Zeitplan als die restlichen 🔥 Änderungen zu veröffentlichen.

Ich stimme @felixfbecker zu
Alles klingt großartig und würde die Qualität sowohl für Entwickler als auch für Benutzer verbessern, aber der Klassenname ändert sich.

In der Lage zu sein, alle Eigenschaften außer einer zu dekonstruieren, würde sicherlich mehr Verwirrung stiften und neuen Benutzern schwerer zu erklären sein, als dass sie className verwenden müssen, da class ein Schlüsselwort ist (was sie deutlich sehen können, wenn der Fehler gemacht wird, da es anders gefärbt ist). . Das Umgehen der Klasse beim Dekonstruieren erfordert die Einführung einer neuen Syntax oder eine völlig andere Methode zum Auslesen dieser bestimmten Eigenschaft, die nur funktionieren würde, bis Sie eine rest-Eigenschaft verwenden müssen.
Es schafft viele Probleme, nur vier Zeichen zu speichern.

@felixfbecker könnte es class / for in JSX und className / htmlFor in der JS-Version sein?

<label class="foo" for="bar">..</label>

wäre

React.createElement('label', {className: 'foo', htmlFor: 'bar'}, '..')

Toller Plan! Schön, dass hier! 👏👏👏

Das ist großartig, ich kann es kaum erwarten, in die neuen Sachen einzutauchen.

Vereinfachen Sie das Ereignissystem drastisch (#4751).

Jetzt kann React den Handler nicht an benutzerdefinierte Elemente delegieren, ohne die ReactDOM-Definition zu erweitern. https://github.com/facebook/react/issues/9242

Dies bedeutet, dass React keinen benutzerdefinierten Handler für benutzerdefinierte Elemente wie <x-component onMyEvent={ev => {...}} /> festlegen kann

@gaearon
Haben Sie diesbezüglich einen Plan?

All diese Änderungen sind ausgezeichnet, aber die größte Meta-Änderung von allen ist meiner Meinung nach die Größenreduzierung. React hat ein gemeines DX, aber es ist fett genug, dass das Herunterladen und Analysieren in durchschnittlichen Netzwerken und insbesondere auf Mobilgeräten ein Problem darstellt.

Wir könnten alles haben!

Würde das Umschreiben der Ereignisdelegation die Tür für die Behebung von #1254 öffnen; wobei einige Ereignisse die Leistung für den Knoten, an den sie angehängt sind, beeinträchtigen (was für React die gesamte App bedeutet).

Haben Sie auch überlegt, synthetische DataSet-Requisiten zu haben? Nicht in der Lage zu sein, zulässige HTML-Requisiten einzugeben (aufgrund von data-*), führt zu einer Menge Fehlern, wenn Props an die DOM-Knoten weitergeleitet werden. Derzeit typisierte React-Komponenten müssen zwischen exakten Typen für Props und zulässigen Datenattributen wählen.

Ich bin begeistert

@ryanflorence Ein bisschen offtop, aber es ist irgendwie traurig, dass niemand (soweit ich weiß) auf die Idee gekommen ist, einen html/css/svg -> jsx-Transfomer zu erstellen, um die Migrationen zu React mit so vielen trivialen Änderungen an der HTML-Zuordnung zu erleichtern attrs to React Requisiten. So viele Arbeitsstunden verschwendet, hauptsächlich Suchen und Ersetzen :(

Es ist sehr seltsam, Folgendes in derselben Ausgabe (und den Kommentaren) zu sehen:

Unser Ziel ist es, React besser an die Funktionsweise des DOM anzupassen
Klassenname → Klasse
Scheint seltsam, immer noch clipPath, htmlFor, tabIndex usw. zu machen.

Wenn all dies direkte Gegenstücke zu DOM-APIs sind

Und dieses Argument geht nicht durch:

Ich habe Ihre Seite dieses Arguments jahrelang verteidigt, aber ich denke jetzt, dass dies eine Reibung ist, die es einfach nicht wert ist. Du gewinnst nichts davon. Nur Leute den Unterricht benutzen zu lassen, hat keine negativen Auswirkungen, außer es

React war schon immer nur eine sehr dünne Schicht auf JS. Also war alles andere außer den spitzen Klammern von JSX JS _und_ hatte ein direktes Gegenstück in DOM-APIs für Dinge, die direkt mit DOM zu tun haben: className , clipPath , htmlFor , tabIndex usw. usw. usw.

Mit der Entscheidung, class einzuführen, hört React auf, eine dünne Schicht zu sein ( class ist ein reserviertes Wort in JS) und bricht mit dem erklärten Ziel, mehr Kompatibilität mit DOM-APIs zu erreichen.

Es ist besonders irritierend zu sehen, dass Sie sowohl „von onChange zu onInput migrieren“ wollen, weil es mit dem DOM inkonsistent ist _und_ mit dem DOM inkonsistent wird, indem Sie className -> class migrieren.

Darüber hinaus öffnet dies eine ganze Dose voller Würmer, da die Leute Änderungen an anderen Teilen fordern (und bereits fordern). Nur in den Kommentaren: Warum verwenden wir dataset statt data-* ? Vielleicht, weil data-* kein gültiges JS ist (ähnlich wie class ) und weil es mit den DOM-APIs konsistent ist? Warum ändern wir nicht htmlFor ? Weil for ein reserviertes Wort ist und htmlFor in DOM-APIs enthalten ist? usw. usw. usw.

Und doch, wenn wir ein unbekanntes Schlüssel/Wert-Paar übergeben, wird es seit React 16 als Attribut behandelt. Wir sind also bereits inkonsistent.

@gaearon , was auch der Grund ist, warum React die einzige Bibliothek ist, die beim Interop-Test von CustomElements Everywhere schlecht abschneidet: https://custom-elements-everywhere.com/
Und es gibt viele Probleme, die darum bitten, es zu ändern: https://github.com/facebook/react/issues/11347 , https://github.com/facebook/react/issues/7249 , https://github.com/facebook /react/issues/9230

Dies mag kein Problem sein, aber wird die Ähnlichkeit von React Fire zu React Fiber für Nicht-Muttersprachler verwirrend sein? Ich habe oft gedacht, dass die Newark Penn Station und die New York Penn Station, die hier in NYC auf derselben Bahnlinie liegen, ein besonders grausamer Witz für Touristen sind.

Wenn es ein echtes Problem ist, könnten Sie es React Flame nennen und trotzdem das Feuer 🔥 Emoji behalten.

Würde das Umschreiben der Ereignisdelegation die Tür für die Behebung von #1254 öffnen; wobei einige Ereignisse die Leistung für den Knoten, an den sie angehängt sind, beeinträchtigen (was für React die gesamte App bedeutet).

Das Beheben von # 1254 in irgendeiner Form ist definitiv etwas, das ich gerne sehen würde.

Haben Sie auch überlegt, synthetische DataSet-Requisiten zu haben?

Ich möchte mich jetzt nicht auf so etwas festlegen, weil es eine größere Oberfläche gibt. Eine reichhaltigere Schnittstelle für DOM ( ariaSet , dataSet , classList ) ist sinnvoll, aber es ist nicht klar, wie viel wir in React DOM investieren wollen, im Vergleich zu einer Bibliothek auf höherer Ebene gibt Ihnen eine reichhaltigere DOM-API. Da diese Änderungen eher kosmetischer Natur sind, aber eine große Oberfläche haben, würde ich damit aufhören.

Reagiere flammend 🔥

@ryanflorence Ein bisschen offtop, aber es ist irgendwie traurig, dass niemand (soweit ich weiß) auf die Idee gekommen ist, einen html/css/svg -> jsx-Transfomer zu erstellen, um die Migrationen zu React mit so vielen trivialen Änderungen an der HTML-Zuordnung zu erleichtern attrs to React Requisiten. So viele Arbeitsstunden verschwendet, hauptsächlich Suchen und Ersetzen :(

@jxub
https://transform.now.sh/html-to-jsx/

So gespannt auf die neuen Änderungen, ihr Menschen von Facebook schreibt mit dieser Migration Geschichte. 50.000 Komponenten werden zu React Fire migriert?
Ihre Testsuiten müssen so eng sein <3

Wird die Ähnlichkeit von React Fire zu React Fiber für Nicht-Muttersprachler verwirrend sein?

vielleicht auch für schwerhörige Leute (oder solche mit anderen Erkrankungen, die die Wortdiskriminierung betreffen)

Danke, dass du @gaearon geteilt hast, das ist großartig!

Ich würde gerne eine Version von JSX 2.0 sehen, die das Problem mit Leerzeichen und neuen Zeilen löst, das auftritt, wenn wir unseren Code mit Babel und Typescript kompilieren.

Es sind verschiedene Probleme offen und ich habe versucht, einen Beitrag zu leisten, wurde aber abgewiesen, weil das React-Team alles rund um JSX überprüfen muss.

Dieses Problem bezieht sich sowieso auf den Dom, da die Art und Weise, wie wir jsx in js übersetzen, nicht zulässt, was das w3c sagt.

Dies ist das Problem https://github.com/facebook/jsx/issues/19

Mein Kommentar steht ganz am Ende.

Ich denke, className ist ok. Lass es sein, was es ist. Fügen Sie der Verletzung keine Beleidigung hinzu.

Kann jemand bitte klären, wie sich dies auf bestehende Handler auswirkt?

Beenden Sie die Wiedergabe von Eingabewerten im value-Attribut

Wird React weiterhin kontrollierte Eingaben mit genauen event.target.value -Aktualisierungen in Handlern haben, oder wirkt sich dies nur auf das Lesen von Werten aus Refs und DOM-Knoten aus?

@nickmccurdy es beeinflusst, was Sie in den Browser-Entwicklungstools sehen

@tomdale React Ember 🔥

Hübsch! Ich warte auf die vollständige Liste der Änderungen in React 17.
Ich glaube, dass es eine neue Ära von ReactJS sein wird. 🔥⚛️

@tomdale Hmm : Garn, Faser, Stoff; Vielleicht könnte ein anderer kleidungsbezogener Begriff verwendet werden? 😆

Und doch, wenn wir ein unbekanntes Schlüssel/Wert-Paar übergeben, wird es seit React 16 als Attribut behandelt. Wir sind also bereits inkonsistent.

@gaearon , was auch der Grund ist, warum React die einzige Bibliothek ist, die beim Interop-Test von CustomElements Everywhere schlecht abschneidet: https://custom-elements-everywhere.com/

Nein, das ist nicht der Grund (benutzerdefinierte und normale Elemente sind völlig separate Codepfade). Der Grund dafür ist, dass wir bereits das alte Verhalten hatten und die Rückwärtskompatibilität nicht brechen wollten, es sei denn, das neue Verhalten war solide. Ich denke, es wäre sinnvoll, eine bessere Interop-Funktion für benutzerdefinierte Elemente als Teil dieses Dachs in Angriff zu nehmen.

Wird die Ähnlichkeit von React Fire zu React Fiber für Nicht-Muttersprachler verwirrend sein?

Beides sind interne Codenamen und haben nach Abschluss der Projekte keine wirkliche Bedeutung mehr. React Fire ist nur ein Versuch, React DOM besser zu machen – und bis es produktionsreif ist, wird es nur noch React DOM sein.

Wird React weiterhin kontrollierte Eingaben mit genauen event.target.value-Aktualisierungen in Handlern haben, oder wirkt sich dies nur auf das Lesen von Werten aus Refs und DOM-Knoten aus?

Ja, denn event.target.value ist eine Eigenschaft . Wir sprechen davon, die Aktualisierung von Attributen zu stoppen . Was keine anderen populären Bibliotheken tun (AFAIK) und das unzählige Probleme verursacht. Es sollte sich nicht auf Ihren Code auswirken, es sei denn, Sie verlassen sich auf CSS-Selektoren für den Wert (was wahrscheinlich sowieso schlecht ist).

Hübsch! Ich warte auf die vollständige Liste der Änderungen in React 17.

Beachten Sie, dass wir uns nicht dazu verpflichten, bis 17 Uhr fertig zu sein. Es könnte 18. oder 19. 😅 sein

Es ist schön, die stetige Entwicklung einer so guten Bibliothek wie React zu sehen. 🎉 class wird die Benutzerfreundlichkeit viel besser machen, es lohnt sich imo

@gaearon

benutzerdefinierte und normale Elemente sind vollständig getrennte Codepfade

Das selbst scheint auch etwas zu reparieren zu sein. Gibt es einen Grund, nicht alle Elemente gleich zu behandeln? Das ist die Absicht der HTML- und DOM-Spezifikationen.

@justinfagnani Wie bereits erwähnt, haben wir es damals nicht getan, weil es keine Konvention dafür gab, wie man feststellt, ob eine Eigenschaft oder ein Attribut festgelegt werden soll – und es bestand das Risiko, dass wir durch die Verwendung einer Überprüfung riskieren, dies zu tun unmöglich, dass die Webplattform dem Prototyp neue Eigenschaften hinzufügt. Ich denke, inzwischen gibt es bereits eine Art Konsens in den RFCs und PRs, an denen @robdodson gearbeitet hat, und wir können es wahrscheinlich von dort abholen.

👍 🔥 🔥 🔥

React Fire sollte es uns auch ermöglichen, einige der cleveren Leistungsoptimierungen anzuwenden, die Inferno hat – aber wegen Breaking Changes nicht anwenden konnte. Aufregende Zeiten :)

LGTM

Bezogen auf die vorgeschlagene className -> class Umbenennung: Ich würde gerne eine classes Eigenschaft haben, die ein Array von Strings annehmen würde. Das würde mir die Mühe einer Menge String-Manipulation (oder die Verwendung von classnames ) in meinen Komponenten ersparen.

Ich denke, der einzige Nachteil einer classes -Prop wäre, dass Arrays, die dieselben Strings in derselben Reihenfolge enthalten, ein Re-Rendering in reiner Komponente verursachen würden, während ein String derselben CSS-Klassen dies nicht tun würde. Ehrlich gesagt scheint es ein kleines Problem zu sein. Ich denke, die meisten React-Entwickler kennen bereits die Kompromisse von Arrays und Objekten in Requisiten.

@gaearon hast du Pläne für Abwärtskompatibilität? Folgen Sie vielleicht dem gleichen Weg wie React Fiber, fügen Sie Warnungen zu den Änderungen hinzu und geben Sie Zeit für die Aktualisierung großer Codebasen, ohne dass neue Updates verloren gehen.

https://www.youtube.com/watch?v=F1U0qvtQnE8

In Bezug auf class und className .

Ich weiß, dass wir diesbezüglich keine breite Einigung erzielen werden, egal, welchen Weg wir gehen. Die Leute haben wirklich starke Meinungen zu diesem. Ich möchte mitteilen, wie ich darüber denke, in der Hoffnung, dass es hilfreich sein wird.

Die Komponenten-API sollte sich idiomatisch anfühlen

Es gibt ein allgemeines Argument, dass React „mit JavaScript übereinstimmt“ und daher className bevorzugt wird. Ich denke, diese Behauptung wird auf subtile Weise missverstanden, daher möchte ich mich ein wenig darauf konzentrieren.

In React kümmern wir uns in erster Linie darum, dass sich die Verwendung einer React-Komponente wie idiomatisches JavaScript anfühlen sollte . Das heißt, wenn ich eine hypothetische <Table> -Komponente verwende, erwarte ich, dass ihre Requisiten camelCase sind:

<Table
  rowHeight={10}
  headerBorderInset={5}
  renderRow={this.renderRow}
/>

Ich erwarte nicht, Prop-Namen wie row_height oder row-height in der öffentlichen API einer Komponente zu sehen. Die Requisiten der Komponente sind ein Objekt (ähnlich wie eine "Optionstasche"), und wir erwarten im Allgemeinen, dass diese Optionen camelCase sind. Dies ist im DOM vielleicht nicht immer idiomatisch, aber das DOM ist an vielen Stellen nicht sehr konsistent. React passt sich dem JavaScript-Ökosystem an, das überwiegend camelCase verwendet.

Aber was ist mit dem DOM? Hier wird es dornig.

DOM-Eigenschaften sind nicht nur "Attribute in JS"

In DOM haben wir Attribute und Eigenschaften. Attribute sind die Dinge, die Sie normalerweise in HTML sehen. Eigenschaften sind die Dinge, die Sie normalerweise von JS aus festlegen. Aber entscheidend ist, dass DOM-APIs sowohl zum Festlegen von Eigenschaften als auch zum Festlegen von Attributen existieren – und sie setzen nicht einmal immer dasselbe.

node.value = 10; // setting a property
node.setAttribute('value', '10'); // setting an attribute

In vielen Fällen spielt es keine Rolle. In manchen Fällen tut es das. Aber vielleicht nicht so, wie man es sich bei der Verwendung von React vorstellen könnte (das eine Abstraktion über beide hat).

Reagieren ist nicht nur das Festlegen von Eigenschaften

Ein häufiges Missverständnis ist, dass React, da es derzeit die camelCase -Konvention für die meisten DOM-Props verwendet, bedeutet, dass React DOM-Eigenschaften setzt. Das ist falsch.

Tatsächlich verwendet React derzeit Attribute für fast alle unterstützten Requisiten. In einigen Fällen, wie value , verursacht dies Probleme (die wir, wie ich besprochen habe, rückgängig machen wollen). In anderen Fällen ist das sogar großartig – weil wir keine Liste der unterstützten Eigenschaften in das React-Bundle aufnehmen müssen. Die Verwendung von Attributen unter der Haube ermöglichte eine erhebliche Größenreduzierung in React 16.

Mein Punkt hier ist, dass die Frage, ob React intern Eigenschaften oder Attribute verwendet, ein Implementierungsdetail ist – und nichts damit zu tun hat, ob das DOM-Element _API_ von React Eigenschaftsnamen, Attributnamen oder sogar einige andere sinnvolle Namen verwenden sollte.

Trotzdem, verwenden wir einfach Eigenschaftsnamen?

Okay, Eigenschaften und Attribute sind ein Implementierungsdetail. Aber warum nicht einfach die Verwendung von DOM-Eigenschaftsnamen standardisieren, da diese speziell "für JavaScript" erstellt wurden? Ist die React-API nicht heute so konzipiert?

Nicht ganz. Nur eine der unten aufgeführten Requisiten entspricht einer echten DOM-Objekteigenschaft:

<div
  tabIndex={1}
  data-id="123"
  aria-live="polite"
  nopin="nopin"
  itemType="http://schema.org/Movie"
  onClick={function() { alert('hi') }}
/>

Ironischerweise wird die einzige Requisite oben, die eine tatsächliche DOM-Eigenschaft mit demselben Namen hat ( tabIndex , wenn Sie sich nicht sicher sind), tatsächlich von React als Attribut festgelegt!

An diesem Punkt sehen Sie also wahrscheinlich, dass es weder eindeutig noch konsistent ist. In einigen Fällen existieren keine Eigenschaften (z. B. für benutzerdefinierte, nicht standardmäßige Attribute), in einigen Fällen könnte React eine reichhaltigere API bereitstellen ( data- vs. dataSet ), tut dies aber derzeit nicht.

In einigen Fällen entscheidet sich React bewusst für eine Abweichung ( onClick in React gegenüber onclick DOM-Eigenschaft), da dies für benutzerdefinierte React-Komponenten sinnvoller ist. Dies liegt daran, dass React-Komponenten oft komplexere Event-Handler wie onItemClick . Es wäre sehr widersprüchlich, wenn Sie <Button onclick> aber <Table onItemClick> würden. Und <Table onitemclick> ist nicht camelCase, was wir in einer Komponenten-API vermeiden wollten.

Oben habe ich erklärt, dass React bereits nicht konsequent ist , "immer den DOM-Eigenschaftsnamen zu verwenden", dass React Eigenschaften nicht einmal intern verwendet (so dass diese Faustregel auch nicht die tatsächliche Mechanik beschreibt), und das in vielen In Fällen, in denen DOM-Eigenschaften einfach nicht existieren, müssen wir beim Zulassen des Attributnamens bleiben.

Wenn nicht Eigenschaftsnamen, lasst uns konsistent sein und Attributnamen verwenden?

Warum also nicht nur Attributnamen verwenden? Das könnte plausibel sein. Aber jetzt stoßen wir auf die allererste Überlegung, die wir angestellt haben. Die Verwendung einer React-Komponente sollte sich wie idiomatisches JavaScript anfühlen . Aber oft leiten Komponenten zumindest einige Requisiten an das zugrunde liegende DOM-Element weiter.

<Button
  borderColor='red'
  tabIndex={1}
 />

 // renders...

 <button
   tabIndex={1}
/>

Es wäre für ein benutzerdefiniertes Button umständlich, Requisiten mit inkonsistenter Großschreibung zu akzeptieren:

<Button
  borderColor='red'
  tabindex={1}
 />

Dies zwingt den Verbraucher, sich immer daran zu erinnern, ob eine bestimmte Stütze eine tatsächliche DOM-Stütze oder nur ein Teil des Komponentenvertrags ist. Selbst diese Unterscheidung ist unscharf – eine Komponente kann sich dafür entscheiden, zuerst eine bestimmte Requisite durchzulassen, sie dann aber tatsächlich für zusätzliche Logik zu verwenden. Wo ziehen Sie die Grenze zwischen „DOM-Requisiten“ und „anderen Requisiten“?

Ich denke, das ist der Hauptgrund, warum es wünschenswert ist, dass Requisiten wie tabIndex , cellSpacing und die meisten anderen DOM-bezogenen Requisiten der camelCase-Konvention folgen. Das liegt daran, dass sie oft in Komponenten-APIs landen.

Wir möchten es benutzerdefinierten Komponenten wie Button leicht machen, sie zu umschließen und weiterzuleiten, ohne sie an dem Punkt, an dem sie in das DOM fließen, in den Attributnamen zu "übersetzen" und ohne Nicht-camelCase-Requisiten in a einzuführen benutzerdefinierte Komponenten-API.

Dies erklärt auch, warum Requisiten wie data-* , aria-* und benutzerdefinierte Attribute vernünftige Ausnahmen sind (obwohl wir reichhaltigere APIs für sie erstellen könnten ). Sie werden selten an benutzerdefinierte Komponenten weitergegeben. Normalerweise sind sie zu sehr an das DOM gekoppelt, um in benutzerdefinierten Komponenten nützlich zu sein – und werden stattdessen zu einem Implementierungsdetail von so etwas wie <Modal> oder <Button> mit einer umfangreicheren CamelCase-API.

React-Eigenschaften stimmen bereits nicht mit DOM-Eigenschaften überein

Wenn die Konvention "DOM-Eigenschaftsname" nicht funktioniert hat, brauchen wir etwas anderes. Was ist es? Könnte es "camelCase-Version des Attributnamens" sein? Es scheint, als ob dies fast immer bereits auscheckt.

Wenn dies zu radikal klingt, bedenken Sie, dass wir dies bereits tun. Wir unterstützen etwas namens srcSet . Aber der DOM-Eigenschaftsname dafür ist srcset . Wir haben autoCapitalize , aber die DOM-Eigenschaft heißt autocapitalize . Wir haben autoFocus , aber die DOM-Eigenschaft ist autofocus .

Wir weichen bereits von DOM-Eigenschaftsnamen ab, wenn sie nicht der camelCase-JavaScript-Konvention entsprechen. Das bringt uns zu class .

Schließlich: className gegen class

Ein Teil der ursprünglichen Begründung dafür, es zu className zu machen, war, dass React DOM-Eigenschaften gesetzt hat und className der Name der DOM-Eigenschaft ist.

Wie ich oben erklärt habe, verwendet React jedoch keine Eigenschaften mehr, außer drei oder vier Sonderfällen. Noch wichtiger ist, dass React nicht einmal konsequent DOM-Eigenschaftsnamen verwendet – vielmehr verwendet es Namen, die natürlich aussehen würden, wenn sie von JavaScript verwendet würden, unabhängig von internen Namensinkonsistenzen in DOM-Attribut- und Eigenschaftsnamen. Und das liegt daran, dass React sich am meisten darum kümmert, dass sich Prop-Namen für benutzerdefinierte Komponenten "JavaScripty" anfühlen. In diesem Sinne ist tabindex kein „JavaScripty“ – aber sowohl class als auch className sind es.

Ein weiteres Argument gegen class war schon früh, dass Code wie dieser für ES3 (relevant für IE8) nicht gültig war:

// Not valid in ES3
// Valid in ES5
var props = { class: 'foo' };

Aber die meisten schreiben ES3 nicht mehr. Entweder verwenden Sie eine Toolchain wie Babel oder Sie zielen wahrscheinlich auf IE9+ ab – React unterstützt jetzt nicht einmal IE8.

Die einzige Unannehmlichkeit, die bei class bleibt, ist, dass Sie Folgendes nicht schreiben können:

// Not valid at all :-(
const class = props.class;
const { class } = props;

Aber ich denke, dass dieses Argument mit der Zeit nicht mehr stark genug ist. React zwingt Sie nicht, Destrukturierung oder diesen spezifischen Variablennamen zu verwenden und so etwas wie zu schreiben

// Valid
const {class: cls} = foo;
const cls = props.class;

ist nicht viel mehr Aufwand.

Typischerweise werden class viel öfter weitergegeben als gelesen, da viele Komponenten mehr als ein inneres <div> oder andere Host-Elemente enthalten. Sie schreiben also viel häufiger <div className> , als class destrukturieren zu wollen. Und somit würde die Änderung zu class mehr Tastatureingaben einsparen, als sie einführen würde.

Hier gibt es noch einen weiteren wichtigen Punkt.

Das Durchreichen class durch viele Ebenen ist an sich kein großartiges Muster. Es ist für Bibliotheken notwendig, aber im Anwendungscode führt es oft zu fragilen Komponenten. Diejenigen, deren Stil ständig bricht, weil es hundert verschiedene Callsites gibt, von denen jede eine andere Klasse anhängt, was Kaskadenfehler verursacht. Es ist also nicht klar, wie wertvoll es ist, die Destrukturierung class überhaupt zu fördern. Ich denke, es ist in Ordnung, dass Sie eine weitere Codezeile schreiben müssen, um sie aus Requisiten zu lesen (oder Sie können einfach props.class verwenden und nicht darüber nachdenken).

Wenn Sie eine Komponente schreiben, die dem DOM sehr nahe kommt (und es daher sinnvoll ist, class als Requisite zu verwenden), möchten Sie wahrscheinlich auch andere Requisiten weiterleiten. So können Sie bei der Destrukturierung die rest-Syntax verwenden:

// Valid in ES2018

function Button({ color, ...rest }) {
  const buttonClass = rest.class +  ' Button-' + color;
  return <button {...rest} class={buttonClass} />
}

Und wenn Sie es nicht ändern müssten, hätten Sie einfach {...rest} weiterleiten können, ohne auch nur class daraus zu lesen. Die Destrukturierungsbeschränkung könnte also dazu beitragen, ein besseres Komponentendesign zu fördern.

Warum nicht beide?

Können wir schließlich nicht einfach sowohl class als auch className unterstützen? In gewisser Weise tun wir das bereits, aber React schreit Sie mit einer Warnung an. Dafür gibt es einen Grund.

Wenn wir beide ohne Vorwarnung unterstützen, wird sich die Community darüber aufteilen, welche verwendet werden soll. Jede Komponente in npm, die eine Klassenstütze akzeptiert, muss daran denken, beide weiterzuleiten. Wenn auch nur eine Komponente in der Mitte nicht mitspielt und nur eine Stütze implementiert, geht die Klasse verloren – oder Sie riskieren, am Ende mit class und className am Ende „nicht einverstanden“ zu sein andere, ohne dass React diesen Konflikt lösen kann. Wir denken also, dass dies schlimmer wäre als der Status quo, und möchten dies vermeiden.

Zusammenfassung

Wenn React heute Open Source war, scheint es, als würden die Vorteile, class (konzeptionell näher an dem, was die meisten Leute erwarten, weniger Tippen für die am häufigsten verwendete Requisite) zuzulassen, die Nachteile überwiegen (etwas mehr Tippen, um es abzufangen – in In welchen Fällen möchten Sie wahrscheinlich sowieso nur den Spread-Operator).

Was wir früher als Nachteile betrachteten (inkonsistent mit DOM-Eigenschaften), ist strittig, weil wir weder DOM-Eigenschaften mehr festlegen noch uns bemühen, mit ihnen konsistent zu sein. Stattdessen streben wir eine attributbasierte, aber camelCase-API auf der konsumierenden Seite der React-Komponenten an – womit wir bereits fast konsistent sind. Und class="Button" ist eindeutig bequemer als className="Button" . Wenn die DOM-API heute entwickelt würde, könnten Sie wahrscheinlich die .class -Eigenschaft genau deshalb festlegen, weil die Beschränkung der Verwendung class in einer Aufgabe wie dieser in ES5 aufgehoben wurde – vor fast zehn Jahren.

Der einzige verbleibende große Nachteil sind die Migrationskosten. Wir werden dies sorgfältig prüfen. Aber wenn wir sowieso ein paar Änderungen vornehmen, können wir vielleicht auch diese vornehmen und endgültig beheben. Wir denken nicht auf die leichte Schulter und berücksichtigen alle Ihre Bedenken.

Hinweis: Dies kann für andere React-Prop-Namen sinnvoll sein, die nicht mit camelCased-Attributnamen übereinstimmen.

@renatoagds

Haben Sie Pläne für Abwärtskompatibilität? Folgen Sie vielleicht dem gleichen Weg wie React Fiber, fügen Sie Warnungen zu den Änderungen hinzu und geben Sie Zeit für die Aktualisierung großer Codebasen.

Wie ich feststellte:

Und wir haben mehr als 50.000 Komponenten bei Facebook, um unsere Migrationsstrategie ehrlich zu halten. Wir können es uns nicht leisten, Produktcode neu zu schreiben, außer ein paar gezielte Korrekturen oder automatisierte Codemodifikationen.

Wir werden also auf jeden Fall versuchen, die Migrationsstrategie so reibungslos wie möglich zu gestalten, so wie wir es immer tun. Wenn es nicht glatt ist, können wir die Änderung nicht selbst vornehmen.

re: className -> class, ich bin cool mit welcher Entscheidung auch immer, ich sehe definitiv die Ausnahme, die Klasse für neue Benutzer zu ändern, und einen Nebeneffekt kürzerer Codezeilen. Sie müssten jedoch noch etwas über die anderen camelCase-Namen lernen.

Die einzige Unannehmlichkeit, die mit der Klasse übrig bleibt, ist, dass Sie dies nicht schreiben können:

const { class } = props;

Aber ich denke, dass dieses Argument mit der Zeit nicht mehr stark genug ist. React zwingt Sie nicht, > Destrukturierung und Schreiben zu verwenden

const class = props.class;

ist nicht viel mehr Aufwand.

Zwei (möglicherweise kleine) Dinge:

1. Ist const class = props.class nicht ungültiges JavaScript? Ich dachte nicht, dass es so ist, und in einem kurzen Test mag Chrome es nicht. Außerdem weist dieser Artikel darauf hin, dass es nicht gültig ist.

2. Ich könnte sehen, dass diese Änderung ein (wiederum möglicherweise kleiner) Bereich der Frustration für Leute ist, die Komponenten wie diese schreiben: nvm (siehe Update unten)

const { oneProp, twoProp, className, ...rest }  = this.props;

// do stuff with oneProp, twoProp, className

return (
  <div
    someProp={prop}
    anotherProp={anotherProp}
    className={someClassName}
    {...rest}/>
);

Nach dieser Änderung müsste dies so etwas sein wie ...

const { oneProp, twoProp, ...rest }  = this.props;

// do stuff with oneProp, twoProp, this.props.className

return (
  <div
    someProp={prop}
    anotherProp={anotherProp}
    {...rest}
    class={someClassName}/>
);

Es ist nicht unmöglich, diese Änderung zu umgehen, aber es ist ein bisschen mehr zu beachten, wenn Sie Komponenten in diesem Stil schreiben und lesen.

Aktualisieren :

Egal,

const { class: className } = this.props;

macht den Trick.

Der einzige verbleibende große Nachteil sind die Migrationskosten. Wir werden dies sorgfältig prüfen. Aber wenn wir sowieso ein paar Änderungen vornehmen, können wir vielleicht auch diese vornehmen und endgültig beheben. Wir denken nicht auf die leichte Schulter und berücksichtigen alle Ihre Bedenken.

Glücklicherweise lässt sich dies leicht abmildern, wenn man einen CSS-in-JS-Ansatz wie Aesthetic verwendet. Danke für das tolle Schreiben!

Zufälliger Tipp bezüglich Attributnamen, ich fand das ausgezeichnete Projekt, svg2jsx eignet sich hervorragend zum Konvertieren großer SVGs zur Verwendung in React!

@james please Entschuldigung, mein Verstand war leer – du hast Recht. Bearbeitet.

@JamesBitte du hast Recht. Das kommt auch häufig vor, wenn man mit JSON arbeitet, für den Standardwert, also ärgerlich!

const { default: defaultVal } = property

Während Sie das Ereignissystem ändern, wäre es wirklich schön, etwas Ähnliches wie die linkEvent-Funktion von Inferno zu sehen, damit wir die Ereignisbehandlung mithilfe von Requisiten in funktionalen Komponenten durchführen können, ohne bei jedem Rendern eine anonyme Funktion erstellen zu müssen.

className -> class wird eine große Veränderung für das Ökosystem darstellen, zahlreiche nicht gewartete Komponenten werden inkompatibel und es gibt nichts, was Sie tun können, wenn Sie sie nicht patchen können. Haben Sie vielleicht einen Wrapper wie StrictMode , der diese Änderung für die Komponenten tiefer im Baum deaktiviert, um einen schrittweisen Migrationspfad bereitzustellen?

Ich könnte sehen, dass diese Änderung ein (wiederum möglicherweise kleiner) Bereich der Frustration für Leute ist, die Komponenten wie diese schreiben:

const { oneProp, twoProp, className, ...rest }  = this.props;

// do stuff with oneProp, twoProp, className

return (
 <div className={someClassName} {...rest}/>
);

Nur nicht destrukturieren.

const { oneProp, twoProp, ...rest }  = this.props;

return (
  <div
    {...rest}
    class={'something ' + rest.class}
  />
);

@gaearon

Ob React intern Eigenschaften oder Attribute verwendet, ist ein Implementierungsdetail

Das scheint ehrlich gesagt auch ein Problem zu sein. DOM-Elemente können sich in einigen Fällen unterschiedlich verhalten und tun dies auch, je nachdem, ob Sie Attribute oder Eigenschaften festlegen. React kann unmöglich alle Unterschiede kennen, aber Benutzer von Elementen können wissen, welche Elemente sie verwenden. Die explizite Kontrolle über Eigenschaften, Attribute und Ereignisse würde es Autoren ermöglichen, aus dieser Situation auszubrechen.

@justinfagnani Wenn Sie bestimmte Dinge haben, die wir ändern sollen, haben Sie etwas dagegen, ein separates Problem mit einer von Ihnen vorgeschlagenen API zu melden? Das klingt etwas außerhalb des Rahmens dieses Problems.

@sompylasar

className -> class wird eine große Veränderung für das Ökosystem darstellen, zahlreiche nicht gewartete Komponenten werden inkompatibel und es gibt nichts, was Sie tun können, wenn Sie sie nicht patchen können. Vielleicht haben Sie einen Wrapper wie StrictMode, der diese Änderung für die Komponenten tiefer im Baum deaktiviert, um einen schrittweisen Migrationspfad bereitzustellen?

Ich stimme zu – und wir wägen immer noch Vor- und Nachteile ab. Nichts ist abgeschlossen.

Aber in der Praxis ist das Problem nicht gewarteter Komponenten nicht neu – es taucht in jeder Hauptversion von React auf, weil sich per Definition etwas in den Hauptversionen ändert (anders können wir nicht vorankommen und wir haben nicht den Luxus, den gesamten Legacy-Code zu behalten das Bundle für immer, anders als z. B. in Serverumgebungen). Das gleiche Problem trat auf, als PropTypes in ein separates Paket verschoben wurde, und wird mit der Umbenennung des Lebenszyklus UNSAFE_ erneut auftreten. Nicht gepflegte Pakete werden gegabelt oder gepatcht. Wir wissen, dass es ein großer Zeitverlust ist, und deshalb vermeiden wir es, mehr als einen großen Major in einem Jahr zu absolvieren. Für Leute, die es sich nicht leisten können, zu helfen, ist es in der Regel die beste Strategie, ein paar Monate zu warten, bevor sie zu einem neuen Major wechseln, da Early Adopters den Weg ebnen und die verlassenen Pakete wiederbeleben. Dann gehen wir alle gemeinsam voran.

Nochmals – ich verstehe Ihr Zögern sehr, aber dies unterscheidet sich nicht grundsätzlich von anderen bahnbrechenden Änderungen, die in der Vergangenheit stattgefunden haben oder in Zukunft passieren könnten. Wie immer werden wir viel Mühe und Wert auf automatisierte Skripte legen, die Sie ausführen können, um den größten Teil Ihrer Codebasis zu konvertieren, und die Sie auch auf anderen Paketen ausführen können (und PRs an sie senden – oder sie in ihrem letzten Zustand forken können ).

Unabhängig von Ihrer Entscheidung ist ein weiteres Argument gegen class die Durchsuchbarkeit. Wie viele Fehlalarme geben Ihnen die Suche nach class , wenn Sie Komponenten finden wollten, die CSS-Klassen in ES6-Code verwenden, der JS-Klassenkomponenten verwendet? Ja, Sie können nach class={ suchen, aber was ist mit der Destrukturierung von Requisiten in JSX, die als Objekt in JS erstellt wurden? (Ich bin gegen den starken Einsatz von Requisiten-Destrukturierung, aber sie werden immer noch verwendet.) Natürlich brauchen wir bessere kontextsensitive AST-basierte Suchwerkzeuge in Code-Editoren, aber im Moment haben wir nur Text und reguläre Ausdrücke. Natürlich können Typensysteme helfen, das Passieren von Objekten zu verfolgen, aber eine große Bevölkerung hat sie nicht übernommen.

Etwas über die Verwendung eines reservierten Wortes passt einfach nicht zu mir, auch wenn es jetzt keine Probleme verursacht; Können wir mit Sicherheit sagen, dass rest.class (zum Beispiel) in x Jahren für die Sprache keine Bedeutung mehr haben wird?

@GeordieP Wenn es heute funktioniert, kann es morgen nicht kaputt gehen. Das ist das Kernprinzip, wie JavaScript entwickelt wird, und der Grund für viele seiner Eigenheiten.

@gaearon Fair genug, dann. Wenn der Gewinn groß genug ist, sage ich: Go for it.

@sompylasar Ich suche normalerweise nach className= oder className: , es scheint, als würden beide auch mit class funktionieren.

Bitte lösche className und um Himmels willen htmlFor . Ich bin kein DOM-Entwickler, normalerweise läuft etwas sehr sehr falsch, wenn ich auf native DOM-Methoden zugreifen muss. Die größte Herausforderung, die ich beim Onboarding von Leuten für React habe, ist die Abstraktion, die JSX über das DOM und seine seltsamen Ersatz-HTML-Attribute macht. Alles wird transpiliert, kein Grund, sich an dieser Stelle um reservierte Wörter zu kümmern. Meiner Meinung nach.

Ich bin mir nicht sicher, ob dies der bestehenden Diskussion etwas hinzufügt, aber es scheint, dass es einen besseren Grund geben sollte, className zu ändern.

Ist das Speichern von React-Anfängern vor einem etwas unintuitiven Namen es wert, dass jeder seine Projekte und sein Verhalten aktualisieren muss?

Als jemand, der Destrukturierung großzügig einsetzt, ist es wahrscheinlich ein größeres geistiges Problem, sich an diese neue Ausnahme von der Regel zu erinnern, als die seltene Gelegenheit, dass ich class anstelle von className schreibe.

Würden Anfänger nicht auch immer noch verwirrt sein von der riesigen Menge an Material (wie Blogs/Repos/usw.), das derzeit className verwendet?

Schließlich schadet dies, wie @sompylasar sagte, der Suchfähigkeit in meiner Codebasis.

Vielleicht ist dies ein Argument vom Typ Tabulatoren vs. Leerzeichen, aber ich verstehe nicht ganz, warum diese Änderung notwendig ist. Es scheint ein großer Preis für wenig Gewinn zu sein, es sei denn, dies ist Teil einer größeren Veränderung in der Art und Weise, wie Sie die API im Laufe der Zeit modellieren möchten. Das heißt, ich werde auf jeden Fall verwenden, was immer du entscheidest 😅.

Ein bisschen offtop, aber es ist irgendwie traurig, dass niemand (soweit ich weiß) auf die Idee gekommen ist, einen html/css/svg -> jsx-Transfomer zu erstellen, um die Migrationen zu React mit so vielen trivialen Änderungen zu erleichtern, um HTML-Attribute zuzuordnen Requisiten reagieren.

@jxub - Ich habe bereits 2014 im Rahmen eines Hackathons einen HTML-zu-JSX-Konverter erstellt: https://magic.reactjs.net/htmltojsx.htm. Ich bin mir jedoch nicht sicher, ob es mit SVG gut umgeht. Das Hackathon-Projekt bestand darin, ein Skript zu erstellen, das eine einfache HTML-Site mithilfe von React (https://github.com/reactjs/react-magic) „ajaxifiziert“, und ein Teil davon erforderte, dass ich eine Möglichkeit zum Erstellen einer React-Komponente entwickelte aus einem Stück HTML, also habe ich den HTML-zu-JSX-Teil als separate eigenständige Seite veröffentlicht.

Wir kümmern uns immer noch um die Unterstützung von IE11, aber es ist möglich, dass wir nicht versuchen werden, einige der bestehenden Browserunterschiede auszugleichen – das ist die Haltung vieler moderner UI-Bibliotheken.

@gaearon - Was sind einige Beispiele für moderne UI-Bibliotheken, die Browserunterschiede nicht ausgleichen? Für mich ist das einer der Hauptgründe, eine Bibliothek zu nutzen.

Verschwörungstheorie: Dieser ganze Klassenname / die Klassennachrichten sind eine helle kontroverse Sache, der jeder sofort Aufmerksamkeit schenken und darüber streiten wird. Es soll entweder die Aufmerksamkeit auf das Überarbeitungsprojekt als Ganzes lenken oder von etwas Größerem ablenken, das im Schatten passiert, oder etwas geben, das später zurückgenommen werden kann, während der Rest akzeptiert wird, wie in der folgenden Anekdote:

Der große Theaterkünstler Tyshler, der Landschaftsskizzen anfertigt, zeichnet in der Ecke einen kleinen grünen Hund. Und als eine der Zulassungskommissionen fragte: „Mir gefällt alles, aber wo ist dieser Hund?“, plagte die Künstlerin sie mit einem Seufzer des Bedauerns.

Die wahren Gründe für diese Änderung sind nicht klar, aber sie haben die Popularität dieses neuen Upgrade-Projekts und die Begeisterung der Community um React bereits in die Höhe getrieben.

Es wäre schön, wenn die Unterstützung von Passive Event Listeners im Rahmen von React Fire liegen würde, was eine wichtige Funktion auf Mobilgeräten ist.

6436

Vielen Dank für Ihre harte Arbeit, aber bitte überdenken Sie noch einmal className -> class .

Wir waren alle einmal React-Neulinge und className hinderten uns nicht daran, React zu lernen und zu lieben.

Ich erinnere mich, als ich vue mit jsx benutzte, hatten sie bereits class und nicht className , ich bin nicht einverstanden, wenn className in class geändert wird, weil React Pionier in Virtual DOM ist , und repräsentieren DOM selbst.

Hängen Sie Ereignisse an das React-Stammverzeichnis und nicht an das Dokument an

@gaearon Bedeutet dies, dass ich in einer Testumgebung keine Elemente an das Dokument anhängen muss, um echte Browserereignisse senden und die ihnen zugeordneten Handler aufrufen zu können? Dies zu tun ist sehr kontraintuitiv und ich bin sicher, dass viele Entwickler, die mit den Interna von React nicht vertraut sind, verwirrt sind, viel Zeit mit dem Schreiben von Tests verschwenden und sich auf Ereignissimulationen und schlechte Testpraktiken einlassen.

Was mich zu einer anderen Anmerkung bringt, können wir etwas gegen react-dom/test-utils unternehmen? Ich interessiere mich besonders für die mögliche Entfernung von Simulate angesichts all der damit verbundenen Probleme, die wir alle kennen, und nehme natürlich die notwendigen Änderungen in react-dom selbst vor, damit es wirklich nicht benötigt wird mehr. Könnte das im Umfang liegen?

/cc @kentcdodds

Ich liebe die Richtung und den Gesamtblick, den React Fire einschlägt. Bisher sehen diese nach großartigen Veränderungen aus, auf die man hinarbeiten kann.

Ich liebe die meisten angekündigten Änderungen, aber ich bin skeptisch gegenüber der className -Änderung.

React zwingt Sie nicht, Destrukturierung oder diesen spezifischen Variablennamen zu verwenden, und das Schreiben von etwas wie (...Code-Snippet...) ist nicht viel aufwändiger.

Es ist zwar nicht viel Aufwand zu schreiben, aber nach meiner derzeitigen Erfahrung würde ich erwarten, dass es _viel_ schwieriger ist, es anderen Entwicklern (insbesondere Entwicklern aus anderen Sprachen) zu erklären. Andererseits waren in all den Jahren, in denen wir React in unserem Unternehmen verwendet haben, wohl nur ein oder zwei Entwickler von className verwirrt und haben dies einfach als Reacts-API akzeptiert, um die Klassennamen innerhalb weniger Minuten festzulegen.

(Meiner persönlichen Meinung nach, obwohl ich das Destruieren _liebe_, fühlt sich die Umbenennungssyntax für Anfänger manchmal seltsam an, weil sie anders ist als das Umbenennen in Importen, das ziemlich ähnlich aussieht und mit Dingen wie Standardwerten kombiniert werden kann. Man _könnte_ dann einfach kein Destructing verwenden , aber das wäre eine _große_ Ausnahme zu allem anderen Code, den wir derzeit in unserem Unternehmen schreiben. Erfahrungen von anderen Können natürlich abweichen, aber das ist meine Sicht auf das Problem 🙃.)

großartig

Auch skeptisch gegenüber der Änderung von className . Es ist eine der geringfügigsten Änderungen im Schema der Dinge, aber es zieht einen großen Teil der kommentierenden Diskussion hier an.

Lohnt es sich wirklich, so viel politisches Kapital für eine Veränderung auszugeben, wenn so viel anderes Gutes angekündigt wird?

Aus meiner Sicht, wenn Sie eine Entscheidung treffen, bei der ein Teil der Rechtfertigung lautet: „Und etwas zu schreiben wie … … ist nicht _dass_ viel mehr Aufwand.“ Diese Entscheidung muss einen _massiven_ Vorteil haben, und die Änderung className -> class ändert sich einfach nicht im Vergleich zu allem anderen, was angekündigt wurde.

Dies wird ein großer Fortschritt für 🔥 React Fire sein

Über class vs. className sollten wir uns meiner Meinung nach daran erinnern, dass JSX ≠ React ist.

Da JSX ein _DSL_ ist, das wie HTML aussieht, ist es am besten, es so nah wie möglich an HTML zu halten. Zugegeben, in der DOM-API heißt es className , aber die meisten verwenden JSX, wahrscheinlich weil sie nicht direkt mit der DOM-API umgehen wollen.

Wenn es für die API von React sinnvoller ist, eng mit der DOM-API übereinzustimmen, dann hoffe ich, dass es in Ordnung/möglich ist, die Zuordnung in der Transpilation vorzunehmen:
<img src="avatar.png" class="profile" /> → React.createElement("img", { src: "avatar.png", className: "profile" }) .

Es wäre sehr wertvoll, die JSX-Syntax zu einer sauberen Obermenge von HTML zu machen.

Um das zu ergänzen, was @mhenr18 gesagt hat.

Aktueller Stand der Dinge:

• Die Reaktion ist inkonsistent
• API ist camelCase

Vorgeschlagener Stand der Dinge:

• Die Reaktion ist inkonsistent
• API ist camelCase
• className -> class

Wahrgenommene Vorteile:

Wenn React heute Open Source war, scheint es, als ob die Vorteile des Zulassens von Klasse (konzeptionell näher an dem, was die meisten Leute erwarten, weniger Tippen für die am häufigsten verwendete Requisite) die Nachteile überwiegen (etwas mehr Tippen, um es abzufangen – in welchen Fällen Sie werden wahrscheinlich will ich sowieso nur den Spread-Operator).

Tatsächliche Nachteile:

• Das gesamte Ökosystem, das von className abhängt, funktioniert nicht mehr (großer Upgrade-Aufwand)
• die gesamte große Menge an Büchern, Tutorials, Beispielen, Codes, Posts und Artikeln wird so leicht ungültig
• Das einzige gültige verbleibende JS ist die zusätzliche Eingabe : const {class: cls} = props . Jeder andere mögliche Anwendungsfall in einfachem JS wird ungültig
• Die React-API bleibt inkonsistent und bricht weitere Annahmen (warum htmlFor nicht for usw.)

Wenn ich Produktmanager wäre, würde meine unmittelbare Reaktion auf die Änderung lauten: wat?

@gaearon Möglicherweise haben Sie dies bereits in Betracht gezogen, bitte markieren Sie PRs mit "React Fire" oder einem ähnlichen Schlüsselwort.

Issues sind normalerweise korrekt getaggt, PRs haben sie manchmal nicht. Dies hilft potenziellen Mitwirkenden.
Dies kommt von meiner Erfahrung, als ich versuchte, die Git-Historie durchzulesen und während der gesamten Fiber-Entwicklung nach Commits im Zusammenhang mit React Fiber und React Reconciler gesucht habe. Es hilft denen von uns, die versuchen, herauszufinden, was passiert, und zu sehen, ob wir in irgendeiner Weise dazu beitragen können.

Ich denke auch, dass die Umbenennung className in class einen so großen Migrationsaufwand und Probleme für neue Entwickler verursachen wird.
Das Attribut className ist so sichtbar und stark genutzt, dass es buchstäblich alle Bibliotheken zerstört, die sich auf React verlassen.
Und das ist nicht genug, die meisten Tutorials werden kaputt sein. Ein neues Gerät, das aus einem Artikel kopiert und einfügt, wird sich fragen: "Warum funktioniert das nicht, es heißt, className ist keine gültige Requisite".
Der Senior muss also helfen und wir haben nichts gewonnen, weil wir noch erklären müssen, warum es nicht so funktioniert, wie Sie es erwarten würden.
Und tatsächlich dauert die Erklärung, dass Sie className verwenden müssen, um Klassen für die Komponente zu definieren, weniger als eine Minute und ist leicht verständlich. Jedem Entwickler zu erklären, warum sie von className zu class gewechselt haben, dauert viel länger und führt zu mehr Frustration.

Alle Anstrengungen, die für ein einziges Wort erforderlich sind.
Es wird nichts an der Art und Weise ändern, wie sich die Reaktion verhält.
Es wird die Entwicklung von React-Dom nicht fördern.
Es wird die Produktivität von Entwicklern, die länger als eine Woche mit React arbeiten, nicht steigern.
Es wird einfach alles kaputt gehen.

Bitte denken Sie darüber nach, ist es das wirklich wert?

Ich benutze babel-plugin-react-html-attrs seit Jahren und es hat mir gute Dienste geleistet. Ich denke nicht, dass es eine gute Idee ist, className in class umzubenennen. Es wird besser durch ein Plugin wie das von mir erwähnte erreicht.

Gab es nicht ein Babel-Plugin , um die ganze „ class v className “ / „ for v htmlFor “-Situation zu handhaben?

Ich hoffe, dass es möglich ist, HTML-Attribute unverändert zu unterstützen und gleichzeitig die Abwärtskompatibilität mit den bereits getroffenen Namensentscheidungen aufrechtzuerhalten.

Die Tatsache, dass es bereits babel-Plugins gibt, um die Konvertierung durchzuführen, ist vielleicht ein Beweis dafür, dass es möglich sein sollte, sie im Core-JSX-Transpiler selbst zu unterstützen. Aber es zu einer offiziellen Spezifikation zu machen, würde die Dinge für alle so viel einfacher und zuverlässiger machen.

Mir sind React-Interna nicht bekannt, daher kann ich nicht viel über die tatsächliche Machbarkeit sagen. Nur um auszudrücken, wie ich denke, dass es in Bezug auf die Benutzerfreundlichkeit "sein sollte".

Bitte überdenken Sie className im Vergleich zu class . Wie oben gesagt wurde, ist der Gewinn fast nicht vorhanden, aber es gibt echte Nachteile.

Zum einen wäre die Verwendung von Haxe als Sprache zum Schreiben von React-Anwendungen für uns nicht nur eine bahnbrechende Änderung, sondern würde uns einfach daran hindern, _irgendeine_ React-Anwendung zu schreiben.

class ist ein reserviertes Schlüsselwort in den meisten Programmiersprachen, und wir konnten diese Requisite einfach nicht mehr manipulieren, was die React-Anwendung nahezu unmöglich machte (viel Glück beim Erstellen einer echten, ohne Klassen zu manipulieren). Dasselbe gilt leider für htmlFor vs. for (dieser ist wirklich hässlich, aber ich bin dankbar, dass es ihn gibt).

Übrigens, Suchbarkeit ... Stellen Sie sich vor, Sie googeln nach "React-Klasse", Sie erhalten gemischte Signale: React-Klassenkomponenten, React-Klassenattribute. Wenn Sie nach "React className" googeln, erhalten Sie veraltete Dokumentation (die oben erwähnten Personen haben die enorme Menge an Upgrade-Arbeit, die durch diese Änderung neben Code-Upgrades verursacht wird).

Ist das Ziel dieses Projekts, mehr Arbeit für die Community und mehr Lärm und gemischte Signale für das Internet zu generieren? Ich hoffe nicht.

Ja, das Web- und JavaScript-Ökosystem hat Mühe, die Rückwärtskompatibilität mit dummen Fehlern der Vergangenheit aufrechtzuerhalten, aber dieses Streben nach Rückwärtskompatibilität hat es ihm ermöglicht, ohne größere Fragmentierung zu einem solchen Ausmaß heranzuwachsen.

Ich verstehe, dass es ohne Veränderung keinen Fortschritt gibt, und ich selbst habe das Motto der frühen FB übernommen, Dinge zu zerbrechen, um schnell voranzukommen (und auch einen Plan zu haben, wie man sie im Voraus wieder zusammenbaut).

Wenn Sie so hartnäckig sind, dass diese Änderung wirklich notwendig ist, nennen Sie einfach den wahren Grund für die Änderung. Es kann nicht das "schwer zu lernende" Ding sein, klingt zu flach für das mächtige React Core-Team. Sie sollten auf jeden Fall etwas im Hinterkopf haben.

@sompylasar Ich suche normalerweise nach className= oder className:, scheint, als würden beide auch mit der Klasse funktionieren.

Außerdem viel Glück dabei, das direkt auf GitHub zu tun =/

Ich habe alle Kommentare hier gelesen. Ich bin mit Änderungen einverstanden, aber class bin ich mir nicht sicher. Der Hauptgrund ist, dass es mit Plänen für JSX 2.0 nicht funktioniert. über Abkürzungsnotation (wie wir sie jetzt in Objekten haben).
Alles andere scheint sehr schöne Verbesserungen zu sein.
Warten auf die endgültige Entscheidung :) Vielen Dank für Ihre erstaunlichen Bemühungen, Leute!

In einem Ihrer Kommentare erwähnten Sie „wenn es heute funktioniert, sollte es morgen funktionieren“. Denken Sie daran, bevor ich frage ;).

Ich unterhalte eine UI-Bibliothek namens RMWC https://jamesmfriedman.github.io/rmwc/ , die auf alle Versionen von React bis zurück zu 15.4 abzielt. Ich war in der Lage, eine einheitliche API-Oberfläche beizubehalten, aber die Änderung von className in class, onChange in onInput und die Überarbeitung des Ereignissystems wird es fast unmöglich machen, dies fortzusetzen.

Gibt es eine Möglichkeit für eine „kompatible“ Schicht, die einige dieser Dinge unter der Haube übersetzen kann? So kann ich in welcher Version auch immer reagieren Feuer schreiben, läuft aber in einer geringeren Laufzeit weiter.

Wenn nicht, gehe ich davon aus, dass mein seltsamer Code noch seltsamer wird. 👀

wenn className wirklich in class geändert werden muss, ändern Sie bitte auch htmlFor in for .
da class und for ursprünglich ungültig waren, als wir props destrukturierten.

Wenn React über eine eigene API verfügt, die viele Attributnamen normalisiert, um eine konsistente API zu erstellen, dann ist className sicherlich perfekt dafür geeignet. Ein zusätzliches idiomatisches Lernen zusätzlich zu den CamelCase-Idiomen und die Tatsache, dass es dem DOM-Eigenschaftsnamen zugeordnet ist (wie einige der anderen JSX-Attribute), ist sicherlich in Ordnung, im Vergleich dazu, es jedes Mal, wenn Sie es verwenden, als Sonderfall zu destrukturieren ein Requisitenobjekt mit darauf.

Ich habe das Gefühl, dass Sie bis jetzt viele lautstarke Meinungen gegen den Status quo gehört haben („Warum können wir keinen Unterricht haben?!“), während alle, die damit zufrieden waren, still blieben; im Einklang mit dem alten Sprichwort, dass Menschen viel eher negative Bewertungen abgeben als positive. Persönlich denke ich, dass eine winzige Lernkurve zusätzlich zu vielen anderen weitaus besser ist als ein spezielles Gehäuse, wenn diese Requisite jedes Mal auftaucht.

Ich denke, ich würde gerne ein bisschen mehr Demokratie drumherum sehen – ich denke, diese sehr spezifische Änderung kann von einem Komitee durchgeführt werden (es war im Wesentlichen ein Pseudo-Komitee, das Sie dazu gebracht hat, diese Änderung in Betracht zu ziehen) – und ich bin froh, dabei zu sein die Verliererseite. Nur damit es im Alltag die wenigsten Menschen betrifft.

Ps alles andere sieht übrigens super aus, besonders die Eventsachen 👌🏻

warten auf neue Updates

@gaearon Ist es eine Überlegung wert, dass Ihr eigenes Beispiel:

const { oneProp, twoProp, ...rest }  = this.props;

return (
  <div class={'something ' + rest.class} {...rest}/>
);

enthält einen Fehler und würde nicht so funktionieren, wie Sie es erwarten? Es ist möglicherweise nicht so einfach wie "Destrukturieren Sie es einfach nicht".

Bin ich der einzige, der nicht so besorgt darüber war, dass Klasse Klassenname ist? Wenn Sie mich fragen würden, welche Probleme React hatte, würde mir das nie in den Sinn kommen.

Trotzdem sind Updates Freebies und ich liebe Freebies.

Bin ich der einzige, der nicht so besorgt darüber war, dass Klasse Klassenname ist?

Um den Unterricht mache ich mir überhaupt keine Sorgen. Die subtilen Fehler mit IE11 werden lustiger (und ich bin trotzdem mehr als zufrieden mit diesen Änderungen)

Es wäre schön, wenn die Unterstützung von Passive Event Listeners im Rahmen von React Fire liegen würde, was eine wichtige Funktion auf Mobilgeräten ist. #6436

Ich stimme zu. Es ist definitiv im Rahmen dieser Arbeit.

Hey @gaearon - erstmal danke.

Haben Sie darüber nachgedacht, eine Umfrage durchzuführen, um Informationen darüber zu sammeln, wie Menschen React verwenden und welche APIs verwendet werden und was verwirrend ist?

Während React bei weitem mein Lieblings-Frontend-Entwicklungsstack ist, finde ich, dass es ein paar Fußwaffen gibt, wenn man es lernt und zum ersten Mal verwendet. Ich möchte nicht einfach darlegen, was die Leute, die ich unterrichtet habe, persönlich verwirrend fanden.

Ich habe festgestellt, dass es in Projekten nützlich ist, an denen ich persönlich beteiligt war (Node, Bluebird usw.).

In Bezug auf das, was ich persönlich gerne im Kern sehen würde: Ich würde gerne eine einfachere, nicht globale Abhängigkeitsinjektionsunterstützung, eine bessere und konsistentere Ereignisbehandlung (die Sie bereits besprechen) bevorzugen.

Haben Sie darüber nachgedacht, eine Umfrage durchzuführen, um Informationen darüber zu sammeln, wie Menschen reagieren > verwenden und welche APIs verwendet werden und was verwirrend ist?

Ich denke, React-Native hat ein canny.io, von dem ich nicht wusste, dass React es nicht tut

Ich unterhalte eine UI-Bibliothek namens RMWC https://jamesmfriedman.github.io/rmwc/ , die auf alle Versionen von React bis zurück zu 15.4 abzielt. Ich war in der Lage, eine einheitliche API-Oberfläche beizubehalten, aber die Änderung von className in class, onChange in onInput und die Überarbeitung des Ereignissystems wird es fast unmöglich machen, dies fortzusetzen.

Gibt es eine Möglichkeit für eine „kompatible“ Schicht, die einige dieser Dinge unter der Haube übersetzen kann? So kann ich in welcher Version auch immer reagieren Feuer schreiben, läuft aber in einer geringeren Laufzeit weiter.

Ich verstehe Ihre Bedenken (ich habe auch meinen fairen Anteil an Bibliotheken geschrieben). Da es jedoch so viele Kompromisse gibt, etwas zu ändern, tendieren wir dazu, uns zu bemühen, den Leuten beim Upgrade zu helfen, anstatt den Leuten zu helfen, mehrere Versionen zu unterstützen. Das bedeutet nicht, dass wir das überhaupt nicht tun (wir haben in 16.3 ein Polyfill für Bibliotheksautoren für Lebenszyklusänderungen veröffentlicht), aber dass wir nicht für diesen Anwendungsfall optimieren.

Mein Vorschlag ist, ein neues Hauptfach zu schneiden, wenn wir ein neues Hauptfach schneiden, wenn etwas nicht kompatibel ist. Benutzer können weiterhin alte Hauptversionen Ihrer Bibliothek verwenden, wenn sie möchten. Ich weiß, dass die Wartung aufwändiger ist, insbesondere wenn Sie es weiterentwickeln, aber es ist fraglich, ob eine einzelne hackige Codebasis besser ist als zwei voneinander abweichende, aber konsistente Codebasen.

@jamesmfriedman es sollte möglich (und nicht zu kompliziert) sein, (automatisch) mit einem Codemod auf die neue API zu aktualisieren und dann (als Teil des Build-Prozesses) (wieder mit einem Codemod) auf die alte API umzuwandeln. Versenden Sie dann beide Bundles und fordern Sie sie dynamisch basierend auf der React-Version an.

Das ist etwas Arbeit, aber es kann einmal gemacht werden (z. B. als Webpack-Plugin oder npm-Installationsskript?) Und sollte nicht schwer sein. Ich würde davon ausgehen, dass es so etwas ist, das einmal veröffentlicht und in allen Bibliotheken verwendet wird.

Wie eine Kompatibilitätsschicht zur Kompilierzeit speziell für Bibliotheken.

Ich unterstütze das Löschen von htmlFor for for.

Denken Sie, dass ein Bridge-Release, das sowohl className als auch class unterstützt, eine gute Idee wäre? Es würde Entwicklern ermöglichen, älteren React-Code von Drittanbietern zu verwenden, während ihr aktueller Erstanbieter-Code zukunftsweisend sein kann. Sobald der Drittanbieter aktualisiert hat, ist es so einfach wie das Löschen des Bridge-Pakets, um ein vollständig optimiertes React-DOM zu erhalten.

React API bleibt inkonsistent und bricht weitere Annahmen (warum htmlFor not for etc.)

Ich glaube, Sie haben den letzten Satz verpasst, als ich sagte, for sollte sich auch ändern. Dann denke ich, dass wir mit „Attributnamen in Kamelbuchstaben“ vollständig konsistent sein werden, mit Ausnahme von ein oder zwei seltenen SVG-Attributen. Was wir auch ändern können.

Gab es kein Babel-Plugin, um die ganze „class v className“ / „for v htmlFor“-Situation zu bewältigen?

Ich sehe einige Erwähnungen davon, also möchte ich das klarstellen. Ein Babel-Plug-In ist kein großartiger Ort, um diese Konvertierung durchzuführen, da es in Fällen wie diesem nicht funktioniert

const props = {
   class: "foo"
}
<div {...props} />

Es macht auch keinen Sinn, dass Sie class übergeben, aber className in Props der Komponente erhalten. Oder, wenn das Plugin nur auf Plattformelemente abzielt, wäre es seltsam, dass das Ersetzen button durch Button das ändert, was die class -Prop kompiliert.

Die Verwendung des Babel-Plugins dafür verschleiert nur die Semantik des Codes, den Sie schreiben, und führt zu mehr Verwirrung. Meiner Ansicht nach ist es eine schlechtere Lösung, als entweder nur className oder class zuzulassen.

Fun Fact: So funktionierte eine sehr alte Version des JSX-Compilers. Dieses Verhalten wurde entfernt, da es verwirrend ist.

Tolle Veränderungen. . .

Tolle! Vielen Dank an alle Mitwirkenden, die daran gearbeitet haben, so aufregende Updates zu bringen.
Ich hatte keine Ahnung, dass className > class so ein großer Skandal ist. Ich persönlich habe mich daran gewöhnt.

Reduzierte Paketgröße und verbessertes Ereignissystem klingen wirklich vielversprechend. Super begeistert!

Ich freue mich sehr darauf, die Polyfills des Event-Systems als separate Pakete zu trennen.
Aber egal, ob className > class zu radikal ist, React hat einen zu großen Einfluss.
Wird dies zum Unvorhergesehenen vieler Systeme führen?

Es wäre schön, ein Drittel von React DOM fallen zu lassen.

Es wird großartig sein, React bei der Entwicklung von Web-Apps zu verwenden.

Es wäre auch schön, Namespace-spezifische Requisiten wie key und ref zu reagieren. z.B

<Foo @key="foo" @ref={callback} prop="hi" />

Dies wurde hier diskutiert - https://github.com/facebook/jsx/issues/66

@elado Obwohl es etwas sein könnte, das wir in Zukunft tun möchten, denke ich, dass es außerhalb des Geltungsbereichs liegt, da es sich auf nicht DOM-spezifische API auswirkt.

Es ist zwar aufregend, aber vor allem die Reduzierung der Bündelgröße, die immer begrüßt wird. Meine Sorge ist, dass die Leute bei Facebook die Trägheit, den Schmerz und die Fragmentierung unterschätzen, die API-Änderungen für das Ökosystem und die Community verursachen können.

Es ist wahr, dass sie sich bei FB um eine große Anzahl von Komponenten kümmern müssen, aber der Vorteil, den sie haben, und ich nehme hier an, ist ihre minimale Abhängigkeit von externen Open-Source-Reaktionsbibliotheken, da sie höchstwahrscheinlich die meisten ihrer Komponenten intern erstellt haben. Für die anderen Leute, die viele Open-Source-Bibliotheken verwenden, hat es wirklich viel Mühe, Warten und Frustration gekostet, Proptypes aus vielen Bibliotheken herauszuholen (und ich spreche aus einer echten Erfahrung mit dem Upgrade einer großen React-Codebasis). Sich schnell zu bewegen und Dinge kaputt zu machen, ist möglicherweise nicht für Leute geeignet, die mit begrenzten Ressourcen ein stabiles Geschäft aufbauen möchten.

Ich genieße React wirklich, die API ist einfach und ich persönlich habe keine Zeit gebraucht, um sie zu lernen und mich an ihre Syntax anzupassen. Daher fordere ich den Betreuer wirklich dringend auf, die Vor- und Nachteile von bahnbrechenden Änderungen im gesamten Ökosystem sorgfältig abzuwägen und pragmatisch zu überlegen, ob die Änderung das gesamte Ökosystem zum Umschreiben zwingt.

Abgesehen davon schätze ich den Aufwand für den Aufbau, die Wartung und die Aktualisierung von React und die Leidenschaft der Ingenieure dahinter sehr :)

Diese zukünftigen {...Updates} sind 🔥

className -> class : Ich glaube nicht, dass es eine seltene Situation ist, wenn das Klassenattribut außerhalb der JSX/Objektdeklaration definiert wird. In solchen Situationen müssen wir unterschiedliche Benennungen für dasselbe verwenden, was zu Inkonsistenzen führt, die Codekomplexität erhöht und die kognitive Belastung erhöht.
Die vorgeschlagene Änderung wird die Nichtübereinstimmung von Attribut-/Requisitennamen nicht aus unseren Codebasen entfernen – sie wird irgendwo aufgrund der Syntaxbeschränkungen oder bei der Arbeit mit nativem DOM existieren. Es ist eine gute Sache, dass wir eine „standardisierte“ (und zu diesem Zeitpunkt gut etablierte) Problemumgehung für dieses Namensproblem haben.
Derzeit kann className überall konsistent verwendet werden und bezieht sich immer auf dasselbe - selbst wenn mit nativem DOM gearbeitet wird. Tatsächlich kann die Reaktion buchstäblich der einzige Ort sein, an dem wir gezwungen sind, class zu verwenden, um auf das Klassenattribut zu verweisen.
className erschien zunächst ziemlich unnötig und etwas verwirrend, stellte sich aber später als recht praktisch und relativ gewöhnungsbedürftig heraus.

Ich würde auch das zusätzliche Objekt { __html } für dangerouslySetInnerHTML loswerden, da es wirklich unnötig erscheint, aber die Probleme im Zusammenhang mit der Migration möglicherweise nicht wert sind (und vielleicht überhaupt nichts mit diesem Problem zu tun haben).

Während die anderen Änderungen viel weniger Emotionen hervorrufen, sind sie viel interessanter und wichtiger, also vielen Dank an das fb-Team für die Mühe.

Je mehr Breaking Changes vorhanden sind, desto länger dauert es, die eigentlichen Benutzeranwendungen zu aktualisieren. Persönlich bin ich schon ziemlich weit hinter dem neuesten besten React zurück (was mich traurig macht), weil frühere Versionen von React Sachen kaputt gemacht haben, die dann Bibliotheken erfordern, auf die ich angewiesen bin, um sie zu aktualisieren, was dann zu Verzögerungen führt.

Idealerweise möchte ich in dem Szenario sein, dass:

• Die nachgelagerte React-Bibliothek schreibt den Code in der neuen Version um und führt einen Fehler für meinen Anwendungsfall ein
• React fügt eine coole neue Funktion / Bundle-Reduzierung hinzu
• Die alte Bibliotheksversion bleibt auf dem neuen React verwendbar
• Yay, ich kann die neue Funktion direkt nach dem Start von React verwenden und einfach warten, bis die Bibliothek den Fehler behoben hat

In der Praxis ist es eher so:

• Die Bibliothek schreibt den Code um und führt einen Fehler ein
• React veröffentlicht neue Breaking Change
• Alte Bibliothek funktioniert nicht mehr
• Neue Bibliothek wird schließlich aktualisiert
• Fehler kann immer noch vorhanden sein
• Ich hänge eher an veraltetem React als (um Ken Wheeler zu zitieren) "the new hotness" fest.
• Ich bin traurig :(

Aus Sicht des „Versandcodes“ wird jedes größere Breaking-Upgrade zu einer riesigen lästigen technischen Schuld, bei der alle Abhängigkeiten aktualisiert, alles erneut getestet und dann nach neuen Fehlern gesucht werden muss, um zu sehen, ob es eine Problemumgehung gibt. Sofern es keine kritische Schwachstelle gibt oder es wirklich unpraktisch ist, etwas zu tun (und diese Messlatte ist hoch), wird es depriorisiert.

Obwohl React sein 0.x-Paradigma abgelegt hat und trotz des Versuchs, eine zentrale Webbibliothek zu sein, gibt es leider immer noch Versionsnummern, was bedeutet, dass viel Zeit damit verbracht wird, still zu stehen.

Grundsätzlich sage ich, bitte, bitte versuchen Sie, eine API zu planen, die es ermöglicht, dass zukünftige große Änderungen nicht kaputt gehen.

(Auch die IE11-Sache ist traurig, weil Sie einen Browser ablehnen, der nicht EOL ist – letzte Version vor 52 Tagen. Ich denke, das React-Team wird feststellen, dass dies nur die Arbeit an das Facebook-Team und alle externen und internen Bibliotheksteams verschiebt, um es zu mildern stattdessen).

@urugator

Ich würde auch das zusätzliche Objekt { __html } für DangerlySetInnerHTML entfernen, da es wirklich unnötig erscheint

Dies ist absichtlich so gestaltet, dass es explizit und schwer versehentlich zu verwenden ist. Wenn es entfernt wird, können alle nicht bereinigten Daten versehentlich an DangerlySetInnerHTML weitergegeben werden.

@philipwhiuk

Grundsätzlich sage ich, bitte, bitte versuchen Sie, eine API zu planen, die es ermöglicht, dass zukünftige große Änderungen nicht kaputt gehen.

Breaking Changes sind notwendig, um die Technologie zu verbessern, und React tut dies verantwortungsbewusst mit seltenen Batches von Breaking Changes. Ohne bahnbrechende Änderungen wie das Entfernen von „componentWillReceieveProps“ hätten wir keine großartigen Dinge wie „React Suspense“, und Software in der Community wäre schwieriger zu warten, da alte APIs für immer bestehen bleiben. Wenn Sie jeweils eine Hauptversion aktualisieren, sollte es Ihnen gut gehen.

Auch die IE11-Sache ist traurig, weil Sie einen Browser ablehnen, der nicht EOL ist - letzte Version vor 52 Tagen.

Niemand lehnt IE 11 ab. Die aktuelle Version von React erfordert tatsächlich Polyfills für einige Funktionen in IE 11, sodass die vorgeschlagenen Änderungen wahrscheinlich ungefähr die gleiche Auswirkung auf die Entwicklung von IE 11 haben würden. https://reactjs.org/docs/javascript-environment-requirements.html

Ich würde auch das zusätzliche Objekt { __html } für DangerlySetInnerHTML entfernen, da es wirklich unnötig erscheint

@urugator - Für das, was es wert ist, besteht die intern bei Facebook häufigste Verwendung von __html darin, vom Server gerendertes HTML in einen React-Komponentenbaum einzufügen. Für diesen Anwendungsfall konstruieren wir die __html -Objekte serverseitig und haben Lint-Regeln, die dagegen sprechen, dies clientseitig zu tun. Serverseitig haben wir Methoden, die XHP in Objekte mit __html -Eigenschaften serialisieren. Das stellt sicher, dass wir nirgendwo Sicherheitslücken einführen, da XHP JSX sehr ähnlich ist (es war eigentlich die Hauptinspiration für JSX) und auch über XSS-Schutz verfügt.

Im Wesentlichen markieren die __html -Objekte eine HTML-Zeichenfolge, von der wir wissen , dass sie irgendwo bereinigt wurde und sicher direkt in das DOM eingefügt werden kann. Ein roher String ist schwieriger zu handhaben - Wie können Sie feststellen, ob er bereinigt wurde oder ob jemand versehentlich einige rohe Benutzereingaben zurückgegeben hat (und somit eine XSS-Lücke eingeführt hat)?

Also ja, es ist absichtlich schwierig zu verwenden, da es in den meisten Apps nicht viele Anwendungsfälle geben sollte und die Anwendungsfälle angemessen begrenzt sein sollten. Im Allgemeinen sollten Sie das __html -Objekt nicht direkt in Ihrer React-Komponente erstellen, sondern Sie sollten eine Funktion haben, die es zurückgibt (sehen Sie, wie die Dokumentation eine createMarkup -Funktion verwendet: https://reactjs. org/docs/dom-elements.html#dangerouslysetinnerhtml)

Meine Sorge ist, dass die Leute bei Facebook die Trägheit, den Schmerz und die Fragmentierung unterschätzen, die API-Änderungen für das Ökosystem und die Community verursachen können.

Danke, dass du das angesprochen hast. Ich verstehe vollkommen, woher du kommst. Aber ich möchte darauf hinweisen, dass die Mehrheit der Leute im React-Team React selbst außerhalb von Facebook verwendet hat, bevor sie eingestellt wurden – oft für große Anwendungen. Ich denke, das hilft uns, uns in die Art von Problemen einzufühlen, die unsere Open-Source-Benutzer betreffen. Ich benutze React seit zwei Jahren und erinnere mich sehr gut an die Fragmentierung, die zB durch den Kontextwechsel zwischen Eltern und Eigentümern verursacht wurde. Der Schlüssel war eine gute Migrationsstrategie – und das Gleiche gilt für alle oben genannten Änderungen.

Es ist wahr, dass sie sich bei FB um eine große Anzahl von Komponenten kümmern müssen, aber der Vorteil, den sie haben, und ich nehme hier an, ist ihre minimale Abhängigkeit von externen Open-Source-Reaktionsbibliotheken, da sie höchstwahrscheinlich die meisten ihrer Komponenten intern erstellt haben.

Dies gilt seit jeher für die Produktseite der Entwicklung. Seit Yarn erstellt und in unser Web-Repository integriert wurde, haben wir jedoch eine zunehmende Anzahl von Komponenten von Drittanbietern gesehen, die auf internen Toolseiten verwendet werden – die selbst eine viel größere Oberfläche haben als Facebook-Verbraucherprodukte. Wir brauchen also auch eine Strategie für die schrittweise Migration in Drittanbieterpaketen.

Im Gegensatz zu vielen anderen Unternehmen verwenden wir dieselbe Version von React für die gesamte Codebasis. Wir haben also auch einzigartige Herausforderungen (z. B. können wir nicht einfach mit dem Upgrade einiger Produkte "warten"). Dies wird sicherlich den Druck auf uns erhöhen, eine gute Migrationsstrategie zu haben, und als Stresstest dienen.

Für die anderen Leute, die viele Open-Source-Bibliotheken verwenden, hat es wirklich viel Mühe, Warten und Frustration gekostet, Proptypes aus vielen Bibliotheken herauszuholen (und ich spreche aus einer echten Erfahrung mit dem Upgrade einer großen React-Codebasis). Sich schnell zu bewegen und Dinge kaputt zu machen, ist möglicherweise nicht für Leute geeignet, die mit begrenzten Ressourcen ein stabiles Geschäft aufbauen möchten.

Falls Sie neugierig sind, wir haben immer noch Code wie

React.PropTypes = require('prop-types')
React.createClass = require('create-react-class')

in unserer Codebasis, weil wir es uns auch nicht leisten können, vollständig auf eine "saubere Weste" zu migrieren. Aber Leute, die heute mit React beginnen, sowie modernere Teile unserer Codebasis, müssen dieses Gewicht nicht tragen. So ungefähr denken wir darüber – wir wollen bessere Standardeinstellungen für neue React-Benutzer wählen, aber eine gute Migrationsgeschichte für uns und alle anderen haben, auch wenn einige Teile davon hacky sein könnten.

Ich habe dies möglicherweise nicht klar genug kommuniziert, daher entschuldige ich mich. Jede große Änderung erfordert eine ausgefeilte und gut ausgeführte Migrationsstrategie, die berücksichtigt, dass die Aktualisierung von Bibliotheken von Drittanbietern lange dauert, verschiedene Versionen möglicherweise koexistieren müssen usw. Zum Beispiel mit class the Plan ist nicht, es einfach über Nacht zu ändern. Wenn wir es tun wollen, sollten wir klug vorgehen, wie wir es einführen – möglicherweise mit einer Nachfrist, in der wir beides zulassen, oder einem Helfer, um es einfacher zu machen, und dann den alten Namen schrittweise auslaufen zu lassen . Ich habe noch keine konkrete Strategie, aber es ist klar, dass die Veränderung ohne eine gute Strategie einfach nicht machbar ist – sowohl für uns als auch für Sie. Das nehmen wir sehr ernst.

(Auch die IE11-Sache ist traurig, weil Sie einen Browser ablehnen, der nicht EOL ist – letzte Version vor 52 Tagen. Ich denke, das React-Team wird feststellen, dass dies nur die Arbeit an das Facebook-Team und alle externen und internen Bibliotheksteams verschiebt, um es zu mildern stattdessen).

Ich verstehe nicht, worauf Sie sich beziehen. Ich habe nirgendwo gesagt, dass IE11 "veraltet" wurde.

Mein Beitrag sagt nur, dass wir für Browser wie IE11 möglicherweise mehr Polyfills als jetzt benötigen. React erfordert bereits einige Polyfills in IE11. Ich sage nicht, dass wir es kaputt machen wollen – es hat immer noch viele Benutzer – aber dass Sie mehr Polyfills einfügen müssen, wenn Sie möchten, dass es funktioniert. Das erscheint mir absolut fair.

Außerdem können wir die Arbeit nicht an andere Teams bei Facebook weitergeben. Wenn wir etwas kaputt machen, liegt es an uns, es zu reparieren. Aus diesem Grund kümmern wir uns so sehr um Migrationsstrategien – wir müssen sie normalerweise selbst ausführen.

Betreff: Der Rest Ihres Kommentars – wir nehmen absolut keine Breaking Changes um der Sache willen vor. Tatsächlich versuchen wir sehr, sehr hart, Breaking Changes zu vermeiden. Es gibt viele Teile von React, die kompliziert und schwer zu warten sind, aber wir behalten sie aus dem einzigen Grund bei, weil wir versuchen, ältere APIs zu unterstützen, selbst wenn sie ausdrücklich als instabil gekennzeichnet wurden. Irgendwann sammelt sich jedoch das Gewicht der Probleme an, und wir müssen den Tisch räumen, um voranzukommen und sie zu beheben. Die Probleme in meinem OP-Beitrag sind genau diese Art von Problemen. Sie wären es nicht wert, alleine eine Breaking Change durchzuführen. Aber zusammen denken wir, dass sie die Mühe wert sind.

Ich verstehe nicht, warum die Leute dem so negativ gegenüberstehen. Aktualisieren Sie einfach nicht, bis Ihre Abhängigkeiten dies tun?

Ist das Schlüsselwortproblem für class vs. className und for vs. htmlFor nicht etwas, mit dem der jsx-Compiler umgehen kann, um die reservierten Wörter zu überschreiben?

Ich wäre wirklich nur besorgt, wenn die Änderungen groß genug sind, dass die Suchergebnisse veraltete Antworten liefern ... Wie der Schmerz Winkel 2+, der beim Googeln nach "Angular -Angularjs -Angular1.x" usw. eingeführt wurde

Ansonsten begrüße ich alle Änderungen!!!

@gaearon

Du sagtest

"Möglicherweise müssen wir die Kompatibilität mit einigen älteren Browsern einstellen"

Es war der Drop-Kompatibilitätsteil, mit dem ich ein Problem hatte, nicht der folgende Polyfill-Teil. Meine Sorge war, in die dunklen Zeiten zurückzukehren.

Apropos Ablauf. Ist diese Art von "Problem" nicht das, wofür der RFC-Prozess entwickelt wurde?

Es war der Drop-Kompatibilitätsteil, mit dem ich ein Problem hatte, nicht der folgende Polyfill-Teil. Meine Sorge war, in die dunklen Zeiten zurückzukehren.

Ich sprach über IE10 und früher. Ich habe ausdrücklich darauf hingewiesen, dass wir IE11 weiterhin unterstützen wollen – ich denke, es macht etwa 3 % unseres Datenverkehrs aus, was viel mehr ist als die 1 %-Grenze, bei der wir es für zu alt halten.

Apropos Ablauf. Ist diese Art von "Problem" nicht das, wofür der RFC-Prozess entwickelt wurde?

Wir werden RFCs posten, wenn die Dinge konkreter sind. Vieles davon erfordert Erkundung, Experimente und tatsächliche Tests, um festzustellen, was wir tun können und was nicht und welche Migrationsstrategien wir verwenden könnten. Wir haben im Moment nicht genug Details, um überhaupt über RFCs nachzudenken (die eine umfassende Migrationsstrategie beinhalten sollten).

Ok danke für die Klarstellung!

@gaearon

Es ist plausibel, dass wir synthetische Ereignisse ganz abschaffen werden.

Wie würde das funktionieren, wenn event.currentTarget auf das Element zeigt, an das der Ereignis-Listener angehängt ist, was im nativen Fall immer document bedeutet - oder die React-Root, sobald React dorthin wechselt?

Reagieren ist nicht nur das Festlegen von Eigenschaften

(...)

Mein Punkt hier ist, dass es ein Implementierungsdetail ist, ob React intern Eigenschaften oder Attribute verwendet

Warum ist dies ein Implementierungsdetail, wenn es beeinflussen kann, was im DOM passiert? Es sei denn, das bezog sich nur auf Eigenschaften, die sich irgendwie in Attributen (und zurück) widerspiegeln, wie class / className .

Ich habe das Gefühl, dass die Verwirrung um die Behandlung von class / className damit zusammenhängt, dass es als Implementierungsdetail betrachtet wird, ob React eine Eigenschaft oder ein Attribut verwendet. Ich habe einen Angular-Hintergrund und als ich anfing, React zu verwenden, war dies das größte Problem für mich - in Angular ist die Trennung zwischen Attributen, Eigenschaften und Event-Handlern direkt aus der Syntax klar und ich war verwirrt, ob Props auf DOM-Elementen von React as gesetzt werden Eigenschaften oder Attribute.

Wie würde das funktionieren, wenn event.currentTarget auf das Element zeigt, an das der Ereignis-Listener angehängt ist, was im nativen Fall immer Dokument bedeutet - oder die React-Root, sobald React zu diesem wechselt?

Ich weiß es noch nicht. :-) Wir werden sehen, was wir tun können. Es ist durchaus möglich, dass einige dieser Dinge nicht funktionieren oder anders ausfallen. Dieser Plan ist nur ein grober Überblick über die Dinge, die wir untersuchen wollen, und die vereinheitlichende Vision für sie.

Warum ist dies ein Implementierungsdetail, wenn es beeinflussen kann, was im DOM passiert? Es sei denn, das bezog sich nur auf Eigenschaften, die sich irgendwie in Attributen (und zurück) wie class/className widerspiegeln.

Für die meisten von ihnen gibt es aus der Sicht des Benutzers keinen erkennbaren Unterschied, welcher zu verwenden ist. Ich denke, die meisten von ihnen werden reflektiert (obwohl ich mich vielleicht irre).

Ich habe einen Angular-Hintergrund und als ich anfing, React zu verwenden, war es das größte Problem für mich - in Angular ist die Trennung zwischen Attributen, Eigenschaften und Event-Handlern direkt aus der Syntax klar und ich war verwirrt, ob Requisiten auf DOM-Elementen von React als Eigenschaften festgelegt werden oder Attribute.

Ich schätze Ihre Perspektive. In der Praxis ist dieser Unterschied für die meisten DOM-Elemente jedoch oft irrelevant und es ist fraglich, ob es für die tägliche Produktentwicklung tatsächlich wertvoll ist , sich darüber zu informieren, welches man verwendet und immer wieder darüber nachdenken muss. Ich denke, das Ausmaß, in dem die Leute sie verwirren, spricht dafür, dass es für sie eigentlich nicht so relevant ist.

(Es gibt Fälle, in denen es viel relevanter wird, z. B. bei benutzerdefinierten Elementen. Aber selbst dort ist es genauso verwirrend, beide gleichermaßen zu unterstützen, weil Sie auswählen müssen, welches verwendet werden soll. Dies wurde an anderer Stelle diskutiert, daher möchte ich einen Sprung vermeiden wieder in diese Debatte – wir haben Vorschläge von Leuten wie @robdodson und wir werden sie prüfen.)

@Daniel15
Ohne die erwähnten Richtlinien (die meiner Meinung nach nirgendwo anders erwähnt werden) macht der zusätzliche Objekt-Wrapper es in keiner Weise sicherer.
Ich glaube, der Benutzer wird über dangerouslySetInnerHTML ausreichend vor der gefährlichen Verwendung gewarnt. Das ist der Punkt, an dem der Benutzer gezwungen ist, die Dokumente zu überprüfen, die Auswirkungen zu berücksichtigen und die Entscheidung zu treffen.
Die Notwendigkeit, den (möglicherweise nicht bereinigten) String in ein Objekt/eine Funktion zu packen, wird ihn nicht dazu bringen, den umschlossenen Wert zu überdenken oder zu säubern.
Wenn es so funktionieren würde, dann wäre { __html } vielleicht nicht kompliziert genug und [{ _html: { __html }] würde es noch sicherer machen - wie oft müssen wir sagen, dass etwas gefährlich ist, um es sicher zu machen ?

Mit den von Ihnen bereitgestellten Erkenntnissen verstehe ich die Argumentation, aber ich denke, sie gilt derzeit für niemanden außerhalb von Facebook, da wir keine Ahnung von der Regel „ { __html } repräsentiert bereinigtes HTML“ haben.
Ich dachte immer, es ist nur ein weiteres Hindernis in der API. Vielen Dank, dass Sie sich die Zeit genommen und etwas Licht ins Dunkel gebracht haben, jetzt macht es mehr Sinn.

Es geht nicht nur darum, es komplexer zu machen, sondern auch darum, zu verhindern, dass nicht bereinigte Daten versehentlich verwendet werden.

Ich liebe es einfach, wie die Community so eigensinnig reagiert. Kudos für euch, das alles zu hören und das Beste daraus zu machen.

Ich finde es toll, wie jeder denkt, dass die Änderungen, die hier kommen oder in den letzten Versionen zu React kamen, „brechend“ waren. Diese Leute haben Angular eindeutig nicht 2 > 3 > 4 Mal erlebt.

Ich liebe die Veränderungen. Ich persönlich habe nichts gegen className und die Destrukturierung class könnte zu einem Ärger werden. Aber ich würde gerne sehen, was euch einfällt.

Ich möchte darum bitten, diese Diskussion beim Thema zu halten. Ob Sie gefährliches HTML hilfreich finden oder nicht, ist interessant, hat aber nichts mit dem Problem zu tun.

Ich liebe React

Dies ist eine perfekte Gelegenheit, neuen Entwicklern zu helfen, sich willkommener zu fühlen. Ich bin sehr froh, dass dies geschieht.

Nur Leute die Klasse benutzen zu lassen hat keine negativen Auswirkungen, außer dass es nicht mit der Destrukturierung und den Migrationskosten funktioniert.

@gaearon Wirf 2c ein, aber diese beiden Negative scheinen genauso groß oder größer zu sein als das aktuelle Negativ (ein einmaliger geringer Preis für das Erlernen der Klasse => className vs. immer Vermeidung von Destrukturierung + Migrationskosten auf Ökosystemebene).

Reagiere :herz:

Echo von @natew oben:

@gaearon Wirf 2c ein, aber diese beiden Negative scheinen genauso groß oder größer zu sein als das aktuelle Negativ (ein einmaliger geringer Preis für das Erlernen der Klasse => className vs. immer Vermeidung von Destrukturierung + Migrationskosten auf Ökosystemebene).

Wie auch immer, was ist die Motivation hinter dem Wechsel von className zu class ?
Soweit ich das nachvollziehen kann, läuft Ihr Kommentar auf zwei Argumente hinaus (bitte korrigieren Sie mich, wenn ich falsch liege):

konzeptionell näher an dem, was die meisten Leute erwarten

Ok, aber das Hinzufügen Name ist die kleinste Hürde. Das Erlernen der Verwendung className war der einfachste Teil beim Erlernen von React. Es ist eine kleine Eigenart, die keine Nachteile hat - tatsächlich löst sie ein Problem mit vier Zeichen. Und es hat viel weniger kognitiven Overhead als jede der bereitgestellten Destrukturierungsalternativen.
Stellen Sie sich vor, jemandem beizubringen, wie er seine erste React-Komponente stylen kann

function Button({ color, ...rest }) {
  const buttonClass = rest.class +  ' Button-' + color;
  return <button {...rest} class={buttonClass} />
}

Mein Noob-Kopf wäre explodiert.
Ich denke, dass die Leute bei der Interaktion mit einer API erwarten, dass die API Lösungen bereitstellt. ClassName ist eine integrierte Lösung. Klasse ist ein eingebautes Problem.

weniger tippen

Bruh, es sind vier Zeichen 8^) . Abgesehen davon, selbst wenn wir class viel seltener destrukturieren, als wir derzeit className verwenden, ist es viel mehr Tipparbeit, wenn wir dies tun. Ich habe also 12 Mal 4 Zeichen weniger eingegeben, aber jedes Mal 50 weitere Zeichen hinzugefügt, wenn ich class destrukturiere? Das ist einfach albern.

Gibt es einen anderen zwingenden Grund für diese Änderung, die ich übersehen habe?
Ist die Motivation eine Art Besorgnis über die Konformität mit DOM-Attributen/Eigenschaften?
Das scheint mir ein viel zu akademisches Argument zu sein. Die meisten Menschen sind sich dieser Implementierungsdetails nicht sehr bewusst und ich denke nicht, dass sie es sein müssen.

Ist es, dass React, wenn es heute veröffentlicht wird, class erlauben würde, anstatt zu className zu wechseln?
Ich denke, das ist irrelevant.
React war heute nicht quelloffen, und wenn es in einem Jahr in der Zukunft quelloffen wäre / wäre, könnten zu diesem Zeitpunkt andere Entscheidungen getroffen werden.
Manchmal ist es besser, sich an die Konsistenz zu halten, als zu versuchen, jede Falte auszubügeln.

Und wenn React von Anfang an die Klasse verwendet hätte, hätten wir uns daran gewöhnt, die Klasse zu destrukturieren und Klassenname neu zuzuweisen, aber wer auch immer mit einem PR für die Änderung von Klasse _in_ Klassenname auftauchte, würde als Retter gefeiert werden.

Abschließend möchte ich nur sagen, dass ich nicht erwartet hatte, mich darüber so aufzuregen, also entschuldige ich mich, wenn etwas unhöflich, beleidigend oder anklagend rüberkam. Ich bin dankbar für all die Arbeit, die Sie bei React leisten, und für all das Wissen, das Sie auf Twitter hinterlassen – ich habe Ihre Tweets verwendet, um einige Antworten zu verteidigen, die ich in Interviews gegeben habe.

Ich bete zu dan.church , dass Sie Ihre Meinung ändern.

Ich freue mich sehr, dass React kontinuierlich erweitert werden kann. Als Entwickler von React möchte ich nicht, dass es von Vue überholt wird. Aber der Prozess von Klassenname -> Klasse muss schmerzhaft sein.

Ich bin nicht gegen die className -> class Umbenennung zum Kopieren und Einfügen, aber es gibt bis jetzt keine klare Motivation dafür. className existiert im DOM, während es reservierte Prop-Namen gibt, die wie htmlFor aus dem Nichts kommen. Ich bin der Meinung, dass diese bei der Umbenennung priorisiert werden sollten, und das ist wahrscheinlich eine weniger durchdringende Änderung, die auch als Test dienen kann.

@sonhanguyen htmlFor ist auch der offizielle Name der Web-API: https://developer.mozilla.org/en-US/docs/Web/API/HTMLLabelElement/htmlFor

@allan2coder anstatt es in ein Array zu packen, packen Sie es in <React.Fragment> oder <> .

@allan2coder Lassen Sie uns bitte auch diesen Thread beim Thema halten, Sie können Fragen stellen, indem Sie ein separates Problem einreichen, wenn Sie möchten.

Ich möchte die Aufmerksamkeit auf patch-package lenken, ein Paket, das es ziemlich einfach macht, Ihre Abhängigkeiten zu patchen (z. B. um sie davon abzuhalten, nicht unterstützte React-APIs zu verwenden). Zugegebenermaßen ist dies für Anwendungscode nützlicher als für Bibliothekscode, aber ich denke, es sollte dazu beitragen, einige der Bedenken von @philipwhiuk auszuräumen.

Ich freue mich auf.

• Migrieren Sie von onChange zu onInput und füllen Sie es nicht für unkontrollierte Komponenten.

Für die obigen Worte bin ich neugierig, ob das onChange-Ereignis in der Nähe des nativen Ereignisses verwendet oder in Zukunft nicht verwendet wird?

@MuYunyun

Basierend auf dem Wortlaut planen sie nicht, das aktuelle Verhalten von onChange beizubehalten. Es würde nicht viel Sinn machen. Reagiere wie andere moderne Libs wird keine Browserkompatibilitätsschicht sein und sollte es auch nicht sein.

Das aktuelle onChange emuliert onput + einige andere Fälle. Es macht überhaupt keinen Sinn, wenn man bedenkt, dass ein Änderungsereignis bereits im DOM vorhanden ist und nicht dieselbe Semantik hat: https://developer.mozilla.org/en-US/docs/Web/Events/change

@jxub

Ein bisschen offtop, aber es ist irgendwie traurig, dass niemand (soweit ich weiß) auf die Idee gekommen ist, einen html/css/svg -> jsx-Transfomer zu erstellen, um die Migrationen zu React mit so vielen trivialen Änderungen zu erleichtern, um HTML-Attribute zuzuordnen Requisiten reagieren. So viele Arbeitsstunden verschwendet, hauptsächlich Suchen und Ersetzen :(

Ich weiß nichts über andere Editoren, aber IntelliJ IDEA (und WebStorm, PhpStorm usw.) führt diese Transformation durch, wenn Sie einen HTML-Code in JS einfügen.

Ein bisschen offtop, aber es ist irgendwie traurig, dass niemand (soweit ich weiß) auf die Idee gekommen ist, einen html/css/svg -> jsx-Transfomer zu erstellen, um die Migrationen zu React mit so vielen trivialen Änderungen zu erleichtern, um HTML-Attribute zuzuordnen Requisiten reagieren. So viele Arbeitsstunden verschwendet, hauptsächlich Suchen und Ersetzen :(

Es existiert tatsächlich, ist aber ziemlich alt und nicht ganz korrekt: https://magic.reactjs.net/htmltojsx.htm

Wir sollten diese Bemühungen wiederbeleben. Wenn Sie helfen möchten, tun Sie dies bitte: https://github.com/reactjs/reactjs.org/issues/484. Bisher hat niemand seine Hilfe angeboten und nachgefragt.

Es existiert tatsächlich, ist aber ziemlich alt und nicht ganz korrekt: https://magic.reactjs.net/htmltojsx.htm

Ich habe dies schon unzählige Male verwendet - es wird sehr häufig verwendet, wenn bestimmte Komponenten an Leute ausgelagert werden, die HTML/CSS, aber kein JavaScript kennen.

Geben Sie also nur Feedback, dass dies ein nützliches Werkzeug ist, das die Leute in der Praxis verwenden. Es gibt auch andere Konverter online.

Ein Problem bei diesem Ansatz ist, dass es nur in eine Richtung geht (nur migrieren _to_ reagieren). Dieses Problem ist jedoch nicht speziell für React.

Hoffe es macht vieles einfacher...

Ein Problem bei diesem Ansatz ist, dass es nur in eine Richtung geht (nur migrieren, um zu reagieren). Dieses Problem ist jedoch nicht speziell für React.

Warum? Umgekehrt sollte es noch einfacher sein – führen Sie einfach ReactDOMServer.renderToString aus.

Warte geduldig auf die Freigabe

@gaearon

Warum? Umgekehrt sollte es noch einfacher sein – führen Sie einfach ReactDOMServer.renderToString aus.

Ok, für den Kontext ist das besprochene Problem: Ich möchte, dass Leute, die HTML/CSS schreiben und JavaScript nicht gut genug kennen, um am JS-Code zu arbeiten, an Markup/Stil/Layout von Komponenten arbeiten können.

Eine Möglichkeit, dies jetzt zu tun, besteht darin, sie es in HTML/CSS entwickeln zu lassen und htmltojsx zu verwenden. Das funktioniert ziemlich gut für mich.

Das Problem ist, dass ich jetzt jede Markup-/Stil-/Layout-Änderung selbst in React pflegen muss.

Wenn ich ReactDOMServer.renderToString aufrufe, würde ich tatsächlich statisches HTML erhalten, aber diesem HTML würde der gesamte eigentliche Komponentencode fehlen, sodass es nicht möglich ist, es Benutzern der Benutzeroberfläche zu geben und ihre Ausgabe zu verwenden, da ich alles neu schreiben müsste meine logik.

Dinge wie React-Sketchapp sind eine nette mögliche Lösung für das Problem, aber ich würde auf einen allgemeineren Ansatz hoffen, der es mir ermöglicht, dies zu tun, während ich normales HTML/CSS verwende. Zum Beispiel - durch irgendeine Form von Metadaten und das Beibehalten von Reaktions-IDs für Elemente.

Ich verstehe absolut, dass dies nicht im Bereich des ReactDOM-Kerns liegt, aber es ist definitiv in seiner Domäne und ein interessantes Problem.

Dies hat keine hohe Priorität - ich wollte hauptsächlich nur erklären, warum htmltojsx für einige von uns auch außerhalb des Kontexts einer Migration nützlich ist :)

Ich möchte, dass Leute, die HTML/CSS schreiben und JavaScript nicht gut genug kennen, um am JS-Code zu arbeiten, an Markup/Stil/Layout von Komponenten arbeiten können.

Wie groß ist das Problem und wie schwer wäre es, ihnen ein wenig JSX beizubringen? Die Änderungen müssen sowieso von einem React-versierten Techniker überprüft werden.

Tut mir leid, wenn dies zu sehr vom Thema abweicht, aber ich glaube, dass HTML/CSS heutzutage nicht mehr ausreicht.

( @gaearon kann dies gerne ausblenden, wenn es laut wird, da es sich um eine Antwort auf den obigen bereits geringfügigen OT-Kommentar handelt.)

Wie groß ist das Problem und wie schwer wäre es, ihnen ein wenig JSX beizubringen? Die Änderungen müssen sowieso von einem React-versierten Techniker überprüft werden.

Nun, es würde Folgendes erfordern:

• Arbeiten Sie nur mit Auftragnehmern zusammen, die mit Ihrem aktuellen React-Stack vertraut sind. Es ist viel schwieriger, Leute zu finden, die gestylte Komponenten lernen
• Installieren Sie Node (npm), Ihren Stack (React, Webpack usw.) und alles andere, was zum Ausführen des Projekts auf jedem Computer der UI-Mitarbeiter erforderlich ist, und halten Sie es auf dem neuesten Stand.
• Bringen Sie ihnen etwas grundlegendes Programmieren und JavaScript bei und lernen Sie, wie man mit den Devtools, Konsolenfehlern usw. arbeitet.
• Bringen Sie ihnen React bei, was seine Syntax ist, Dinge wie className , was key bedeutet usw.
• Arbeiten Sie nur mit Auftragnehmern und Freiberuflern zusammen, die bereit sind, auf diese Weise zu arbeiten, anstatt HTML/CSS zu produzieren. Das macht die Sache meist auch teurer.

Nun, wie oben erwähnt, sind Dinge wie „react-skeptchapp“ ein nützlicher Weg, um dies für UI-Leute zugänglicher und einfacher zu machen – aber es erfordert immer noch, dass sie viel lernen.

Ich verstehe vollkommen, warum Sie das fragen, und ich bin mir nicht sicher, ob dies ein häufiges Problem ist (ich vermute es). Unabhängig davon denke ich nicht, dass es für die Zukunft des Kerns von ReactDOM in Frage kommt.

Das ist ziemlich off-topic :-) Lassen Sie uns diese Diskussion auf Twitter oder woanders fortsetzen.

"Das Verhalten, für das ein Tool verwendet wird, ist ein Verhalten, das das Tool fördert"
~ Gary Bernhardt

Die Art und Weise, wie React verwendet wird, da die meisten davon nicht Teil der API von React sind, führt zu einer großen Anzahl von Fallstricken, die zu Diskussionen wie dieser führen, bei denen alle verwirrt und frustriert sind. Ist die Verwendung eines reservierten Schlüsselworts wie class aufgrund von Javascript, HTML oder der Reaktion selbst schlecht?

Zurück zu den Änderungen in 16.3 (wenn ich mich richtig erinnere) würde sich die Bibliothek jetzt anders verhalten, indem sie jedes Attribut akzeptiert, das an native HTML-Elemente übergeben wird, die vom vdom gerendert werden. Ich erinnere mich ziemlich genau, dass der größte Teil meiner Codebasis jetzt von Fehlern geplagt war weil des Verhaltens, das wir bei der Umsetzung dieses eindeutig schlechten Musters hatten

<div {...this.props} />

Ich muss also sagen, dass ich ziemlich enttäuscht bin, dass Dan vorschlägt, dass wir diesen schrecklichen Code weiterhin über alle Codebasen verbreiten.

Zunächst einmal gibt es keine Garantien für den Inhalt von props , aber native HTML-Elemente werden beim ersten Mal fast immer nicht das tun, was von ihnen erwartet wird, wenn Sie ihnen jedoch gleichzeitig die falschen Props übergeben Es wird als sicher angesehen, übergeordnete Requisiten an untergeordnete Komponenten weiterzugeben, aber in Wirklichkeit ist dies schrecklich faul

<Child {...props} />

const Child = (props) => <div {...props} />

Manchmal wissen Sie nicht einmal, was Sie rendern, und dieses Problem wird noch schwieriger zu lösen. Es ist auch extrem schwierig, diese Art von Komponenten mit Typsystemen zu überprüfen, da dies bedeuten würde, dass die meisten Komponenten eine Reihe von zufälligen Schnittstellen implementieren müssen, die sie untereinander teilen sollten, es ist ein tiefes, tiefes Kaninchenloch, in das man hineingehen kann.

Wenn eine Umschreibung vorgenommen wird, um dies zu beheben, würde ich erwarten, dass die Designer dahinter den Schaden erkennen, den diese schlechten Muster der Codebasis zufügen, anstatt sich auf schlechte Entscheidungen zu verdoppeln.

Wir müssen uns daran erinnern, dass jsx auf Javascript aufgebaut ist, und die Verwendung der "Idiosynkrasien" von Javascript als Ausrede, um bei der Verwendung von Schlüsselwörtern absichtlich mit der Sprache in Konflikt zu geraten, ein schlechter erster Schritt zur Reparatur der API ist. Ich würde vorschlagen, anstatt einen Krieg zu beginnen gegen die Sprache würden Sie sich ganz davon entfernen

@gaearon Lange Zeit! :) (ps. sorry für tl;dr voraus)

Wie auch immer, ich wollte nur einen Einblick in das geben, was ich aus meinen eigenen Abenteuern gelernt habe. Ich habe mein eigenes "bloßes minimales" React-Derivat erstellt, das ich jetzt für leistungs-/funktionskritische Anwendungen verwende. Es war ursprünglich nur ein lustiges Nebenexperiment, aber ich sah Leistungsverbesserungen von über +300 % in realen Fällen für das anfängliche Rendern/Aktualisieren/Löschen, einschließlich vieler anderer Vorteile. Das ist auch ohne die Verwendung eines gepoolten Ereignishandlers.

IIRC, ein großer Teil davon stammt einfach aus meiner eigenen Bibliothek, die die gesamte React-Props-Logik umgeht und Attribute direkt in setAttribute, Stile direkt in style.setProperty, Listener direkt in addEventListener und so weiter einspeist. Die grundlegende Schnittstelle des DOM-Elements sieht also so aus: `{attributes: {}, style: {}, listeners: {}, className: "", ...}, es ist ausführlicher, aber die Schnittstelle ist jetzt klein und trivial zu implementieren und ist extrem schnell. Das ist wahrscheinlich zu extrem für Sie, aber es hat mir sehr, sehr gut gedient.

Etwas, das ich auch getan habe, ist, CSS vollständig fallen zu lassen, alle Stile sind inline. Es ist viel viel schneller als Sie erwarten würden und bietet viele nette praktische Vorteile. Es umgeht auch die Kosten für das anfängliche CSS-Parsing des Browsers (was überraschend teuer ist) und den Selektorabgleich, der den größten Teil des Overheads wieder hereinholt. Ich kann auf meinem Laptop mit geringer Leistung problemlos stabile 60 FPS und weit darüber hinaus erreichen, selbst für komplexe Hierarchien (ohne Baumbeschneidung).

Ich kann mir vorstellen, dass das meiste davon nicht wirklich nützlich für Sie ist, aber vielleicht ist da etwas Interessantes dabei. Wie auch immer, mein Hauptkritikpunkt bei HTML+React ist, dass React-Benutzerkomponenten keine Schnittstelle für Layout/Positionierung (und wahrscheinlich bis zu einem gewissen Grad auch Ereignisse) bereitstellen, ohne auf CSS zurückzugreifen. Vereinfacht gesagt, wenn ich eine ButtonComponent erstelle und dann verwende, kann sie standardmäßig nicht positioniert oder in ein Layout integriert werden, ohne; Implementieren einer zweckspezifischen Logik darin, Einhüllen in ein Dummy-Element, das positioniert werden kann, oder durch Verfügbarmachen einer Stil-Prop, die mit den Stilen zusammengeführt wird, die für das Root-Element von ButtonComponent verwendet werden. Keines davon ist perfekt, und das Zusammenführen von Stilen ist gefährlich, da es einfach ist, Stile dort einzufügen, die Sie nicht sollten. Das Problem besteht im Wesentlichen darin, dass an Komponentengrenzen eine Teilmenge der verfügbaren Eigenschaften öffentlich (Positionierung/Layout) und einige intern (visuelle Gestaltung) sein sollten.

Eine andere Sache, die ich mache, ist die Trennung zwischen Komponenten und Inhalt/Kindern. Beispielsweise nehmen DOM-Komponenten keine Liste von Kindern entgegen, sondern akzeptieren eine Inhaltsinstanz. Die Inhaltsinstanz implementiert die Abstimmungslogik und das Rendern von untergeordneten Elementen, was bedeutet, dass Sie unterschiedliche Implementierungen für unterschiedliche Zwecke haben können. Die offensichtlichsten Anwendungsfälle sind: meist statische Hierarchien vs. dynamisch generierte Kinder. Statische Hierarchien, die die Mehrheit ausmachen, können also mit einer schnelleren, einfacheren Logik implementiert werden, während dynamisch generierte Kinder konfigurierbare Strategien haben können. Es eröffnet auch die Möglichkeit, "Inhaltskomponenten" zu haben, die zum intelligenten Verwalten von z. B. Flexbox-Layouts ohne unnötige Umwege verwendet werden könnten.

In Bezug darauf und etwas, von dem ich denke, dass React falsch liegt, sind Kinder. Ich bin noch nicht zu einer bestimmten Schlussfolgerung oder Lösung gekommen. Aber ich bin der festen Überzeugung, dass es in React ein grundlegendes Problem gibt, da Sie Props nicht von der Wurzel zu einem beliebigen Punkt in der Hierarchie blasen können, ohne jedes einzelne Element zwischen diesen beiden Punkten neu zu rendern, und effektives Pruning ist oft auch problematisch. Die Leistung ist meistens „gut genug“ und die zusätzliche Komplexität der Verwaltung in React macht es möglicherweise nicht lohnenswert, sie zu lösen. Aber in meinen bisherigen Experimenten war ich in der Lage, die Kosten für vollständige Root-Updates mit sehr kleinen Mengen an trivialem Code auf Bruchteile zu reduzieren, aber meiner Intuition zufolge ist dies nicht sehr kompatibel mit der Philosophie von React oder seinem vereinfachten Kindermodell.

Etwas, das meistens definitiv nichts für Sie ist, aber ein großes Merkmal meiner Bibliothek ist, dass sie im Grunde nur ein minimales "Basis-DOM-Element" für allgemeine Zwecke bietet. Die Idee ist, dass Sie Ihre eigenen Low-Level-spezifischen Verhaltensweisen trivial erweitern/ersetzen und implementieren können, wenn Sie ein großes Projekt mit spezifischen Anforderungen/Umständen sehr kostengünstig und ohne Rückgriff auf "Hacks" entwickeln, z. B. wenn Sie sehr stark berühren -orientiert sein, spezielles Style-Handling machen wollen usw. Es bedeutet auch, dass verschiedene Versionen kompatibel sind und nebeneinander laufen können, solange die ABI gleich ist (eine Änderung sollte extrem selten und sehr einfach zu beheben sein ). Das bedeutet auch, dass Sie in der DOM-Element-Oberfläche recht eigensinnig sein können, ohne allumfassend sein und versuchen zu müssen, alle Probleme zu lösen.

Wie auch immer, vielleicht meistens nur herumgeschwafelt und ich kann die meisten Konzepte wahrscheinlich nicht sehr gut vermitteln, aber vielleicht gibt es etwas Interessantes für Sie von jemandem, der die entgegengesetzte Richtung eingeschlagen hat. Das meiste davon ist wahrscheinlich nicht relevant für Sie, nur weil Sie auf "Einfachheit" abzielen, aber wer weiß :)

Bevor ich es vergesse, könnten Sie auch an meiner Funktion objectKeyValueReconcile interessiert sein, die speziell optimiert wurde, um außerordentlich schnell zu sein, um Prev/Next-Requisiten für React-ähnliche Szenarien zu vergleichen. Es ist für mich für ziemlich signifikante Leistungssteigerungen in der realen Welt verantwortlich.

https://github.com/syranide/surgical/blob/master/packages/surgical/private/objectKeyValueReconcile.js

Imho würde ich die "Klassen" -Idee fallen lassen. JSX wird irgendwann sterben.

Was sind die Gedanken, React DOM Unterstützung für nicht elementbasierte DOM-/Fensterereignisse hinzuzufügen? Mit der möglichen Entfernung synthetischer Ereignisse vermute ich, dass es immer noch eine Form des Sammelns/Aktualisierens/Stapelns von Ereignissen geben würde. Die Keypress-, Resize- und Window-Scroll-Ereignisse sind gängige Szenarien, die mir in den Sinn kommen, aber möglicherweise würde es möglich sein, die meisten/alle der Liste in https://developer.mozilla.org/en-US/docs/Web/Events zu unterstützen hinter derselben Abstraktion vorteilhaft sein.

Dies wird zufällig auch in der ältesten offenen Ausgabe Nr. 285 diskutiert 😄.

@gaearon

Der praktische Effekt von className -> class wird sein:

({ className }) => <div className={className} />

wird werden

({ ...rest }) => <div class={rest.class} />

Diese Änderung wird einiges an Schmerz verursachen, während die Vorteile rein akademisch sind. Wir haben gesehen, dass andere Gemeinschaften ähnliche Dinge tun - bedenken Sie zum Beispiel, dass python3 vor einem Jahrzehnt zum ersten Mal veröffentlicht wurde und wir immer noch darüber streiten. Ein beträchtlicher Teil der Community hat den Übergang noch nicht vollzogen und wird es nie tun. Bitte ueberlege es Dir nochmal.

@kans

Oder dieses:

props => <div class={props.class} />

Das ist von ähnlicher Komplexität wie die ursprüngliche Funktion.

Ich mochte className, weil class ein Schlüsselwort in js ist, aber glaube nicht, dass es so oder so eine große Sache ist. Ich bevorzuge ein glamouröses Styling, also betrifft mich das nicht. Ich habe className in den letzten Jahren vielleicht ein paar Dutzend Mal verwendet?? Fast nie.

Ein Gedanke, der mir zugunsten von class eingefallen ist, ist jedoch, dass die meisten Leute, die className tatsächlich verwenden, CSS verwenden und das HTML/CSS-Modell von class erwarten. Der überwältigende Hauptzweck dieser Requisite ist wirklich nur das Verlinken mit CSS-Code, richtig, warum also nicht einfach Klasse nennen, wie es ein HTML/CSS-Benutzer erwartet?

IMO außerhalb des Designsystemcodes würde die wirklich idiomatische React-Entwicklung normalerweise sowieso nicht sehr viel className oder class verwenden. Wenn ich Klassen für CSS verwenden muss, ist es meistens auf ein paar kleine UI-Komponenten beschränkt. So ziemlich alles, was auf der Anwendungsebene verwendet wird, ist eine höhere Ebene (wie beispielsweise <Columns verticalAlign="center"> oder <BodyText /> ).

Ich frage mich also, ob die Umbenennung von className in class es für die Art von Leuten einfacher macht, die die Requisite sowieso verwenden (einfacher in die React-Entwicklung einzusteigen, den Kontext zu wechseln, nicht wütend zu werden , etc), warum nicht einfach umbenennen?

Reduzieren Sie bitte die Bündelgröße.

Da dies ein großes, bahnbrechendes Update ist, könnten wir vielleicht auch die Benennung des React-Lebenszyklus korrigieren!

dh shouldComponentUpdate => shouldUpdate usw. Diese Benennung ist mehr als albern.

@AlexGalays

Da dies ein großes, bahnbrechendes Update ist, könnten wir vielleicht auch die Benennung des React-Lebenszyklus korrigieren!

dh shouldComponentUpdate => shouldUpdate usw. Diese Benennung ist mehr als albern.

Hook-Namen mit längerem Lebenszyklus sind weniger mehrdeutig, wenn danach gesucht wird. Kürzere Namen sind zu allgemein und hängen vom Kontext ab, in dem sie sich befinden, sodass sie zufällig mit etwas anderem einer großen Codebasis übereinstimmen können (falsch positive Übereinstimmung).

Lifecycle-Methoden sind Teil des React-Kerns, und in dieser Ausgabe geht es ausschließlich um React-Dom.

@ljharb
Ups, in der Tat!

@sompylasar
Tut mir leid, das ist einfach kein guter Grund (Wortspiel beabsichtigt, reasonReact hat die Methodennamen korrigiert :)). Wir stellen auch nicht allen unseren Modulen ihre Paketnamen voran und finden sie gut. Wie auch immer, ich werde aufhören, darüber zu reden, da React-Core in dieser Ausgabe nicht berücksichtigt wird.

Würde gerne diese Änderungen sehen.
Ich hoffe, dass sie unter Berücksichtigung der benutzerdefinierten Elemente-Interop implementiert werden.

Ich frage mich, ob es sich lohnt, einige der Diskussionen in separate Threads im Forum zu verschieben (https://discuss.reactjs.org)? Da GitHub-Probleme nicht wie Forenbeiträge in Threads unterteilt sind, ist es schwierig, mehrere verschiedene Dinge in demselben Problem zu diskutieren.

Die Änderung von className -> class erscheint mir interessant 😺

Watch, React-Projekte 2019

const {
  class: className, // YouKnowIamRight PepeHands
  someFancyProp,
  ...restProps
} = props

Ich sehe das mit Sicherheit kommen.

Ich liebe es total, HTML kopieren und einfügen zu können und className nicht ändern zu müssen, aber gleichzeitig sehe ich die Probleme, die das class reservierte Schlüsselwort mit sich bringen könnte.

An diesem Punkt würde ich es vorziehen, bei className zu bleiben, es sei denn, Sie haben starke technische Bedenken (keine persönliche Präferenz).

Aber das ist nur meine pragmatische Meinung.

Ich verstehe zwar die zusätzliche Reibung, die class -Kennung nicht zerstören zu können, aber ich habe das Gefühl, dass zu viele Leute in diesem Thread die Anzahl der Male überschätzen, die sie benötigen, um den Klassennamen als Requisite zu erhalten.

Das Übergeben className an eine React-Komponente (das ist nicht nur ein DOM-Element) bedeutet, dass Sie entweder ziemlich kleine Bausteine ​​erstellen, ohne neue Abstraktionen bereitzustellen, oder dass diese Komponente einige ihrer Implementierungsdetails offenlegt. Im ersten Fall (z. B. <Button /> -Komponente) möchten Sie wahrscheinlich dem Beispiel von @gaearon folgen und den "Rest" der Requisiten auch an das DOM-Element weiterleiten. Im zweiten Fall würde Sie die zusätzliche Reibung vielleicht dazu zwingen, die Sache zu vermeiden und eine bessere Lösung zu finden.

Aus meiner bescheidenen Erfahrung heraus musste ich öfter HTML in JSX kopieren und einfügen (und class durch className ersetzen), als ich mich erinnern kann, eine Komponente zu erstellen, die className empfängt.

Das Verteilen aller Requisiten auf ein HTML ist ein Anti-Pattern. Wenn jemand in der Zukunft eine zusätzliche Stütze einfügt, die zufällig mit einem HTML-Attribut übereinstimmt, wird dies das Verhalten unerwartet ändern. Wenn IE ein neues Attribut hinzufügt, werden Sie abgespritzt.

@philipwhiuk Wenn Sie nur die Requisiten verteilen, die Sie nicht verwenden, gibt es keine Verhaltensprobleme.

@j-f1

Wenn Sie nur die Requisiten verteilen, die Sie nicht verwenden, gibt es keine Verhaltensprobleme.

Nicht wirklich. Wenn Sie Ihrer Komponenten-API eine neue Option hinzufügen, wird diese Option nicht mehr an den zugrunde liegenden DOM-Knoten weitergegeben. Jemand kann sich darauf verlassen, dass genau dieses Attribut für das Element festgelegt wird, und dann brechen Sie diese Person. Das Verteilen aller ungenutzten Requisiten auf alles darunter bedeutet, dass jede Ergänzung Ihrer Komponenten-API eine bahnbrechende Änderung darstellt.

Übrigens, ich habe ein zufälliges Beispiel verwendet, in dem Sie den Wert von class dekonstruieren, aber bei diesem Detail nicht abgeschnitten werden.

Viele von Ihnen (ja, das tun Sie) dekonstruieren fast jeden Wert aus props und state , anstatt die Punktnotation zu verwenden, aus anderen Gründen als um zu vermeiden, zusätzlichen Text einzugeben.

Deshalb lege ich die Betonung auf die Situation, aber gehe nicht seitwärts und konzentriere mich auf die Verbreitung von Requisiten oder was auch immer für ein anderes Nebenthema du darüber sprechen könntest.

Wenn Sie etwas pragmatischer sind, würden Sie über die technischen Implikationen statt über Ihre persönlichen Vorlieben sprechen, aber ich sehe niemanden, der etwas über die technischen Implikationen von className sagt.

Eine andere Sache, auf die Sie achten müssen, ist, dass Sie die Core-Mitwirkenden dazu bringen, sich auf etwas zu konzentrieren, das die Frage der persönlichen Vorlieben ist (beweisen Sie mich falsch, nur weil ich möchte, dass Sie pragmatisch darüber nachdenken).

Ihre Zeit, Mühe und ihr Geld (vom Unternehmen) sind begrenzt, also besser, wenn die Community versteht, dass es bessere Dinge gibt, auf die wir unsere Aufmerksamkeit richten können, und wenn jemand aus dem Kernteam eine Stunde für etwas aufwendet, für das wir es vorziehen, dass er es verwendet die nächste große Sache für React, kein Refactoring-Code für solche Änderungen.

Aber nochmal meine pragmatische Meinung.

Apropos Polyfills, ich denke nicht, dass React versuchen sollte zu erkennen, ob der Benutzer "gute" Polyfills angegeben hat.
(zB hasBadMapPolyfill im Code)
React sollte nicht für all die zufälligen Fehler verantwortlich gemacht werden, die man in einem Programmierprojekt machen kann.

@AlexGalays React ist auf die Verwendung einer Map-Implementierung mit korrekter Semantik angewiesen. Wenn Benutzer ein nicht konformes Polyfill verwenden, kann ihre App auf unerwartete und verwirrende Weise brechen, daher ist es hilfreich, in diesem Fall im Voraus zu warnen.

Dies geschieht auch nur im Entwicklungs-Build, sodass in der Produktion kein Overhead dafür anfällt.

Ich liebe dieses React Fire und Sie würden weiter daran arbeiten, da es ein interessanterer Schritt zu sein scheint, ReactDOM zu modernisieren.

Wäre es möglich, dass das Reaktionsfeuer Ereignishandler nicht erneut bindet?

class Compo exntends Compoent {
 onClick() {
   ...
 }
  render() {
   <button onClick={this.onClick} >click me </button>
  }
}

Ich glaube nicht, dass jemand wirklich möchte, dass der Event-Handler zurückgeprallt wird. Und in den seltenen Fällen, in denen Sie es tun würden, könnten Sie es manuell binden

@cullphid

Wäre es möglich, dass das Reaktionsfeuer Ereignishandler nicht erneut bindet?

Sie können die Methode einmal an die Klasse binden, indem Sie automatische Bindungen für Pfeilfunktionen verwenden oder die Funktion in Ihrem Konstruktor binden. Wenn es eindeutige Parameter gibt, die Sie mit dem Ereignis verketten möchten, können Sie sich die Ereignishandler merken oder DOM-Attribute an die Knoten selbst anhängen und über event.currentTarget darauf zugreifen.

class Compo extends Compoent {
 onClick = () => {
   ...
 }
 render() {
   <button onClick={this.onClick}>click me</button>
 }
}

Ein weiterer Vorteil der Vereinfachung des Ereignissystems (können wir zu rohen DOM-Ereignissen ohne Pooling zurückkehren, wie es ALLE Frameworks tun? :) ) ist, dass es auch einfacher ist, statisch zu tippen.

Scheint ein toller Plan zu sein! Es wäre wirklich schön, IE 11-Unterstützung zu haben (auch wenn das bedeutet, dass wir unsere eigenen Polyfills versenden, was völlig in Ordnung ist). Als jemand, der mit Regierungskunden zusammenarbeitet, ist es völlig unbekannt, wann sie aufhören werden, IE 11 zu verwenden :(

@MatthewHerbst dasselbe Boot, unsere Kunden verwenden IE 11 und wir haben genug Verkehr davon 😢

Ich wollte mich nur einmischen, um zu sagen, dass das alles super aufregend ist. Das einzige, was ich gelesen habe, das mich beunruhigt hat, war:

Es ist möglich, dass wir nicht versuchen werden, einige der bestehenden Browser-Unterschiede auszugleichen

Im Moment finde ich es toll zu wissen, dass das Ereignissystem von React auf jedem Browser, den React unterstützt, "einfach funktioniert". Ich fürchte, dass diese Änderung bedeutet, dass es in die Verantwortung der App fällt, browserübergreifende Probleme zu berücksichtigen. Dies würde wahrscheinlich viele schwer zu verfolgende Fehler einführen. ... zumindest für meine Apps. :)

Wie auch immer, danke wie immer für die tolle Bibliothek.

@kentcdodds hatte die JSX 2.0 -Integration als eine mögliche Idee erwähnt, die ich durch die Strategie gelesen hatte, und nichts gesehen, was damit in Zusammenhang zu stehen schien. Ich habe mich gefragt, ob das nur in der Luft liegt oder etwas, das für die Zukunft zurückgestellt wird?

Lass den IE sterben! Unterstützen Sie keine absolut veralteten Browser. Es gibt auch für restriktive Unternehmen keinen Grund, nicht auf einen aktuellen Browser umzusteigen. Sie werden diesen IE11 in Ihren Statistiken sehen, bis Sie und das Web ihn nicht mehr unterstützen.

@hbroer Legacy-Software?

@hbroer niemand bleibt auf einem älteren Browser, weil seine Websites noch funktionieren, sie tun dies, weil sie entweder keine Wahl haben oder nicht wissen, wie sie aktualisieren sollen. Das Brechen einer Website ist für diese Benutzer äußerst feindselig und hinterlässt ihnen keinen aktualisierten Browser, sondern nichts.

• "Ich weiß nicht, wie ich aktualisieren soll" - nicht unser Problem, aber wir können Nachrichten "Neuen Browser installieren" mit einer Liste von Browsern und möglicherweise mit Hilfetext und Telefonnummer der Microsoft-Hotline ^^ einfügen
• „keine Wahl haben“ – Richtig, aber die Organisation muss ihre Umgebung aktualisieren. Wenn ihre Werkzeuge nicht funktionieren, werden sie es tun.

Ich hasse es, für die Vergangenheit zu programmieren und kann die Vorteile neuer Technologien nicht nutzen, weil 90 % der Programmierer immer noch die beschissenen Browser der unteren 15 % der Verbraucher unterstützen, die im letzten Jahrhundert lebten. ^^ Ich will dieses "Oh, was ist mit diesen Internet Explorer 6 Nerds, wir müssen diese 15% unterstützen" nicht noch einmal für die nächsten 10 Jahre haben.

btw M$ scheint Edge für Windows 7 und 8 mit ihrer Umstellung auf Webkit zu bringen.

@hbroer alles ist unser Problem, wenn es sich auf Benutzer auswirkt. Habe etwas Empathie für andere Menschen.

(Separat ist M$ eine ziemlich jugendliche und sehr veraltete Referenz aus den späten 90ern, die Sie vielleicht entfernen möchten; ich entferne dies gerne beiseite, wenn Sie dies tun.)

Ich sehe, hier sind viele M$ Fanboiz. :Ich kümmere mich wirklich um Menschen, aber nicht um Organisationen, die den technologischen Fortschritt blockieren, oder die Programmierer, die meinen, diesen alten Mist über Jahre hinweg unterstützen zu müssen. Ich habe kein Problem mit einem zusätzlichen Paket, das eine Bibliothek "alten Mist kompatibel" macht. Aber eine Bibliothek im Jahr 2019 sollte mit >=2019-Technologie codiert werden und nicht mit <=2013-Technologie. Es ist schon schlimm genug, diesen (oh, lasst uns das ein bisschen anders machen) Safari und (alten) Edge-Mist unterstützen.

Mikrotropfen

@hbroer Tatsächlich sind alte Android-Browser und alte Safari ein größeres Problem als jeder Microsoft-Browser. Es geht nicht darum, ein „Fanboi“ zu sein, sondern professionell zu sein, und den Begriff „M$“ zu verwenden, ist es nicht.

Und nein, es ist in keiner Weise „schlecht“, alte Technologien zu unterstützen, es ist moralisch und ethisch vertretbar. Was schlecht ist, sind Websites, die "am besten in X funktionieren", egal ob das Netscape Navigator, IE 6 oder der neueste Chrome ist.

Ich sehe, hier sind viele M$ Fanboiz.

@hbroer Ich sehe hier eine Person mit pauschalen Ad-hominem-Angriffen.

Aber eine Bibliothek im Jahr 2019 sollte mit >=2019-Technologie codiert werden und nicht mit <=2013-Technologie.

Nein, sollte es nicht.

Wenn Sie sich eine Sekunde Zeit nehmen und sich die Standardeinstellungen der Browserliste ansehen, wären Sie überrascht. Stattdessen greifen Sie auf Ad-hominem-Angriffe und Beleidigungen auf Schulkantinenebene zurück.

Sobald Sie genügend Benutzer haben, wird IE11 zu einem beträchtlichen Teil der Personen, die auf Ihre Website zugreifen. Bei einem früheren Job hatten wir fast eine Million Menschen im Monat, die über IE11 auf unsere Website zugegriffen haben.

Wenn Sie alten Mist unterstützen möchten, fügen Sie Poly-Füllungen hinzu. Kein Grund, nicht für die Zukunft und die Gegenwart zu programmieren. Die Unterstützung alter Technologien macht Web-Apps fetter und langsamer als nötig.

Ps Ich sehe eine Person, die Sarkasmus nicht lesen kann und sich nicht um Smilies kümmert ^^

@hbroer Sie zeigen, dass IE11 die Gegenwart ist, also wird erwartet, dass wir dafür codieren.

Und noch einmal. Siehe den Standardwert unter https://browserl.ist.

Ps Ich sehe eine Person, die Sarkasmus nicht lesen kann und sich nicht um Smilies kümmert ^^

Yeah Nein. Dies ist eine gängige Taktik, die von Trollen und Spielplatzmobbern angewendet wird. "Was?! Ich habe dich nicht beleidigt! Es war nur ein Witz!".

0,20 % der Menschen auf dem Planeten, sogar gefiltert nach „denjenigen, die das Internet nutzen“, sind 6,4 Millionen Menschen. Prozente sind völlig irrelevant. Code für Menschen; die Vergangenheit und die Zukunft und Ihre Bundle-Größe spielen keine Rolle.

Wenn Sie für die Bündelgröße von Menschen codieren möchten, ist dies ebenso wichtig wie die Browserkompatibilität. Benutzer erwarten nicht nur, dass die Dinge funktionieren, sondern auch schnell zu laden sind.

Jetzt, im Jahr 2019, werde ich für neue Projekte CSS-Grid verwenden (das nur experimentelle Unterstützung für IE11 bietet) und auf ES6 transpilieren, und ich möchte keine Polyfills für diesen veralteten Browser liefern. IE11-Benutzer erhalten lediglich eine Meldung: Aktualisieren Sie Ihren Browser oder verwenden Sie eine Alternative.

Es gibt Leute da draußen, die kein Java-Script verwenden wollen. Sie kümmern sich um sie? Das sieht man nicht in den Statistiken. Und ich bin auch nicht in der Statistik, wie viele andere Leute, die diese Tools blockieren.

Ich achte auf jeden Browser, der nicht veraltet ist. Ich unterstütze Edge, das weniger Benutzer hat als dieser IE11-Mist, wegen Windows 7 (das bis Januar 2020 unterstützt wird), und moderne Menschen verwenden moderne Browser. ^^

Niemand hindert Sie daran, Polyfills und so etwas wie ein Kompatibilitätspaket zu verwenden. Aber der Kern sollte auf dem neuesten Stand sein und nicht nur wegen eines Stücks eines alten M$-Tech-Browsers zurückbleiben.

Was mir in vielen Javascript-Frameworks fehlt, ist LTS. Darüber können wir reden. Wenn Sie eine moderne Seite mit Funktionen aus der Gegenwart erstellen, ist es schön, ein aktuelles technisches Framework zu verwenden. Und wenn Sie eine Webapp für B2B-Zeug bauen, die ein Maximum an Stabilität und Kompatibilität benötigt, können Sie eine LTS-Version verwenden. Oder verwenden Sie Knockout. Dann können Sie die wenigen 100t Leute unterstützen, die immer noch ein nicht aktualisiertes Windows XP mit IE6 verwenden ^^

Die Kompatibilität ist im ursprünglichen Beitrag unter "Kompromisse" eindeutig aufgeführt, sodass die perfekte Unterstützung für alte Browser bereits ein sekundärer Fokus ist.

Sie erfordern mehr Polyfills und Integration, wenn Sie sie unterstützen müssen, aber das wäre Ihre Wahl . Sie können auch mehrere Bundles für verschiedene Browserziele erstellen und das kleinstmögliche JS für jeden Besucher bereitstellen, damit es nicht Ihr gesamtes Publikum beeinträchtigt.

Der Fortschritt bei React Fire selbst scheint unbeeinflusst zu sein, also ist aus dieser Debatte wirklich nichts zu gewinnen. Lassen Sie uns bitte weitermachen und zum Hauptthema zurückkehren.

Wäre dies eine gute Gelegenheit, #6410 zu lösen? Es scheint ähnliche Auswirkungen wie die vorgeschlagenen Änderungen an onChange / onInput zu haben.

Update vom 05.06.2019

Es ist eine Weile her. Hier ist ein kleines Update, wo wir sind.

Wir haben im Dezember mit der Arbeit an Fire begonnen. In https://github.com/facebook/react/pull/14382 und anderen Threads ist einiges in Arbeit. Als wir jedoch begannen, Teile des Ereignissystems zu entfernen, die wir für unnötig oder veraltet hielten, entdeckten wir viele Grenzfälle, in denen es sehr hilfreich war und Fehler verhinderte – sogar in modernen Browsern. Wir wollen immer noch das Legacy-Bloat reduzieren, aber es ist nicht klar, dass es in der Praxis die beste Richtung ist, näher an rohen DOM-Events zu sein. Das Reduzieren des Bibliothekscodes nur, um ihn mehrmals im Anwendungscode neu hinzuzufügen, ist nicht der beste Kompromiss. Und es ist nicht einmal immer möglich, es auf App-Ebene zu beheben.

Unabhängig davon stellten wir bei der Arbeit an FB5 fest, dass es selbst bei der Verwendung von React heute erhebliche Schwierigkeiten gibt, Benutzeroberflächen zu implementieren, die sowohl auf Maus- als auch auf Touch-Geräten funktionieren und sich gut anfühlen. Sogar grundlegende Dinge wie Schaltflächen fühlen sich mit Maus und Berührung ganz anders an, wenn Sie Ereignisse wie onClick verwenden, und es wird noch schwieriger, ein konsistentes Verhalten mit Hover, Fokus usw. zu erreichen.

Als wir also mit der Arbeit an Fire begannen, dachten wir, dass ein benutzerdefiniertes Ereignissystem vielleicht unnötig ist. Aber nachdem wir es per Prototyping entfernt hatten, stellten wir fest, dass unser Ereignissystem tatsächlich unser größter Hebel ist, um diese Reihe von Problemen zu beheben .

Als Ergebnis dieser Untersuchung haben wir die Arbeit an anderen Gegenständen, die Teil von React Fire sind, vorübergehend unterbrochen und beschlossen, uns zunächst nur auf das Ereignissystem zu konzentrieren. Dieses Projekt wurde als React Flare (https://github.com/facebook/react/issues/15257) bekannt. Es ist an sich herausfordernd genug und wirkt sich auf die anderen Punkte auf dieser Liste aus, daher konzentrieren wir uns zunächst isoliert darauf.

Das Ziel von React Flare ist es, das Erstellen von UIs zu vereinfachen, die sich auf dem Desktop und auf Mobilgeräten, mit Maus und Berührung gut anfühlen und zugänglich sind. Es enthält deklarative APIs zum Verwalten von Interaktionen wie Press, Hover und Focus. Anders als beim aktuellen React-Ereignissystem bläst das Flare-Design das Bündel nicht für Ereignisse auf, die Sie nicht verwenden – und es sollte es ermöglichen, die Codemenge in UI-Bibliotheken zu reduzieren, die sich mit Maus- und Berührungsereignissen befassen.

React Flare ist immer noch ein Experiment, aber wir sind ziemlich zuversichtlich in seine allgemeine Richtung und planen, es schließlich offiziell als Open Source verfügbar zu machen. (Im Moment funktioniert es nur, wenn Sie manuell vom Master bauen, und es gibt keine Semver-Garantien, da wir aktiv daran arbeiten.) Wie Fire ist „Flare“ nur ein Codename – wenn wir es ausliefern, wird es das haben richtige Benennung, Dokumentation usw. Vielleicht react/events oder so ähnlich. Äquivalente Events möchten wir irgendwann auch in React Native anbieten.

Nachdem wir die anfängliche Implementierung von React Flare abgeschlossen haben, kehren wir zur React Fire-Liste zurück und bewerten alle anderen Punkte neu, indem wir das verwenden, was wir daraus gelernt haben. Es ist immer noch wahrscheinlich, dass wir, wenn Flare einen „reicheren“ Satz von Ereignissen übernimmt, die „grundlegende“ Ereignisbehandlung in React DOM vereinfachen und eine Reihe von Polyfills entfernen können. Vielen Dank an alle für die bisherige Diskussion, und ich hoffe, dies ist nützlich.

Gute Arbeit! Das Ereignissystem ist also immer noch notwendig, um Maus- und Berührungsereignisse auszugleichen, aber es wird leichtgewichtig und unabhängig von React sein.

Wird "React Flare" als Teil des Standard-React-Pakets geliefert oder ist eine zusätzliche Installation erforderlich, wenn man die Menge der APIs berücksichtigt, mit denen es geliefert wird?

Wir möchten vermeiden, dass ungenutzter Code gebündelt wird. Die aktuelle Absicht ist also, dass es per API opt-in ist. Vielleicht getrennte Einstiegspunkte in einem einzigen Paket.

Wird dieses Maus- und Berührungsereignissystem PointerEvent nutzen? Ich habe im vorherigen Update keine Erwähnung dieses Webstandards gesehen, daher wollte ich Sie nur darauf aufmerksam machen.

Zeigerereignisse sind DOM-Ereignisse, die für ein Zeigegerät ausgelöst werden. Sie sind so konzipiert, dass sie ein einzelnes DOM-Ereignismodell erstellen, um mit Zeigeeingabegeräten wie Maus, Stift/Stift oder Berührung (wie einem oder mehreren Fingern) umzugehen. Der Zeiger ist ein hardwareunabhängiges Gerät, das auf einen bestimmten Satz von Bildschirmkoordinaten abzielen kann. Ein einziges Ereignismodell für Zeiger kann das Erstellen von Websites und Anwendungen vereinfachen und unabhängig von der Hardware des Benutzers eine gute Benutzererfahrung bieten.

Und hier ist ein direkter Link zur aktuellen Browser-Kompatibilität .

@jonathantneal Ja, das neue System nutzt Zeigerereignisse stark – mit Fallbacks auf Maus-/Touch-Ereignisse, wenn Zeigerereignisse nicht unterstützt werden.

Ich befürchte, dass https://github.com/facebook/react/issues/11347 in dieser Ausgabe nicht angesprochen wurde. Reagieren Sie Flunks https://custom-elements-everywhere.com.

Bitte berücksichtigen Sie Shadow-Root, wenn Sie das Ereignissystem umgestalten - nur das Anhängen an das React-Root würde die meisten Probleme heute nicht lösen, nur das Anhängen an das Element (https://github.com/facebook/react/issues/9242, https:// github.com/facebook/react/issues/15759, https://github.com/facebook/react/issues/13713, https://github.com/facebook/react/issues/11827)

In diesem Update: https://github.com/facebook/react/issues/13525#issuecomment -499196939 erwähnt @gaearon:

Als wir jedoch begannen, Teile des Ereignissystems zu entfernen, die wir für unnötig oder veraltet hielten, entdeckten wir viele Grenzfälle, in denen es sehr hilfreich war und Fehler verhinderte – sogar in modernen Browsern.

Ich war neugierig, ob eine Liste dieser Grenzfälle irgendwo dokumentiert ist?

@gaearon Jetzt, da Flare ausgegangen ist (SCNR), gibt es einen aktualisierten Plan (in Bezug auf das Update vom 5. Juni 2019 ), wie es weitergehen soll?

Und wie @trusktr möchte ich hier auch #11347 adressiert bekommen.

Könnten Polyfills in ein anderes Bündel aufgeteilt werden, insbesondere dasjenige, das für große Evergreen-Browser nicht relevant ist.

Hallo zusammen, es ist schon eine Weile her und wir haben einige dieser Dinge ein- und ausgeschaltet.

Lassen Sie mich jeweils ein Update geben:

• Beenden Sie die Wiedergabe von Eingabewerten im Attribut value (https://github.com/facebook/react/issues/11896). Dies wurde ursprünglich in React 15.2.0 über https://github.com/facebook/react/pull/6406 hinzugefügt. Es wurde sehr häufig gefordert, weil das konzeptionelle Modell der Leute des DOM darin besteht, dass das value , das sie im DOM-Inspektor sehen, mit dem JSX-Attribut value übereinstimmen sollte. Aber so funktioniert das DOM nicht. Wenn Sie etwas in ein Feld eingeben, aktualisiert der Browser das value -Attribut nicht. React sollte es auch nicht tun. Es stellte sich heraus, dass diese Änderung, obwohl sie wahrscheinlich für einige Codes hilfreich war, die auf CSS-Selektoren angewiesen waren, eine Kaskade von Fehlern verursachte – einige von ihnen sind bis heute nicht behoben. Einige der Folgen dieser Änderung sind: https://github.com/facebook/react/issues/7179 , https://github.com/facebook/react/issues/8395 , https://github.com/facebook /react/issues/7328 , https://github.com/facebook/react/issues/7233 , https://github.com/facebook/react/issues/11881 , https://github.com/facebook/react /issues/7253 , https://github.com/facebook/react/pull/9584 , https://github.com/facebook/react/pull/9806 , https://github.com/facebook/react/pull /9714 , https://github.com/facebook/react/pull/11534 , https://github.com/facebook/react/pull/11746 , https://github.com/facebook/react/pull/12925 . An diesem Punkt lohnt es sich eindeutig nicht, weiter gegen den Browser zu kämpfen, und wir sollten ihn rückgängig machen. Der positive Teil dieser Reise ist, dass wir dank der unermüdlichen Arbeit unserer DOM-Mitarbeiter ( @nhunzaker , @aweary , @jquense und @philipp-spiess) jetzt über detaillierte DOM-Testvorrichtungen verfügen, die uns helfen, Regressionen zu vermeiden.

Wir wollen dies immer noch tun, aber wir haben uns entschieden, React 17 zu „reservieren“, um minimal mögliche Breaking Changes zu haben, damit es sich auf das nächste Element auf dieser Liste konzentrieren kann. Diese Änderung wird also bis React 18 warten.

• Hängen Sie Ereignisse an das React-Stammverzeichnis an und nicht an das Dokument (https://github.com/facebook/react/issues/2043). Das Anhängen von Event-Handlern an das Dokument wird zu einem Problem, wenn React-Apps in größere Systeme eingebettet werden. Der Atom-Editor war einer der ersten Fälle, der darauf stieß. Jede große Website entwickelt schließlich auch sehr komplexe Grenzfälle im Zusammenhang mit der Interaktion von stopPropagation mit Nicht-React-Code oder über React-Roots hinweg (https://github.com/facebook/react/issues/8693, https://github .com/facebook/react/pull/8117, https://github.com/facebook/react/issues/12518). Wir werden auch eifrig Ereignisse an jeden Root anhängen wollen, damit wir während Updates weniger Laufzeitprüfungen durchführen müssen.

Wir machen das in React 17. Das war ein riesiger Haufen Arbeit, aber zum Glück ist es fertig.

• Migrieren Sie von onChange zu onInput und füllen Sie es nicht für unkontrollierte Komponenten (https://github.com/facebook/react/issues/9657). Siehe die verlinkte Ausgabe für einen detaillierten Plan. Es war verwirrend, dass React einen anderen Ereignisnamen für das sogenannte input -Ereignis im DOM verwendet. Während wir im Allgemeinen große Änderungen wie diese ohne nennenswerten Nutzen vermeiden, möchten wir in diesem Fall auch das Verhalten ändern, um etwas Komplexität zu entfernen, die nur für Grenzfälle wie das Mutieren von kontrollierten Eingaben erforderlich ist. Daher ist es sinnvoll, diese beiden Änderungen zusammen vorzunehmen und dies als Gelegenheit zu nutzen, damit onInput und onChange genauso funktionieren wie die DOM-Ereignisse für unkontrollierte Komponenten.

Wir werden wahrscheinlich darauf zurückkommen, aber es ist unklar, wie viel Abwanderung sich hier lohnt. Das ist also noch TBD.

• Vereinfachen Sie das Ereignissystem drastisch (https://github.com/facebook/react/issues/4751). Das aktuelle Ereignissystem hat sich seit seiner ersten Implementierung im Jahr 2013 kaum verändert. Es wird in React DOM und React Native wiederverwendet, ist also unnötig abstrakt. Viele der Polyfills, die es bietet, sind für moderne Browser unnötig, und einige von ihnen verursachen mehr Probleme, als sie lösen. Es macht auch einen erheblichen Teil der React DOM-Bundle-Größe aus. Wir haben hier keinen sehr spezifischen Plan, aber wir werden das Event-System wahrscheinlich komplett forken und dann sehen, wie minimal wir es machen können, wenn wir uns näher an das halten, was das DOM uns gibt. Es ist plausibel, dass wir synthetische Ereignisse ganz abschaffen werden. Wir sollten sprudelnde Ereignisse wie Medienereignisse stoppen, die im DOM nicht sprudeln und keinen guten Grund haben, zu sprudeln. Wir möchten einige React-spezifische Fähigkeiten wie das Blubbern durch Portale beibehalten, aber wir werden versuchen, dies mit einfacheren Mitteln zu tun (z. B. das erneute Versenden des Ereignisses). Passive Ereignisse werden wahrscheinlich ein Teil davon sein.

Wir haben dies Anfang 2019 versucht, und ein wirklich minimales Ereignissystem hat in unseren internen Tests nicht sehr gut funktioniert. Es gab ziemlich viel Cross-Browser-Normalisierung, die React durchführt, die immer noch nützlich für Leute mit älteren Browsern oder in Nischenbereichen wie Rich-Text-Eingabe-Editoren ist, die contentEditable verwenden. Als Teil unserer Arbeit zum Anhängen von Ereignissen an Wurzeln haben wir jedoch viel Abstraktion aus dem Ereignissystem entfernt, damit es in Zukunft einfacher zu verstehen und zu verbessern ist. Als Teil von React 17 entfernen wir das „Event-Pooling“, das für viel Verwirrung gesorgt hat, und wir geben auch das onScroll -Event nicht mehr weiter. Wir werden wahrscheinlich das Blubbern von Medienereignissen in React 18 stoppen und das React-Verhalten näher an das des Browsers bringen. Wir haben mit dem neuen Ereignissystem einige Bytes eingespart, aber sie wurden von neuen Funktionen, an denen wir arbeiten, in Anspruch genommen, sodass dies insgesamt nicht zu einer Verringerung der Bundle-Größe führen wird.

• className → class (https://github.com/facebook/react/issues/4331, siehe auch https://github.com/facebook/react/issues/13525#issuecomment- 417818906 unten). Dies wurde unzählige Male vorgeschlagen. Wir erlauben bereits die Weitergabe class an den DOM-Knoten in React 16. Die Verwirrung, die dies verursacht, ist die Syntaxbeschränkungen nicht wert, vor denen es zu schützen versucht. Wir würden diese Änderung nicht alleine vornehmen, aber in Kombination mit allem anderen darüber ist es sinnvoll. Beachten Sie, dass wir nicht einfach beides ohne Warnungen zulassen können, da dies für ein Komponenten-Ökosystem sehr schwierig zu handhaben ist. Jede Komponente müsste lernen, mit beiden richtig umzugehen, und es besteht die Gefahr, dass sie sich widersprechen. Da viele Komponenten className verarbeiten (zB durch Anhängen), ist es zu fehleranfällig.

Dies war der umstrittenste Teil des Vorschlags. Seitdem haben wir Hooks veröffentlicht, die das Schreiben von Funktionskomponenten fördern. In Funktionskomponenten empfehlen wir im Allgemeinen die Verwendung von Destrukturierung für Props, aber Sie können nicht { class, ... } schreiben, da dies ein Syntaxfehler wäre. Insgesamt ist also nicht klar, ob dies ergonomisch genug ist, um es tatsächlich durchzuziehen. Ich denke, es ist plausibel, dass wir uns das in Zukunft noch einmal ansehen oder zumindest class nicht warnen lassen und die Leute tun lassen, was sie wollen. Aber vorerst werden wir diese Idee zurückstellen.

Hallo, das ist ein toller Artikel!
Wollte nur wissen, ob es Pläne gibt, die React-DOM-Prod-Größe zu reduzieren? Für mobile Anwendungen ist dies immer noch ein Overhead, da der Browser mehr als 100 KB von React-DOM JS und dann andere Module parst. Dann App-spezifisches JS.
Bei inhaltsreichen Seiten verursacht dies eine stärkere Blockierung und eine höhere TTI.

Irgendeine Idee, wann wir solche Veränderungen sehen können?

@morevolk-latei Wie viel Zeit wird bei Ihren Messungen für das Parsen von 100 KB ReactDOM aufgewendet?