React: Informieren Sie sich über die Ermutigung von Benutzern, den DEV-Modus nicht an die Produktion auszuliefern

Als Referenz: https://github.com/facebook/react/pull/8782

Zum Kontext warnen wir bereits, wenn wir feststellen, dass Sie eine DEV-Version von React minimiert haben: https://github.com/facebook/react/blob/8791325db03725ef4801fc58b35a3bb4486a8904/src/renderers/dom/ReactDOM.js#L91 -L98

Soweit wir ähnliche Heuristiken finden können, um Benutzer zu benachrichtigen und vielleicht noch aggressiver einen DOM-Dialog zu öffnen, sollten wir das tun.

Ich möchte auch klarstellen, dass die von uns bereitgestellten Warnungen die Leistung erheblich verbessern können, wenn die Leute darauf achten. Dieser Thread erklärt einige Gründe dafür, warum es schwierig ist, dies nachträglich bereitzustellen, wenn es nicht die Standardeinstellung ist.

Ich möchte mich auch mit einem Vorschlag für eine einzelne Konsole einmischen. Warnung, wenn renderToString im Entwicklermodus aufgerufen wird. Offensichtlich wird in den meisten Situationen renderToString im Knoten aufgerufen, wo wir keinen DOM-Dialog alarmieren oder öffnen können.

Leider möchte ich nicht nur erkennen können, ob NODE_ENV auf production gesetzt ist, sondern auch, ob process.env.NODE_ENV kompiliert wurde. Kennt jemand eine Möglichkeit, das zu tun?

Danke für den Thread @sebmarkbage und ich erkenne die Schwierigkeiten bei der nachträglichen Bereitstellung an. Ich bin auch dankbar für die aktuellen Warnungen. Es scheint, dass einige Entwickler die Konsolenausgabe ihrer bereitgestellten Websites möglicherweise nicht so oft wie möglich überprüfen. Es ist jedoch ein guter erster Schritt.

Soweit wir ähnliche Heuristiken finden können, um Benutzer zu benachrichtigen und vielleicht noch aggressiver einen DOM-Dialog zu öffnen, sollten wir das tun.

Ich wäre dankbar für Verbesserungen der Heuristiken, die zum Benachrichtigen von Benutzern verwendet werden. Ein aggressiverer DOM-Dialog würde viel helfen. Es würde sicherstellen, dass die Website weiterhin für Endbenutzer funktioniert, gibt aber einen aktiven Hinweis darauf, dass es niedrig hängende Performance-Früchte gibt, die Entwickler auswählen können.

Die Alternative besteht darin, dass wir einen Weg finden, dies auf Build-Tool-/ENV-Ebene zu beheben, wie im ursprünglichen Beitrag erwähnt. Das würde vermeiden, dass eine DOM-Injektion erforderlich ist.

Das Einfügen von Nachrichten in das DOM scheint gefährlich und ein wenig zu anmaßend. Dies eröffnet die Möglichkeit, dass Endbenutzer unerwartete und verwirrende Warnungen erhalten, was meiner Meinung nach inakzeptabel erscheint.

@thelarkinn schlug vor, dass wir versuchen sollten, ENV-Konfigurationen zu standardisieren, die erforderlich sind, um die Erkennung solcher Nachrichten besser zu erleichtern

Dies scheint der ideale Raum zu sein, um dies anzusprechen. Es ist ein Build-Problem und sollte, wenn möglich, von den Build-Tools behoben werden.

Anekdotisch: Warnungen in der Konsole wurden in der Vergangenheit nicht gesehen (oder ignoriert). Ich habe hier keine harten Zahlen, aber ich denke, konsolenbasierte Warnungen reichen nicht aus. Ich stimme @addyosmani zu, dass eine DOM-basierte Warnung viel bewirken würde.

@surma vielleicht sollten sie console.warn oder console.error für eine bessere Sichtbarkeit verwenden 😉

Ich sehe nicht, wie es in jedem Szenario akzeptabel wäre, Inhalte nur dann in eine Anwendung einzufügen, wenn sie in der Produktion ausgeführt wird. Sie gehen davon aus, dass die Nachricht abgefangen werden würde, bevor die Anwendung an die tatsächlichen Benutzer gesendet wird, wo die Nachricht UX möglicherweise erheblich beeinträchtigen könnte.

Übrigens werden wir eine umfassendere Fehlerbehandlungsunterstützung in Fiber hinzufügen, sodass Sie Komponenten mit Fehlern (ausgelöste Fehler) durch benutzerdefinierte Fehleransichten ersetzen können. Selbst im Standard-Szenario werden wir wahrscheinlich sehr aggressiv vorgehen und diese Komponente einfach aus dem Baum entfernen, wenn sie einen Fehler verursacht, sodass Sie sowieso eine benutzerdefinierte Fehler-Benutzeroberfläche für Ihre Benutzer haben möchten.

Möglicherweise können wir einen solchen Fehler für diese Warnung auslösen.

Ich glaube ehrlich gesagt nicht, dass console.{error,warn} über console.log irgendetwas geändert hätte. Wie gesagt, diese Geschichte ist anekdotisch.

Ich sage auch nicht, dass das Anzeigen eines DOM-Dialogs _die_ Lösung ist. Es ist etwas, womit ich persönlich mich wohl fühlen würde. Wenn es negative Auswirkungen hat, im Entwicklermodus zu bleiben, würden die Benutzer zumindest wissen, dass _etwas_ nicht stimmt, und wahrscheinlich anfangen, auf die Schaltfläche „Hilfe“ oder so etwas zu klicken.

Fazit: Ich denke, Frameworks müssen irgendwann ins Gesicht des Entwicklers kommen. Ich würde gerne ein Brainstorming dazu durchführen, um zu sehen, welche Schritte und Kompromisse Autoren von Frameworks bereit sind einzugehen, um zu verhindern, dass Benutzer in Zukunft im Dev-Modus bereitstellen.

Was ist, wenn React überhaupt nicht funktioniert, wenn Sie keine Umgebung bereitstellen, unabhängig davon, ob es sich um Entwicklung oder Produktion handelt? Auf diese Weise wird eine bewusste Entscheidung für das eine oder andere getroffen.

Über die in das DOM eingefügte Nachricht könnte sie mit einem globalen oder so etwas deaktiviert werden. Keine große Sache IMO. Wenn Sie es deaktivieren, bestätigen Sie, dass Sie wissen, was Sie tun.

Das Problem mit einer Konsolennachricht ist, dass Leute manchmal eine Menge Dinge protokollieren oder andere Warnungen haben, die sie ignorieren, und es ist leicht, diese erste Konsolennachricht nach dem Scrollen nicht zu sehen ...

Bei einem obligatorischen env werden zwangsläufig Boilerplates usw. die env var festlegen, sodass Sie sie einfach verwenden können, fürchte ich: /

Ich glaube ehrlich gesagt nicht, dass console.{error,warn} über console.log irgendetwas geändert hätte.

Glauben Sie, dass es ein Problem ist, wenn Entwickler die Konsole einfach nicht überprüfen oder die Konsole mit Warnungen überladen ist? Könnte dies (teilweise) mit einem allgemeineren Ansatz zur Entwicklerausbildung angegangen werden?

Ich sage auch nicht, dass das Anzeigen eines DOM-Dialogs die Lösung ist. Es ist etwas, womit ich persönlich mich wohl fühlen würde. Wenn es negative Auswirkungen hat, im Entwicklermodus zu bleiben, würden die Benutzer zumindest wissen, dass etwas nicht stimmt, und wahrscheinlich anfangen, auf die Schaltfläche „Hilfe“ oder so etwas zu klicken.

Ich verstehe das, aber ich sage nur, dass ich nicht glaube, dass es eine Lösung ist, geschweige denn die Lösung. Es ist gut, dass Sie damit vertraut sind, aber ich denke, es ist besser, auf Nummer sicher zu gehen und anzunehmen, dass die meisten Benutzer nicht möchten, dass ihren Benutzern unerwartete Fehler angezeigt werden.

Fazit: Ich denke, Frameworks müssen irgendwann ins Gesicht des Entwicklers kommen. Ich würde gerne ein Brainstorming dazu durchführen, um zu sehen, welche Schritte und Kompromisse Autoren von Frameworks bereit sind einzugehen, um zu verhindern, dass Benutzer in Zukunft im Dev-Modus bereitstellen.

Ich bin 💯 dafür, den Entwicklern ins Gesicht zu sehen, aber es ist wichtig, es an der richtigen Stelle zu tun. Für mich ist das der Build-Schritt, nicht die Produktion.

Über die in das DOM eingefügte Nachricht könnte sie mit einem globalen oder so etwas deaktiviert werden. Keine große Sache IMO. Wenn Sie es deaktivieren, bestätigen Sie, dass Sie wissen, was Sie tun.

Es ist genauso schlecht, es standardmäßig aktiviert zu haben, wie es nicht konfigurierbar zu machen: Das Standardverhalten könnte zu unerwartetem Verhalten für den Endbenutzer führen. Wenn überhaupt, sollte es standardmäßig deaktiviert werden, aber das macht den gesamten Zweck zunichte, da Entwickler das anfängliche Problem einfach beheben könnten, sobald sie sich dessen bewusst sind.

Das Problem mit einer Konsolennachricht ist, dass Leute manchmal eine Menge Dinge protokollieren oder andere Warnungen haben, die sie ignorieren, und es ist leicht, diese erste Konsolennachricht nach dem Scrollen nicht zu sehen ...

Ich verstehe das total, die Konsole kann voll werden und es ist leicht, Dinge zu übersehen. Aber es ist genau aus den Gründen, die ich argumentiere, überfüllt: Es ist der Ort, an dem Entwickler Feedback oder Fehler erhalten. Es steht der Benutzererfahrung nicht im Weg, was bei injizierten Nachrichten nicht der Fall ist.

Macht Sinn, ich verstehe die Begründung.

Nun, vielleicht wäre es zumindest etwas, das Ding mithilfe der Konsolenformatierung herausspringen zu lassen.

Das Problem ist, dass sich fast niemand die Konsole in der Produktion ansieht. Sie können dort jede Schriftart verwenden und die Leute werden es nicht bemerken.

Wenn wir jedoch dafür sorgen, dass in der Produktion standardmäßig eine Nachricht als Breaking Change (in 16 oder 17) angezeigt wird, ist sie kaum zu übersehen. Ich meine, es würde passieren, wenn Sie versuchen, es zum ersten Mal bereitzustellen (für neue Benutzer), und bestehende Benutzer sollten die Versionshinweise lesen, wenn sie auf ein neues Major aktualisieren. Ich denke also, es ist machbar, solange wir es sehr deutlich machen und es unmöglich ist, die Botschaft zu übersehen.

Das Problem ist, dass sich fast niemand die Konsole in der Produktion ansieht. Sie können dort jede Schriftart verwenden und die Leute werden es nicht bemerken.

Ich kann nur die Erfahrung des Chrome-Teams damit kommentieren, aber ich würde zustimmen. Die meisten Leute werden Konsolenmeldungen während ihres Iterations-Workflows bemerken, aber ein weitaus geringerer Prozentsatz sieht sich Warnungen auf Produktionsseiten an und weniger reagieren darauf.

Wenn wir jedoch dafür sorgen, dass in der Produktion standardmäßig eine Nachricht als Breaking Change (in 16 oder 17) angezeigt wird, ist sie kaum zu übersehen. Ich meine, es würde passieren, wenn Sie versuchen, es zum ersten Mal bereitzustellen (für neue Benutzer), und bestehende Benutzer sollten die Versionshinweise lesen, wenn sie auf ein neues Major aktualisieren. Ich denke also, es ist machbar, solange wir es sehr deutlich machen und es unmöglich ist, die Botschaft zu übersehen.

Danke, dass du offen für eine solche Veränderung bist, @gaearon. Was wäre nötig, um sich darauf zu einigen, in einer zukünftigen Version standardmäßig eine Nachricht zu versuchen? 😄

Ich stimme zu, dass Konsolenwarnungen nicht die Lösung sind und eine seitensichtbare Warnung viel besser ist.

Die seitensichtbare Warnung könnte:

• Weisen Sie den Entwickler darauf hin, dass sich die Website im Entwicklermodus befindet
• Link zu den Dokumenten zu den Vorteilen und zum Versand ohne
• Ein Link zum Deaktivieren der Nachricht für … ich weiß nicht 2 Stunden?

Das Deaktivieren der Nachricht ist wichtig, da sie möglicherweise etwas auf der Seite stört/verdeckt. Da diese Einstellung im lokalen Speicher gespeichert würde, wird die Warnung weiterhin auf dem Live-Server angezeigt, da es sich um einen anderen Ursprung handelt.

Ja, es ist ziemlich schrecklich, wenn echte Benutzer diese Nachricht auf Live-Sites sehen, aber es fühlt sich an, als würden die Entwickler ermutigt, diese Art von Problem zu beheben, während einige anscheinend glücklich sind, mit den Leistungsproblemen des Entwicklermodus zu leben.

Wenn ich diese Warnung (die Einfügung in DOM) zum ersten Mal in der Produktion gesehen hätte, wäre ich ziemlich verärgert. Die Warnungen müssen rechtzeitig erfolgen.

@rtorr Mein Vorschlag ist, dass es passiert, wenn sich die Site im Entwicklungsmodus befindet, also sollte es im Voraus gesehen werden, es sei denn, ich vermisse etwas?

@jakearchibald Entschuldigung für die Verwirrung, meine Antwort war nicht an deine gerichtet. Ich möchte den Thread nur darauf hinweisen, dass wir, wenn wir die Lösung "insert into the dom" verwenden, sehr vorsichtig sein und sicherstellen sollten, dass die Benutzer wissen, bevor sie etwas verschieben (irgendwie, ich habe hier keine gute Idee). .

Ich sehe nur, wie ein Entwickler eine Einstellung oder so etwas vergisst und das Management ausflippt. Lohnt sich diese Möglichkeit für die Folgen des Entwicklungsmodus in der Produktion?

Eine DOM-basierte Warnung, die ich ständig deaktivieren muss, ist nicht in Ordnung, es muss möglich sein, sie für immer zu deaktivieren, und vielleicht sollte sie für localhost überhaupt nicht angezeigt werden.

Eine Sache, die mich gerade getroffen hat, wenn es möglich wäre, eine Art Flag im Browser zu haben, das Sie aktivieren müssen, um die Devtools zu aktivieren (vielleicht eine große Überlagerung in ihnen mit "Sind Sie ein Entwickler? [Ja/Nein]" ), die die Seite erkennen kann, und zeigt nur die Warnung für Entwickler an. Richtig formuliert könnte es auch bei Selbst-XXS-Angriffen helfen.

Eine DOM-basierte Warnung, die ich ständig deaktivieren muss, ist nicht in Ordnung, es muss möglich sein, sie für immer zu deaktivieren

Das Starten von Websites mit aktiviertem Dev-Modus ist ebenfalls nicht in Ordnung. Vielleicht muss die Nachricht nur einmal am Tag verworfen werden? Aber je länger der Zeitraum, desto wahrscheinlicher ist es, dass es am Ende live geht. Wenn es für immer deaktiviert werden kann, sind wir wieder da, wo wir angefangen haben.

Ich denke auch nicht, dass ein unbeabsichtigter Dom-Knoten in der Produktion in Ordnung ist.

Ich denke, dass wir so oder so immer einen Grenzfall haben werden. Wenn dieses Problem ständig auftritt, ist möglicherweise die Bereitstellung des Dev-Modus falsch. Obwohl es in einer perfekten Welt nicht ideal ist, aber wenn wir den Prod-Modus so wichtig finden, dass wir bereit sind, die Anwendung von jemandem zu ändern, sollte er vielleicht Standard sein und der Dev-Modus sollte aktiviert werden.

@rtorr

Ich denke auch nicht, dass ein unbeabsichtigter Dom-Knoten in der Produktion in Ordnung ist.

Wieso den? (Ich sage nicht, dass du falsch liegst, würde nur gerne deine Gründe hören)

Vielleicht fügen Sie eine Einstellung hinzu, um die prod-Domäne zu definieren. Wenn die prod-Domäne nicht festgelegt ist, erhalten wir immer die Warnung zum DEV-Modus (mit der Aufforderung, die Domänen-URL festzulegen). Wenn sie festgelegt ist, erhalten wir nur eine Warnung, wenn die URL mit der prod-Domäne übereinstimmt. Wir könnten sogar jeden Dienst binden, den wir Entwickler benachrichtigen möchten

Ich freue mich, dass hier konstruktiv diskutiert wird. Es gibt hier zwei Lösungen, die ich sehen kann, um das Problem zu lösen. Webpack könnte die Angabe von NODE_ENV erzwingen, die React dann verwenden könnte, um einfacher zu vermeiden, dass Leute DEV an PROD senden, aber das wäre eine bahnbrechende Änderung für Webpack. Ich spreche jetzt mit Sean darüber, wie machbar so etwas für Webpack 3 sein könnte. Den React + Webpack-Stack anfänger- und leistungsfreundlich zu halten, ist etwas, von dem ich weiß, dass es beiden Lagern am Herzen liegt.

Die zweite (DOM-Injection-Idee) ist etwas, das React tun könnte, und wie Jake erwähnt, die UX ausbalancieren, indem die Nachricht einmal am Tag angezeigt oder verworfen wird. Es ist eine einzeilige Änderung, um das Problem zu beheben, dann müssen Sie nur erneut bereitstellen. Ich kann voll und ganz nachfühlen, dass ich nicht möchte, dass das Management ausflippt.

Wenn wir mehr React-Sites bekommen wollen, die die viel schnellere Erfahrung liefern, an der FB gearbeitet hat, um etwas zu prodieren, muss es vielleicht etwas geben. Wenn jemand bessere Ideen hat, schlagen Sie sie bitte vor.

@jakearchibald

Wieso den? (Ich sage nicht, dass du falsch liegst, würde nur gerne deine Gründe hören)

Zurück zu meinem obigen Kommentar, es sei denn, wir können die Entwickler im Voraus informieren (was das eigentliche Problem zu lösen scheint), finde ich es ziemlich extrem, das Produkt von jemandem abzuwerten, indem eine Warnung für die Entwickler auf ihrer Produktionsseite angezeigt wird. In vielen Fällen könnte dies dem Produkt möglicherweise mehr schaden als der Leistung des Entwicklungsmodus.

Egal, was wir tun, irgendjemand wird das Standardprodukt in die Produktion liefern, warum nicht die Produktion zum Standard machen? Warum nicht den Dev-Modus so weit verbessern, dass er keine so große Wirkung mehr hat?

@rtorr https://twitter.com/sebmarkbage/status/820054247496503296

@jakearchibald Ja, ich sehe, dass beide Seiten Probleme haben. Ich vertraue den Leuten in diesem Thread, dass sie sich etwas Gutes einfallen lassen, auch wenn es das ist, was Sie vorschlagen. Ihr seid alle großartig, FYI. Vielleicht ist extrem die Antwort.

Könnten Sie die DOM-Knoten-Warnung nicht einfügen, wenn der Benutzer die React-Entwicklungstools ausführt, damit normale Benutzer sie nicht bemerken?

@jakearchibald

Das Starten von Websites mit aktiviertem Dev-Modus ist ebenfalls nicht in Ordnung. Vielleicht muss die Nachricht nur einmal am Tag verworfen werden? Aber je länger der Zeitraum, desto wahrscheinlicher ist es, dass es am Ende live geht. Wenn es für immer deaktiviert werden kann, sind wir wieder da, wo wir angefangen haben.

Als die Seite gestartet wurde, entschied jemand, dass sie "bereit" sei, also ist sie zwar schlecht, aber keine Katastrophe. Allerdings müssen Hunderttausende von Entwicklern (möglicherweise kenne ich die genauen Zahlen nicht) eine Site-Zerstörung abweisen (Eine DOM-Warnung muss so behandelt werden, da Sie keine Ahnung haben, wie sie mit dem Rest der Site interagiert und wenn die Website mit sichtbarer Warnung nutzbar ist), ist fünf oder sogar nur eine Warnung pro Tag eine Katastrophe. Die meisten Entwickler haben eine korrekt eingerichtete Build-Kette (benutzerdefiniert, Create-React-App oder andere) und haben überhaupt keine Verwendung für diese Warnung, sie müssen in der Lage sein, sie loszuwerden.

@dan-gamble Ich glaube, dass Entwickler, die React Dev Tools nicht verwenden, das dringendste Ziel für diese Warnung sind.

@Pajn Möglicherweise denke ich nicht, dass Sie automatisch auf den Prod / Dev-Schalter aufmerksam werden, nur weil Sie eine Chrome-Erweiterung herunterladen

@dan-gamble Nein, natürlich nicht. Aber es gibt Leute, die eine ganze App ohne sie entwickeln, was meines Erachtens darauf hindeutet, dass sie Entwicklungstools nicht viel verwenden und daher die aktuelle Warnung für minimierten Code weniger wahrscheinlich sehen.

Normalerweise füge ich einer so langen Diskussion nicht hinzu, wenn ich das Gefühl habe, dass der Punkt bereits gebracht wurde, aber dem muss ich zustimmen und möchte diesen Punkt betonen: Reagieren Sie, indem Sie das DOM berühren und mich warnen, dass ich eine Entwicklerversion verwenden würde ein großer Fehler sein. Soweit ich weiß, gibt es dafür in keinem anderen Rahmen einen Präzedenzfall.

Stellen Sie sich all die Tutorials vor, all die Playgrounds, all die kleinen Nebenprojekte, die den Dev-Modus verwenden, um React zu lehren. Jede einzelne kleine Testseite, die ich zusammenwerfe, um etwas Lustiges in React zu erkunden oder zu versuchen, einen Testfall zu isolieren. Wenn React auf jeder einzelnen dieser Seiten eine Warnung ausgeben würde, die ich manuell deaktivieren müsste, wäre ich unglaublich sauer. Es würde sich wie ein überheblicher Elternteil anfühlen und Sie aktiv davon abhalten, React zu verwenden, denn wenn Sie versuchen, etwas Neues zu tun, schlägt es Sie auf das Handgelenk.

Sogar alle 2 Stunden ? Nein danke. Ein ständiges Nörgeln wie dieses wird Benutzer sicherlich davon abhalten, in React zu entwickeln, und ich denke ehrlich, es würde die Leute davon abhalten, andere Frameworks zu übernehmen. Vielleicht wollen die Chrome-Entwickler das?

Ganz zu schweigen von der Tatsache, dass ja, das irgendwie in die Produktion rutschen wird, und es ist schon schwer genug, bestimmte Teams davon zu überzeugen, React zu übernehmen, und das ist nur mehr Munition für sie dagegen.

Das, was ich an React am meisten liebe, ist, dass es nichts tut, bis Sie ReactDOM.render(...) anrufen, und wenn Sie das tun, es nur Sachen in das DOM legt, wo Sie es gesagt haben. Deshalb ist es eine so gute, isolierte, funktionale Bibliothek.

Müssen wir auch erkennen, ob Personen ein nicht verkleinertes Paket versenden? Was ist, wenn sie nicht cachen, wenn sie sollten? Was ist, wenn sie nginx nicht optimal konfiguriert haben? Oder verwenden Sie shouldComponentUpdate nicht, wenn sie sollten? Oder rendern sie unnötigerweise alles, wenn sie es nicht müssen?

Es gibt mehrere Gründe für eine schlechte Leistung und es ist falsch, die Schuld ausschließlich dem Dev-Modus von React zuzuschreiben. Wenn Sie eine Website bereitstellen, wird unbedingt erwartet, dass Sie verstehen, wie eine optimierte Website bereitgestellt wird. Ich sage nicht, dass wir nichts tun können, aber der Hauptgrund dafür ist, dass Benchmark-Autoren ihrer Due Diligence nicht nachkommen, und wir sollten dafür nicht bezahlen müssen. Wir müssen einen anderen Weg finden, das auszurufen.

Ich wollte mit der meiner Meinung nach richtigen Lösung weitermachen: diese Art von Einschränkungen in die Tools einzubauen. Stellen Sie sicher, dass Webpack oder ein anderes Tool, das Sie zum Erstellen Ihrer Website für die Produktion verwenden, der Ort ist, an dem wir diese Überprüfungen erzwingen sollten.

In Bezug auf das Erzwingen einer NODE_ENV-Einstellung durch das Webpack (vielleicht gibt es dafür bereits ein Problem in ihrem Repo), würde es das nicht schwieriger machen, Bibliotheken zu verwenden, die nicht auf env-Einstellungen angewiesen sind?

Oder ist die Idee, dass es die Verwendung von NODE_ENV erkennen und nur dann erzwingen würde, wenn der Code es verwendet?

Lassen Sie uns nicht zu sehr auf die "2 Stunden"-Sache aufhängen. Es könnte ein beliebiger Zeitraum sein, solange es funktioniert.

Darüber hinaus bedeuten lokale Speicherereignisse, dass sie nur einmal pro Ursprung verworfen werden müssen. Wenn Sie mehrere Demos auf einer Seite haben, würde das Schließen einer Demo die anderen schließen.

Wenn die Warnung live schlüpft, ist sie laut genug, um eine schnelle Lösung zu rechtfertigen - eine, die den Benutzern zugute kommt. Wenn wir uns Sorgen darüber machen, wie React in der Öffentlichkeit aussieht, möchten wir unbedingt eine unnötige Verlangsamung wie diese vermeiden.

Sicher, dies würde keine fehlerhaften Caching-Header usw. erkennen, hier geht es nur darum, den "Entwicklungsmodus" zu erkennen. Auch „schiefe Wege“-Argumente sind nicht hilfreich.

Ich denke nicht, dass es sinnvoll ist, das Problem in Build-Tools zu verschieben, da Sie dasselbe Problem haben, wenn Entwickler ein anderes Build-Tool verwenden oder dieses nicht in den Produktionsmodus versetzen. Frameworks im Dev-Modus erzeugen bereits Konsolenwarnungen, und das funktioniert eindeutig nicht.

Hier geht es nicht nur um Benchmarks, sondern um echte Websites, die für echte Benutzer langsam laufen, weil ein Schalter nicht geschaltet wurde.

@jakearchibald Danke für die rationale Antwort auf meine emotional aufgeladene. Ich denke, es ist ein berechtigter Punkt, dass es viele Gründe gibt, warum eine Website mit React langsam sein könnte. Ich würde gerne sehen, wie wir Leistungsverbesserungen vorschlagen können, die besser sind als eine grobe Überprüfung des Entwicklermodus und eine In-Browser-Warnung. Wenn wir Tools hätten, um eine React-App zu analysieren und ernsthafte Vorschläge zur Leistung zu machen, von allem wie dem Entwicklungsmodus bis zu zu vielen Neurenderings, wäre das viel nützlicher. Ein solches generisches Tool kann in jede Pipeline eingebunden werden, sei es Webpack, Browserify usw.

Dies ist jedoch das Wichtigste, was ich sagen wollte: An manchen Tagen werde ich den React-Entwicklermodus an 5-10 verschiedenen Orten verwenden, wie z. B. jsbin, Tutorials und sogar das Zusammenwerfen einer kleinen Testsite und das Öffnen mit dem file://-Protokoll. Eine erzwungene In-Browser-Warnung steht dieser Art flexibler Entwicklung, die das Web so auszeichnet, feindlich gegenüber. Ich würde diese Warnungen überall sehen, weil ich domänenübergreifendes Reagieren im Web lerne.

Wenn die Warnung live schlüpft, ist sie laut genug, um eine schnelle Lösung zu rechtfertigen - eine, die den Benutzern zugute kommt. Wenn wir uns Sorgen darüber machen, wie React in der Öffentlichkeit aussieht, möchten wir unbedingt eine unnötige Verlangsamung wie diese vermeiden.

Selbst die Möglichkeit zuzulassen, dass Endbenutzern eine entwicklerspezifische Warnung angezeigt wird, erscheint mir nicht akzeptabel. Eine langsame Website ist eine Sache, aber eine Nachricht wie diese könnte das Vertrauen der Benutzer untergraben, insbesondere bei sicherheitsorientierten Websites (würden Sie sich freuen, wenn Ihre Banking-Website plötzlich kryptische Fehler anzeigen würde?) Wäre Google mit all ihren einverstanden Benutzer plötzlich diese Warnung erhalten, wenn auch nur für einen Moment?

Darüber hinaus bedeuten lokale Speicherereignisse, dass sie nur einmal pro Ursprung verworfen werden müssen. Wenn Sie mehrere Demos auf einer Seite haben, würde das Schließen einer Demo die anderen schließen.

Sie können sich nicht darauf verlassen, dass localStorage dies dedupliziert. Es gibt keine Garantie dafür, dass localStorage (oder andere lokale persistente Daten) nicht in jedem Intervall gelöscht werden.

edit : Indem Sie den Fehler nur einmal alle {INTERVAL} anzeigen, haben Sie es jetzt viel schwieriger gemacht, ihn zu reproduzieren und zu debuggen, da er nicht deterministisch reproduzierbar ist.

Es gibt 2 Fälle, die gelöst werden müssen:

• Verhindern Sie falsche Benchmarks, Leistungstests: Leicht gelöst mit einer großen großen Konsolenmeldung.
• Verhindern Sie den Versand von DEV an Produktionsstandorte: Die Leute öffnen keine devtools in prod.

Argumente gegen das Berühren des DOM sind überzeugend.

Wenn es eine große, auffällige, offensichtliche Konsolenwarnung gibt, besteht die Möglichkeit, dass die Leute vor dem Versand an die Produktion die Entwicklerversion verwenden und diese wirklich offensichtliche Konsolennachricht sehen. Oder vielleicht wurde ein Teil des Codes bereits an die Produktion geliefert, aber für ein anderes Projekt werden sie die nächste Reaktionsversion mit dieser unmöglich zu übersehenden Konsolennachricht verwenden. Vielleicht erinnern sie sich an die Site, die sie in die Produktion geschickt haben, und prüfen, ob dort DEV aktiviert ist.

Die Konsolenbotschaft wäre lehrreich, so wie jeder, der React entwickelt, weiß, dass DEV etwas wirklich Wichtiges hat, und sie sehen es jedes Mal, wenn sie React für die Entwicklung verwenden.

Ich war zögerlich bei https://github.com/facebook/react/pull/8782 , weil die Leute im Allgemeinen keine Warnungen mögen, die sie nicht loswerden können (siehe https://github.com/facebook/react/issues/ 3877), aber unter Berücksichtigung der Alternativen könnte es eine akzeptable Lösung sein.

Neugierig. Würde die Verwendung von localStorage das EU-Cookie-Gesetz auf einer Website geltend machen, die ansonsten nicht darunter fällt?

Wenn informative Warnungen während der Entwicklung eine gute Idee sind, warum tun es dann andere Bibliotheken nicht? Nun, ein Grund sind Probleme wie diese. Wenn andere dies tun wollten, sollten sie auch ähnliche UIs anzeigen? Muss man alle schließen?

Es scheint mir, dass es ideal wäre, etwas Zentraleres zu haben, um dies zu handhaben.

Vielleicht könnte Chrome einen Entwicklungsmodus haben? Bibliotheken könnten dem Host mitteilen, dass sie sich im Entwicklungsmodus befinden, und Chrome könnte dann ein Abzeichen hinzufügen oder ein Popup-Fenster öffnen, um dies anzuzeigen.

Lässt mich denken, dass die React-Devtools-Erweiterung genutzt werden könnte, um eine Benachrichtigung oder etwas Offensichtliches anzuzeigen, wenn eine Seite mit React im Dev-Modus geöffnet wird?

@sebmarkbage

Wenn informative Warnungen während der Entwicklung eine gute Idee sind, warum tun es dann andere Bibliotheken nicht?

Ich denke, jemand muss der Erste sein. Angular hat ein ähnliches Problem mit Sachen wie http://code.gov , die im Entwicklermodus gestartet werden. Wenn React anfängt, dieses Zeug zu fangen, wo andere Frameworks dies nicht tun, werde ich darauf drängen, dass sie ähnliche Änderungen vornehmen.

Ich werde darauf drängen, dass sie ähnliche Änderungen vornehmen.

@jakearchibald schlagen Sie vor, dass jedes Framework seine eigene Warnung bereitstellen sollte? Ich denke nicht, dass es eine großartige Idee ist, den Standard für Frameworks/Bibliotheken festzulegen, die ihre eigenen Entwicklungswarnungen in der Produktion bereitstellen. Sollten wir nicht versuchen, die Plattform zu standardisieren? Wie von @sebmarkbage erwähnt

Vielleicht könnte Chrome einen Entwicklungsmodus haben? Bibliotheken könnten dem Host mitteilen, dass sie sich im Entwicklungsmodus befinden, und Chrome könnte dann ein Abzeichen hinzufügen oder ein Popup-Fenster öffnen, um dies anzuzeigen.

Ich denke, das ist eine großartige Idee. Präzedenzfall: Safari verfügt über einen separaten Modus, den Sie aktivieren müssen, um auf DevTools zuzugreifen. Wenn Chrome dasselbe tun würde, könnte es auch sicher einen Indikator für den DEV-Modus und eine API hinzufügen, um ihn auszulösen. Dieser Indikator wäre nur für Entwickler sichtbar, damit er die Benutzererfahrung nicht stört.

Wird es nicht dauern, bis Browser-Anbieter so etwas implementieren?

@jide ja, aber es ist wichtiger, dieses Problem richtig als schnell anzugehen. Außerdem kann es in einem einzelnen Browser implementiert werden, bevor Standardisierungsbemühungen (falls erforderlich) in Betracht gezogen werden.

@awary

Schlagen Sie vor, dass jedes Framework seine eigene Warnung bereitstellen sollte?

Angesichts der Tatsache, dass jedes Framework seinen eigenen Entwicklungsmodus bereitstellt (und dieser Modus zwischen Frameworks sehr unterschiedlich sein kann), erscheint es völlig fair, dass das Framework die Warnung auf ähnlich einzigartige Weise implementieren sollte.

Browser haben einige Anstrengungen unternommen, um zu vermeiden, dass devtools der Seite ausgesetzt werden. Wenn wir Devtools hier zur Eintrittsbarriere machen, werden wir viele Benutzer übersehen, die eine DOM-Warnung nicht übersehen würde. Eine DOM-Warnung scheint nicht nur einfacher zu sein, sie hat auch weniger Plattformabhängigkeiten und wird mehr Entwickler erreichen. Einfacher & effektiver klingt nach Gewinn.

@gaearon Auf der Seite der Chrome DevTools haben wir ein Brainstorming für eine Live-API für „Verletzungen“ entwickelt, die Autoren von Webplattformen und Frameworks verwenden könnten, um wichtige Warnungen zu signalisieren. Diese würden irgendwo wie bei der bevorstehenden Aktualisierung des Audits-Panels präsentiert. Es klingt ähnlich wie Ihre Frage und könnte verwendet werden, um eine Warnung bei der Erkennung des DEV-Modus auszulösen.

Für diese spezielle Ausgabe sind Sie vielleicht hinter etwas lauterem her, als wir ursprünglich geplant hatten. Ein Bereich für Verstöße erfordert ähnlich wie Konsolenprotokollmeldungen, dass Sie wissen, dass ein Bereich Einblicke geben wird. Vielleicht gibt es zusätzlichen UX-Raum für etwas, das ein gut sichtbares Seiten-Overlay weiter unten auf der Seite anzeigt, für das Frameworks das Messaging standardisieren könnten. @paulirish und @s3ththompson für ihre Gedanken nach dem Feiertagswochenende.

Fwiw, ich vermute, diese API wird erst in ein paar Monaten fertig sein. Wenn dies der Fall ist, wird es zunächst nur auf Canary verfügbar sein und 6-7 Wochen später könnte es seinen Weg in die stabile Version finden.

Eine DOM-Warnung erscheint nicht nur einfacher, sondern auch effektiver.

Da stimme ich Jake zu. Lassen Sie uns weiter über die DevTools-Lösung plaudern, aber ich würde auch gerne herausfinden, was React als Fallback tun könnte, falls die API nicht Ihren Anforderungen entspricht oder zeitlich weiter entfernt ist.

Angesichts der Tatsache, dass jedes Framework seinen eigenen Entwicklungsmodus bereitstellt (und dieser Modus zwischen Frameworks sehr unterschiedlich sein kann), erscheint es völlig fair, dass das Framework die Warnung auf ähnlich einzigartige Weise implementieren sollte.

@jakearchibald ist Ihnen klar, dass die Einstellung, dass Standard bedeutet, dass Seiten, die mehrere Frameworks (oder Bibliotheken, die in der Suite folgten) verwenden, dazu führen können, dass Endbenutzern eine beliebige Menge nicht deterministisch gerenderter kryptischer Warnungen angezeigt wird?

Browser haben einige Anstrengungen unternommen, um zu vermeiden, dass devtools der Seite ausgesetzt werden.

Und ich bin mir sicher, dass der Grund zumindest teilweise darin liegt, dass entwicklerspezifische Nachrichten Endbenutzern nicht zugänglich gemacht werden sollten.

Eine DOM-Warnung erscheint nicht nur einfacher, sondern auch effektiver.

Niemand spricht gegen die Einfachheit oder Effektivität der Lösung. Es würde funktionieren , aber auf Kosten der Benutzererfahrung. Geschwindigkeit ist nicht das einzige, was Benutzer negativ beeinflussen kann.

Fwiw, ich vermute, diese API wird erst in ein paar Monaten fertig sein. Wenn dies der Fall ist, wird es zunächst nur auf Canary verfügbar sein und 6-7 Wochen später könnte es seinen Weg in die stabile Version finden.

@addyosmani Wenn es eine bessere Lösung ist, sehe ich nicht, wie das ein Problem wäre. Alle Änderungen an React würden in einer Hauptversion erfolgen, was meiner Meinung nach sowieso TBD ist, was das Release-Timing betrifft.

Die beschlossene Lösung wird möglicherweise alle zukünftigen Entwicklungen beeinflussen. Eine Frage von Wochen oder Monaten ist in diesem Zusammenhang meiner Meinung nach akzeptabel.

Ich verstehe, dass einige Entwickler sich angegriffen fühlen, wenn ein Framework etwas in ihr DOM einfügt, das sie nicht selbst dort abgelegt haben. Aber ich denke, dass ein Banner unten auf der Seite mit der Aufschrift „Diese Website befindet sich im DevMode“ eine großartige Lösung dafür wäre, die keinen großen Einfluss auf die Benutzererfahrung hat. Ich würde gerne verstehen, warum viele Leute das Gegenteil denken.

@aweary : Wenn eine „sicherheitsorientierte“ Website jemals im DevMode gestartet wird, sollte ihr nicht vertraut werden, bis sie das Problem behoben hat. „DevMode“ könnte alle Arten von sicherheitsbezogenen Verknüpfungen wie deaktivierte CORS-Prüfungen oder offengelegten Vorlagenquellcode usw. enthalten. Wenn eine Website sicherheitsorientiert ist, _darf_ dies nicht passieren.

(Mir ist klar, dass „DevMode“ in React eine sehr spezifische Bedeutung hat, aber ich versuche hier, die Perspektive eines Nicht-Entwicklers einzunehmen.)

@awary

Ist Ihnen klar, dass das Festlegen dieses Standards bedeutet, dass Seiten, die mehrere Frameworks verwenden, dazu führen können, dass Endbenutzern eine beliebige Menge nicht deterministisch gerenderter kryptischer Warnungen angezeigt wird?

Das ist mir absolut klar. Eine Seite mit mehreren Frameworks im Dev-Modus wird die Benutzererfahrung ohne triftigen Grund stark beeinträchtigen. Es scheint, dass es Ihnen lieber ist, wenn es unbemerkt und unkorrigiert bleibt. Mir wäre lieber, dass es für Nicht-Entwickler so schlecht ist (sichtbare Nachrichten, die an Entwickler gerichtet sind), dass der Entwickler es umgehend behebt und eine viel bessere Benutzererfahrung schafft.

Geschwindigkeit ist nicht das einzige, was Benutzer negativ beeinflussen kann.

Ich sehe niemanden, der etwas anderes behauptet? Ich bin ziemlich traurig über diese Art von Reaktion 😞

Es scheint, dass es Ihnen lieber ist, wenn es unbemerkt und unkorrigiert bleibt

@jakearchibald das ist irgendwie eine seltsame Schlussfolgerung, ich glaube nicht, dass ich meine Freizeit hier verbringen würde, um mit dir zu reden, wenn ich nicht wollte, dass das behoben wird? Nur weil ich mit Ihrer Lösung nicht einverstanden bin, heißt das nicht, dass ich mich damit abgefunden habe, sie ungelöst zu lassen. Das ist wirklich ungerecht.

Mir wäre lieber, dass es für Nicht-Entwickler so schlecht ist (sichtbare Nachrichten, die an Entwickler gerichtet sind), dass der Entwickler es umgehend behebt und eine viel bessere Benutzererfahrung schafft.

Das ist meiner Meinung nach grundsätzlich inakzeptabel: Sie bestrafen die Benutzer zuerst explizit.

Wenn eine „sicherheitsorientierte“ Website jemals im DevMode gestartet wird, sollte ihr nicht vertraut werden, bis sie das Problem behoben hat.

Der @surma -Entwicklermodus ist nicht von Natur aus unsicher, aber unabhängig davon geht er über die Grenze, um anzunehmen, dass es in Ordnung ist, wenn Sie dies den Benutzern mitteilen.

Ich denke nicht, dass eine Lösung, die das Öffnen oder Aktivieren von Entwicklungstools erfordert, ausreichend ist. Damit dies bemerkt wird, muss es für QA, Management und möglicherweise Endbenutzer sichtbar sein. Entwickler sind zu sehr daran gewöhnt, dies zu sehen. Ähnlich wie problematische SSL-Konfigurationen hervorgehoben werden. Es muss nicht viel sein, aber genug, um zu bemerken, dass jemand danach fragt und es dann repariert.

Das Injizieren in das DOM ist aus vielen Gründen problematisch. Für React ist es etwas praktikabler, da wir eine DOM-Bibliothek sind und DOM-Einstiegspunkte haben. Es ist schwieriger für Bibliotheken, die nicht DOM-spezifisch sind und möglicherweise in einem Worker ausgeführt werden.

Eine Sache, die wir möglicherweise tun können, ist das Favicon zu ändern, solange wir eine Möglichkeit bieten, es explizit zu überschreiben. Viele Seiten haben bereits separate Favicons für den Entwicklungsmodus.

Wir müssen eine Standarderfahrung für die Behandlung von Fehlern in React finden, die möglicherweise nicht in der Lage ist, das DOM an Ort und Stelle zu halten. Die aktuelle Standardimplementierung im Master löscht React-Inhalte aus dem Baum, wenn ein Fehler ausgegeben wird. Das ist auch invasiv.

Wenn wir feststellen könnten, dass Sie sich nicht im Entwicklungsmodus befinden, könnten wir diesen Fehlermodus auslösen. Wir brauchen dann wirklich eine solide Möglichkeit, uns dauerhaft für einen Entwicklungsmodus zu entscheiden.

Ähnlich wie problematische SSL-Konfigurationen hervorgehoben werden.

Das ist genau das, was ich für perfekt halte. Benutzer sind bereits daran gewöhnt, dass Browser Sicherheitsinformationen über von ihnen besuchte Websites bereitstellen, Leistungsinformationen sind von dort aus kein großer Sprung mehr. Außerdem wäre es für alle Frameworks/Bibliotheken konsistent, die potenzielle Leistungsprobleme melden, und würde den Benutzerworkflow nicht direkt beeinträchtigen. 👍

Ich mag die Favicon-Idee: Auffällig, funktioniert ohne Devtools oder Erweiterung, von allen wahrnehmbar, schadet den Benutzern nicht, kann animiert werden, um Aufmerksamkeit zu erregen, nervig genug, dass Entwickler verschwinden wollen.

Was ist mit der Aktivierung des DEV-Modus?
Wir irren uns auf der „guten UX“-Seite, weil schlechte DX leichter zu bemerken ist (und meiner Meinung nach sollten Benutzer bei Problemen wie diesem „gewinnen“, weil sie nicht wählen können, während Entwickler es können).
Ich bin mir sicher, dass einige Frameworks dies bereits tun (wie Relay, wenn ich mich richtig erinnere).

Vorschläge zur Umsetzung:

• Aktivieren Sie den Entwicklungsmodus nur, wenn NODE_ENV explizit auf development gesetzt ist
• Aktivieren Sie den Entwicklungsmodus, wenn das globale __DEV__ === true ist
• Exportieren Sie ein Debug-Tool-Modul, das im Userland aktiviert werden soll

Die erste scheint die beste zu sein, da die anderen beiden ohne Wächter fest codiert sein können (z. B. eine if(NODE_ENV === 'development') -Anweisung) und daher trotzdem an die Produktion gesendet werden.

@mattecapu Siehe meinen zweiten Kommentar bzgl. https://twitter.com/sebmarkbage/status/820047144677584896

Wenn es einen ähnlichen Weg gibt, um zu erzwingen, dass Entwickler mit der Ausführung im DEV-Modus beginnen, spielt es keine Rolle, was die Standardeinstellung ist. Aber es ist wirklich schlimm, wenn man zurückfällt.

Hier gibt es eine Menge zu kommentieren, und ich habe Gedanken, aber ich möchte mich speziell zu der Frage äußern, wie man eine Entwicklerwarnung deaktiviert.

Ich bin kein großer Fan einer Schaltfläche, die eine DOM-Warnung für eine bestimmte Zeit in einem bestimmten Browser deaktiviert. Wie @jlongster betont , ist es für Entwickler ein Problem, wenn es häufig vorkommt. Aber noch wichtiger für mich ist, dass es eine browserspezifische Variabilität im Verhalten einführt, die leicht dazu führen kann, dass Fehler nicht reproduziert werden können, "aber es funktioniert auf meinem Computer gut".

Ich bevorzuge einen an Render gesendeten Parameter, der Domains auflistet, die als Dev-Boxen gelten, mit einem Standardwert von ["localhost", "127.0.0.1"] . Es würde in etwa so aussehen:

React.render(<App/>, 
  myDiv,
  () => { console.log('finished render!'), 
  { devDomains: ["localhost", "devbox.mycorp.com"] }
);

Wenn sich die aktuelle Domain in der Liste befindet, wird die Entwicklerwarnung nie angezeigt. Ansonsten tut es das. Unter diesem Regime:

• Verwenden von dev build auf Ihrem lokalen Computer mit localhost oder 127.0.0.1 : Keine Entwicklerwarnung jemals und keine Entwickleraktion erforderlich.
• Verwenden von dev build auf einem Entwicklungscomputer mit einem anderen Hostnamen : Sie erhalten die DOM-Warnung, bis Sie den Domänennamen zu der an render übergebenen Liste hinzufügen. Danach erhalten Sie nie die DOM-Warnung.
• Verwenden des dev-Builds auf einer prod-Maschine : Sie erhalten die DOM-Warnung, bis Sie React auf die prod-Version umstellen.

Das einzige, was mich an dieser Lösung beunruhigt, ist, dass sie dazu führen könnte, dass Entwickler eine Liste aller ihrer Dev-Server-Domänen im Code hinterlassen, und dieser Code kann es in die Produktion schaffen. Für Unternehmen, die ihre Dev-Server-Domains als geheim betrachten, wäre das ein Problem. Die Gedanken?

@aickin Das Problem bei diesem Ansatz besteht darin, dass Benutzer sich der Konfiguration und damit des zu lösenden Problems bewusst sein müssen. Das Problem ist, dass die Leute sich der Unterscheidung zwischen Dev und Prod gar nicht bewusst sind.

Bearbeiten : Egal, wie ich sehe, befindet sich noch eine DOM-Warnung in der Entwicklung.

Serverseitige Umgebungen beheben dies, indem sie eine „spezielle“ Fehlerseite anzeigen, die Debug-Details enthält und Ihnen auch mitteilt, sie nicht in der Produktion bereitzustellen.

Da wir planen, React schnell zum Scheitern zu bringen und Ansichten aufzuheben, es sei denn, Sie stellen eine benutzerdefinierte Fehlergrenze bereit, können wir in der Entwicklung genauso gut eine standardmäßige „rote Box“-Fehlergrenze hinzufügen, die als Lernseite fungiert.

Wenn der Benutzer dann zum ersten Mal einen Fehler in der Produktion hat, wird ihm eine spezielle ausführliche Fehlermeldung angezeigt. Dies könnte eine Gelegenheit sein, über den DEV-Build aufzuklären.

Aber ich denke, dass ein Banner unten auf der Seite mit der Aufschrift „Diese Website befindet sich im DevMode“ eine großartige Lösung dafür wäre, die keinen großen Einfluss auf die Benutzererfahrung hat. Ich würde gerne verstehen, warum viele Leute das Gegenteil denken.

Die meisten Benutzer mögen Web-Apps nicht, wenn sie wissen, dass es sich um eine Web-App handelt. Warum? Denn eine früher verbreitete Mentalität des Webs war, dass es erledigt ist, wenn es auf dem Bildschirm erscheint, egal wie schlecht es sich benommen hat und die Benutzer gelernt haben, dass das Web schlecht ist. Es ist jedoch durchaus möglich, eine großartige UX im Web zu erstellen, aber dazu muss ich das DOM besitzen. Wenn jemand zufällige Banner an beliebigen Stellen einfügt, kann das falsche Element anfangen zu scrollen, oder es kann dazu führen, dass der gesamte Bildschirm beim Scrollen neu gezeichnet wird, oder es kann beispielsweise mit Ziehgesten oder etwas anderem interferieren. Der Punkt ist, solange dieses Banner hoch ist, kann ich mich nicht entwickeln, weil ich nicht wissen kann, dass die Erfahrung dieselbe ist, wenn dieses Banner weg ist.

Als Framework-Lösung gefällt mir die Favicon-Idee sehr gut, es behindert die Entwicklung nicht, es sieht für Benutzer nicht zu seltsam aus, es zerstört möglicherweise nicht die UX, aber es wird bemerkt. Es funktioniert jedoch zu diesem Zeitpunkt wirklich nur für eine einzelne Bibliothek oder ein einzelnes Framework und überhaupt nicht für Bibliotheken, die in Workern ausgeführt werden. Die wirkliche Lösung ist eine gute Möglichkeit, dies über den Browser zu tun, der mehrere Frameworks und Bibliotheken unterstützen kann und auf den von allen Kontexten aus zugegriffen werden kann.

Eine andere Lösung, die mehrere Frameworks und Bibliotheken unterstützt und klarer ist, aber eine Berechtigungsanfrage erfordert, besteht darin, eine Browserbenachrichtigung anzuzeigen.

Hier ist eine Idee: Aktualisieren Sie die Dokumente zu den ersten Schritten auf der Homepage von React, um die Erstellung von React-Apps stärker voranzutreiben. Und betonen Sie die Bedeutung des npm-Builds in diesen Dokumenten. Wir brauchen keine DOM-Warnung, wir brauchen Bewusstsein.

Ich denke, @ropilz hat dies früher im Thread mit seinem Kommentar "_..wir könnten sogar jeden Dienst binden, den wir Entwickler benachrichtigen wollen.._" angesprochen, aber es ist möglicherweise unbemerkt geblieben (oder nicht zur Kenntnis genommen).

So wie ich es verstehe, ist das grundlegende Problem, das hier gelöst wird

• um _Entwickler_ irgendwie zu warnen, wenn Produktions -_Endbenutzer_ feststellen , dass eine Site im Entwicklungsmodus läuft
• wir können uns nicht darauf verlassen, dass Entwickler in der Produktion console.log -Meldungen (oder sogar DOM-Warnungen) sehen, _es sei denn_, diese Entwickler nutzen die Produktionsseite aktiv selbst (oder wir verlassen uns auf Endbenutzer, QA/ Supportteams usw., um diese Warnungen an den Entwickler zurückzumelden)
• Es gibt (gültige) UX-Argumente _gegen_, die Endbenutzern eine DOM-sichtbare Warnung zeigen, die für Entwickler gedacht ist.

Was wäre, wenn es etwas Analoges zu report-uri von CSP gäbe, damit Frameworks Warnungen im Entwicklungsmodus senden können, anstatt eine Warnung vor Ort auf der Website anzuzeigen, wo sie für Endbenutzer sichtbar wären?

Natürlich gibt es eine Reihe von Dingen zu beachten, wie zum Beispiel:

1. Solche Berichte wären idealerweise standardmäßig aktiviert, aber was wäre die Standardeinstellung report-uri ? (Würden wir erwarten, dass jedes Framework seinen eigenen kostenlosen Dienst hostet, ähnlich wie https://report-uri.io? (Dies _kann_ für große, von Unternehmen gesponserte Frameworks wie React & Angular möglich sein; aber sicherlich unpraktisch für kleinere Open-Source-Frameworks wie Preact, Vue usw.)
2. Wie wird der Eigentümer/Entwickler der Website benachrichtigt, nachdem eine Warnung gemeldet wurde? (Vielleicht eine gute Möglichkeit für Nicht-Entwickler, sich an einem Projekt zu beteiligen, indem sie sich freiwillig melden, um diese Berichte zu überwachen und dabei zu helfen, den Betreuer aufzuspüren/zu benachrichtigen?)

Ich gebe zu, dass dieser Vorschlag nur eine Gedankenblase ist, und ich habe nicht darüber nachgedacht, wie praktisch das wäre oder wie es tatsächlich funktionieren würde; aber ich wollte es ansprechen, da mir scheint, dass die Herausforderung der „Berichterstattung über Produktionsprobleme“ für die CSP/HPKP-Berichterstattung bereits teilweise gelöst wurde, und vielleicht könnten wir hier etwas Ähnliches untersuchen?

Es ist wichtig, einen Schritt zurückzutreten und zu erkennen, dass React ein Framework ist. Sie dürfen nicht :

• Ändern Sie das DOM, um etwas visuell darzustellen, nur als Erinnerung für Entwickler . Es gibt keine Möglichkeit, dass dies sofort gut funktioniert, es sei denn, Sie verstehen und entwickeln etwas, das in allen Umgebungen funktionieren kann, ohne die Entwickler zu behindern und das Vertrauen ihrer Benutzer zu verlieren, falls es in der Produktion auftauchen sollte (wenn meine Erfahrung darauf hindeutet, dass dies passieren wird). ziemlich häufig und viele werden nicht in der Lage sein, eine schnelle Lösung bereitzustellen, um es auszuschalten).

• Ändern Sie das Favicon. Das Favicon wird ärgerlicherweise zwischengespeichert, für Lesezeichen, gespeicherte Web-App-Symbole auf Mobilgeräten verwendet, wenn keine anderen angegeben sind usw. Dadurch besteht die Gefahr, dass eine versehentliche (oder absichtliche) Produktionsbereitstellung im Entwicklungsmodus das Logo einer Marke löscht.

• Browser-Benachrichtigungen. Wenn Sie angeschaut werden, werden Sie wahrscheinlich von einem Benutzer angeschaut. Das Aufklappen einer Benachrichtigung wird Browserberechtigungen anfordern und seltsame Dinge auftauchen, die Benutzer nicht verstehen werden. Die Annahme, dass diese hauptsächlich von Entwicklern gesehen würden, ist meiner Erfahrung nach genau umgekehrt und möglicherweise vertrauenszerstörend für Benutzer.

Es ist nicht die Aufgabe von React, Entwickler zu babysitten. Ich schlage entweder vor:

1. Aktivieren Sie den Entwicklungsmodus. Wenn die Entwickler feststellen, dass sie etwas nicht debuggen können, schauen sie nach, wie sie es einschalten können (was überall dokumentiert werden muss). Nein, es ist nicht die Aufgabe von React, ihnen zu sagen, dass sie es wieder ausschalten sollen. Ihr Problem.

2. Belassen Sie es bei einer einfachen console.log-Nachricht (und diese muss deaktiviert werden können). Lassen Sie Entwickler es finden und handhaben. Wenn nicht, na ja. Sie können nicht jede Organisation erreichen und sie dazu bringen, die Dinge richtig zu machen. Es ist einfach nicht skalierbar.

Ich muss dem Berühren des DOM widersprechen, um eine Warnung anzuzeigen. Es sieht für React einfach und simpel aus, weil es eine DOM-Bibliothek ist, aber stellen Sie sich vor, alle Bibliotheken müssten ihre eigene Warnung im DOM anzeigen. Es wird ein totales Durcheinander.

Es gibt so viele Bibliotheken, die Entwickler verwenden, die wahrscheinlich ihren eigenen Entwicklungsmodus haben. Ich denke, das Setzen process.env.NODE_ENV auf production ist bereits ein gängiger Standard beim Bündeln von Modulen für Browser. Dafür müssen wir das Bewusstsein schärfen.

Ich stimme zu, dass die React-Dokumentation nicht deutlich zeigt, dass es einen Unterschied zwischen Dev- und Production-Build gibt. Wenn Sie die Dokumentation öffnen, müssen Sie die Advanced Guides durchgehen, um den Unterschied zwischen Dev- und Production-Build zu lesen. Der Titel lautet Optimizing Performance , etwas, das Anfänger definitiv nicht anschauen werden, weil sie React verwenden, weil sie gehört haben, dass es schnell ist. Ich denke, die Dokumentation könnte verbessert werden, um eine weitere Dokumentation mit dem Titel "Using React in Production" oder ähnlichem im Abschnitt " Schnellstart " zu haben.

Anfänger lesen normalerweise keine erweiterten Handbücher, aber sie öffnen einige Links im Schnellstart, wenn der Titel klar genug ist und wichtig erscheint. Ich weiß, dass ich es getan habe, weil ich das mache, wenn ich anfange, React zu lernen. Ich habe die Anleitung „Erste Schritte“ nicht gelesen, aber ich habe einige Seiten im Abschnitt „Schnellstart“ gelesen.

Ein anderer Ansatz, den wir verfolgen könnten, ist das Anzeigen einer Warnung in der Konsole, wenn React im Entwicklermodus verwendet wird, mit einem Link, um diesen Punkt in den Dokumenten zu beheben. Das Öffnen der Konsole in der Produktion für Entwickler ist ungewöhnlich, aber in der lokalen Umgebung werden sie beim Entwickeln sicherlich die Konsole öffnen. Auf diese Weise werden sie sich bei der lokalen Entwicklung bewusst, dass sie etwas tun müssen, bevor sie für die Produktion veröffentlichen.

http://code.gov wurde trotz Konsolenwarnungen gestartet. Genau das sollten wir verhindern. (Diese Seite ist Angular, aber das gleiche gilt für React)

Hier ist die Ausgabe für code.gov, falls jemand sie erreichen (oder eine PR senden möchte): https://github.com/presidential-innovation-fellows/code-gov-web/issues/221

Angular 2 is running in the development mode. Call enableProdMode() to enable the production mode.

Ich habe Angular 2 noch nie benutzt (was mich in diesem Fall zum Anfänger macht). Meine erste Reaktion, nachdem ich die Warnung gesehen habe, ist , dass ich einfach versuche, enableProdMode() . Es funktioniert nicht. Ich denke, die Konsolennachricht für Angular Case könnte verbessert werden. Anstatt sich auf Magie zu verlassen, sollten sie auf die Dokumente verweisen.

Wenn ich die Angular-Dokumente öffne, sehe ich nichts über den Produktionsaufbau. Ich denke, das ist ein Problem sowohl für Angular als auch für React. Beide verwenden den Dev-Modus, aber sie sagen den Leuten in den Dokumenten nicht, wie sie ihn deaktivieren können. Aus diesem Grund könnte die Verbesserung der Dokumentation einen großen Beitrag zur Schulung von Entwicklern leisten

Ich bin nicht dagegen, Benutzer zu warnen, wenn Entwickler "Fehler" machen, aber das Einfügen eines zufälligen DOM-Elements ist einfach aufdringlich. Ich finde es toll, wie Browser mit HTTPS-Problemen umgehen, bei denen der Browser über eine dedizierte Benutzeroberfläche verfügt, um anzuzeigen, dass die Website unsicher ist. Wir haben keinen für den leistungsbezogenen Status. Angesichts der zunehmenden Bedenken hinsichtlich der Webleistung im Allgemeinen sehe ich nicht ein, warum Browserhersteller keine Möglichkeiten finden, Benutzern mitzuteilen, dass die Website, die sie besuchen, scheiße ist.

Dies sollte auf Tooling-Ebene angegangen werden, damit möglicherweise Webpack und Babel die Entwickler über die Vorteile des Setzens eines NODE_ENV informieren können.

@pveyes Einverstanden, ich habe das gleiche Argument gegenüber dem Angular-Team gemacht.

@matthewp , es gibt ein viel älteres Problem zu diesem https://github.com/presidential-innovation-fellows/code-gov-web/issues/129 und das Angular-Team hat sich direkt an sie gewandt und ihnen die Lösung gegeben – es scheint eine zu geben wenig Lust, es anzuwenden. Die Frage ist, hätte eine DOM-Warnung diese Korrektur dringender gemacht oder verhindert, dass sie von Anfang an im Entwicklermodus gestartet wird?

Die Frage ist, hätte eine DOM-Warnung diese Korrektur dringender gemacht oder verhindert, dass sie von Anfang an im Entwicklermodus gestartet wird?

Höchstwahrscheinlich würden sie die Warnung in der Entwicklung sehen, Google, wie man sie deaktiviert, und sie deaktivieren. Dann haben sie es im Entwicklermodus bereitgestellt, ohne es in Zukunft zu merken, weil sie es vergessen haben. Während der Entwicklung soll es wie in der Produktion aussehen, damit kein zufälliger Teil des DOM eingefügt werden kann. Sie können dies auch nicht von einem QA- oder Staging-System sehen lassen, da dies kein Hinweis auf die Produktion wäre.

Am Ende haben Sie also einen Haufen Junk-Code, der dieses Ding deaktiviert, das mit der UX der Website kollidiert. Es ist auch nicht so, dass sich der ursprüngliche Ingenieur, der es während der Entwicklung deaktiviert hat, unbedingt daran erinnern würde; Sie sind möglicherweise sogar weitergezogen, bevor es in Produktion ging.

Ich bin mir nicht sicher, wie der Bereitstellungsprozess bei code.gov funktioniert, aber wenn es so etwas wie das ist, was ich als Regierungsauftragnehmer erlebt habe, dann würde eine versehentliche Bereitstellung im Entwicklungsmodus in der Produktion entweder:

1. Erzwingen Sie ein vollständiges Rollback der gesamten Bereitstellung (von denen einige 6 Monate dauern, um die Genehmigung zu erhalten und alles zu bündeln, von UI-Änderungen bis hin zu Server-Software-Updates), wahrscheinlich am nächsten Tag, dann erhalten Sie Meetings und Follow-up-Dokumente darüber, was passiert ist und Planen eines neuen Bereitstellungsfensters (Sie werden immer wieder gefragt, ob sich die DB-Skripte oder -Dienste oder was auch immer aufgrund einer einzelnen Warnung in der Benutzeroberfläche alle im Entwicklungsmodus befanden). Ich habe gesehen, dass dies für sehr kleine Dinge passiert. Manchmal können Sie Ausnahmen bekommen, aber YMMV.

2. Es würde von Benutzern bemerkt, es würde korrigiert, aber da es wahrscheinlich keine Auswirkungen auf die Funktion hat, würde es erst im nächsten Bereitstellungsfenster aktualisiert. So können alle Benutzer es wochen- oder monatelang sehen.

Das war zumindest meine Erfahrung. Der Punkt ist, selbst wenn ein DOM- Einbruch unmittelbar nach der Bereitstellung bemerkt wird, wissen Sie nicht, wie ihre Infrastruktur / ihr Prozess ist, und es ist möglicherweise nicht etwas, was sie sofort beheben können (obwohl sie dazu in der Lage sein sollten ).

Warnmeldungen werden deutlicher, wenn #7360 (gelbes Kästchen) zusammengeführt wird. Wir könnten auch eine Nachricht in das gelbe Feld einfügen (nennen Sie es "Warnungen im Entwicklungsmodus reagieren"?).

Wenn ich die Angular-Dokumente öffne, sehe ich nichts über den Produktionsaufbau. Ich denke, das ist ein Problem sowohl für Angular als auch für React. Beide verwenden den Dev-Modus, aber sie sagen den Leuten in den Dokumenten nicht, wie sie ihn deaktivieren können. Aus diesem Grund könnte die Verbesserung der Dokumentation einen großen Beitrag zur Schulung von Entwicklern leisten

Es befindet sich direkt auf der Installationsseite:

https://facebook.github.io/react/docs/installation.html#development-and-production-versions

Und zur Leistungsoptimierung:

https://facebook.github.io/react/docs/optimizing-performance.html#use-the-production-build

Ich denke nicht, dass es fair ist zu sagen, dass Docs nicht offen darüber sind.

Wenn Sie die Dokumentation öffnen, müssen Sie die Advanced Guides durchgehen, um den Unterschied zwischen Dev- und Production-Build zu lesen. Der Titel lautet Optimizing Performance, etwas, das Anfänger definitiv nicht anschauen werden, weil sie React verwenden, weil sie gehört haben, dass es schnell ist. Ich denke, die Dokumentation könnte verbessert werden, um eine weitere Dokumentation mit dem Titel "Using React in Production" oder ähnlichem im Abschnitt "Schnellstart" zu haben.

Es steht gleich auf der allerersten Seite (Installation):

https://facebook.github.io/react/docs/installation.html#development-and-production-versions

Du hast recht. Es tut mir leid. Ich bin davon ausgegangen, dass sich der Produktions-Build in einem anderen Abschnitt befindet, also habe ich dort nicht nachgesehen und stattdessen in der Seitenleiste nach dem relevanten Titel gesucht (und die Seite zur Leistungsoptimierung gefunden). Ich hätte es besser wissen müssen.

Ich bin kein wirklicher React-Anfänger, deshalb habe ich die Installationsdokumentation nicht geöffnet, als ich die Dokumentation öffne, um meine Annahme zu überprüfen - dass die React-Dokumentation nicht im Voraus über Prod vs. Dev spricht -

Keine Bange. Wenn es nicht sichtbar genug ist, bin ich offen für Vorschläge für eine bessere Platzierung. Zum Beispiel könnten wir eine eigene Seite dafür erstellen ( Deploying to Production ).

Vergessen wir nicht, dass dieses Problem ein wichtiges Problem ist, das gelöst werden muss, aber nicht das wichtigste Problem, das hervorgehoben werden muss. Ich bin auch nicht davon überzeugt, dass es ausreichen wird, selbst wenn es ganz auf der Titelseite hervorgehoben wird, weil die Leute es sehen und durchblättern, es vergessen und denken werden: „Ich weiß, was ich tue“. Ich würde also nicht über die Doku-Sache hinausschwenken.

Der einzig wirkliche Weg, es anzugehen, besteht darin, es zu erkennen und zu benachrichtigen.

@KrisSiegel Dass das Favicon zwischengespeichert wird, ist ein guter Punkt. Ich frage mich, ob wir es einfach nach ein oder zwei Sekunden umschalten und dann alle paar Sekunden kurz zurückklappen sollten. Auf diese Weise ist es sehr unwahrscheinlich, dass das Caching- und Lesezeichenproblem zum Zeitpunkt des überschriebenen Symbols erfolgt.

Ich dachte, JS-Manipulationen am Favicon werden nicht zwischengespeichert, aber vielleicht irre ich mich.

Ich würde argumentieren, dass der richtige Ort, um Hooks dafür zu haben, nicht Chrome oder Firefox ist, sondern eher Webpack, Browserify oder Rollup.

Das Erstellen dessen, was als Produktionspaket für React gedacht ist, ohne den Produktionsmodus zu aktivieren, ist genau das – ein Build-Fehler. Ich denke, der Grund, warum es keine Einigung darüber gibt, wie dies zur Laufzeit dargestellt werden soll, spiegelt wider, dass dies kein Problem ist, das zur Laufzeit behandelt werden sollte.

@taion Ich stimme zu. Ich denke, das gehört definitiv in das Build-Tool, nicht in das DOM.

Ich denke, es sollte der Ort der Build-Tools sein, die Annahme zu treffen, dass Node env für Produktionscode auf Produktion gesetzt werden sollte. Es ist möglicherweise nicht für alle Projekte erforderlich, aber ich denke, es ist eine gute Annahme.

Wenn npm run build im Terminal ausgeführt wird und die Umgebung nicht auf Produktion eingestellt ist, sollten Sie im Terminal eine rote Warnung zusammen mit der Standardausgabe erhalten: env is not set to production, some scripts may be in development mode

Derzeit bekomme ich keine solche Warnung vom Webpack.

Edit: Klarstellung hinzugefügt

Oder setzen Sie einfach NODE_ENV für Sie, wirklich.

Wenn Konsolenwarnungen nicht funktionieren, bin ich mir nicht sicher, ob Build-Warnungen funktionieren.

Der Build sollte entweder Dinge für Sie konfigurieren oder fehlschlagen, wenn er für die Produktion falsch konfiguriert ist. Zumindest für React _ist_ das ein Build-Zeit-Flag.

@jakearchibald Ich bin sicher, dass es von einigen immer noch ignoriert wird, aber zumindest würde ihnen die Warnung angezeigt, wenn sie es erstellen, anstatt nicht gesehen zu werden, da die Warnung in der Browserkonsole versteckt ist, die sie möglicherweise nie in der Produktion öffnen . Am wichtigsten ist, dass es denjenigen mit weniger Erfahrung einen Hinweis darauf gibt, was sie tun sollten, um die Codeproduktion vorzubereiten.

Während viele Entwickler Bibliotheken aktualisieren, ist es üblich, Webpack und allgemeinere Tools nicht zu aktualisieren, weil viele Leute davon ausgehen, dass es einfach funktioniert, und es kann mühsam sein, Webpack und Co. zu aktualisieren.

Das Erstellen dessen, was als Produktionspaket für React gedacht ist, ohne den Produktionsmodus zu aktivieren, ist genau das – ein Build-Fehler.

Die Verwendung einer vorgefertigten Version von React aus einem CDN ist ebenfalls eine unterstützte Konfiguration , aber es gibt überhaupt keinen Build-Schritt in diesem Workflow. Daher würde eine Lösung für dieses Problem, die sich nur auf den Build konzentriert, den CDN-Anwendungsfall ignorieren.

Ich bin mir ehrlich gesagt nicht sicher, wie ich darüber denke; Ich sehe Argumente sowohl für als auch gegen Entwicklerwarnungen für die Verwendung von React CDN.

@taion Glauben Sie als jemand, der eine reine Build-Lösung unterstützt, dass dies ein wichtiger Anwendungsfall ist, den es abzudecken gilt?

Was denken andere Leute?

Ich denke, die Dokumentation dort ist ziemlich klar, dass Sie die .min.js -Bundles für die Produktion verwenden sollten. Vielleicht könnte es eine fette, eine größere Schriftgröße oder so etwas gebrauchen. Aber wenn jemand das nicht verkleinerte React-Bundle in der Produktion für seine Website verwendet, hat er sowieso andere Probleme.

Ich denke, die Dokumentation dort ist ziemlich klar, dass Sie die .min.js-Bundles für die Produktion verwenden sollten.

Einverstanden, aber die Seite ist auch ziemlich klar darüber, wie Sie Ihr Build-Tool für die Produktion konfigurieren, wenn Sie React als npm-Paket einschließen. Ich denke, der springende Punkt dieser Ausgabe war der Versuch, eine Erfolgsgrube für Leute zu schaffen, die diese Seite der Dokumentation nicht sorgfältig lesen.

Es hört sich jedoch so an, als ob Sie anderer Meinung sind und dass Sie der Meinung sind, dass die Verwendung des Dev-Builds aus dem CDN kein wichtiger Fall ist, den Sie mit einer aggressiveren Dev-Warnung verhindern sollten. Ist das eine faire Zusammenfassung Ihrer Position, oder übersehe ich einige Nuancen?

Ich denke, die CDN+dev-Konfiguration ist offensichtlicher falsch, da der Benutzer einen nicht minimierten Build von React verwenden muss. Es ist schwieriger, auf diese Weise zu scheitern, da der Wissensaufwand, der erforderlich ist, um _einfach den verkleinerten Build_ zu verwenden, geringer ist.

Die Konfiguration, bei der Sie _denken_, dass die Dinge produktionsbereit sind, weil Sie die Minimierung in Webpack oder Browserify ausgeführt haben, aber eigentlich nicht sind, weil Sie NODE_ENV nicht festgelegt haben – das können Sie nicht über die CDN-Bundles erhalten.

Ich denke, React Tab auf Chrome Developer Tools reicht aus, um zu sagen, ob wir in DEV Mode sind.

Ich denke, es ist erwähnenswert, dass es einen Präzedenzfall für ein Framework gibt, das ein DOM-Element im Entwicklungsmodus in die Seite einfügt:

http://symfony.com/blog/new-in-symfony-2-8-redesigned-web-debug-toolbar

Soweit ich das beurteilen kann, glaube ich nicht, dass dies standardmäßig aktiviert ist.

Nach der obigen Diskussion scheint es ein allgemeines Ziel zu geben, eine perfekte Lösung zu erreichen, die alle Einschränkungen erfüllt, aber zuverlässig jeden daran hindert, im Dev-Modus zu laufen, wenn dies nicht der Fall sein sollte. Das OP erklärte, dass es einen Kompromiss zwischen den potenziellen Erfahrungen für Entwickler und Benutzer geben müsste, und ich denke, das ist sehr wohl der Fall.

Um zu versuchen, das Problem ein bisschen neu zu formulieren:

• Eine Anzahl von React-Sites ungleich Null schafft es in die Produktion, ohne dass der Entwicklungsmodus deaktiviert ist
• Diese Zahl möchten wir gerne reduzieren
• Wir wollen React-Entwickler nicht verärgern
• Wir wollen React-Neulinge nicht abschrecken
• Wir möchten nicht, dass Endbenutzer von Websites, die in React erstellt wurden, kryptische Entwicklerwarnungen sehen
• Wir möchten Sites nicht aufgrund des Vorhandenseins fremder DOM-Elemente unterbrechen

Angesichts dessen denke ich, dass ein anständiger erster Schritt für React im Dev-Modus wäre, über console.warn oder console.info anzukündigen, dass es sich im Dev-Modus befindet, mit Anweisungen, um sicherzustellen, dass dies für die Produktion deaktiviert ist Einsatz.

Sicher, das wird nicht jeden erwischen, aber _es ist ein anständiger Anfang_, der die Anzahl der Leute reduzieren sollte, die versehentlich an die Produktion liefern, und keine Türen für zukünftige Verbesserungen verschließt.

Angesichts dessen denke ich, dass ein anständiger erster Schritt für React im Dev-Modus wäre, über eine console.warn oder console.info anzukündigen, dass es sich im Dev-Modus befindet, mit Anweisungen, um sicherzustellen, dass dies für die Produktionsbereitstellung deaktiviert ist.

Es ist jedoch nicht falsch , sich im Entwicklungsmodus zu befinden, wenn Sie ... entwickeln. Welche anderen Heuristiken könnten wir verwenden?

Angesichts der Tatsache, dass niemand die Konsole in der Produktion liest, frage ich mich, ob wir ein Timeout einfügen könnten, damit es protokolliert wird, wenn Sie Lösungen für die Absturzberichterstattung verwenden.

Es ist jedoch nicht falsch, sich im Entwicklungsmodus zu befinden, wenn Sie ... entwickeln. Welche anderen Heuristiken könnten wir verwenden?

Ich denke, es sollte dem aktuellen React DevTools-Hinweis ähneln

Eine Informationsmeldung, die Sie daran erinnert, dass Sie sich im Entwicklungsmodus befinden und dass der Entwicklungsmodus für Produktionsstandorte deaktiviert werden sollte. Dies sollte (theoretisch) mehr Entwicklern bewusst machen, dass es einen Unterschied gibt und einige Maßnahmen ergriffen werden müssen, um den Produktionseinsatz vorzubereiten.

Wie Sie sagen, wird fast niemand eine Konsolenwarnung in der tatsächlichen Produktion sehen – und zu diesem Zeitpunkt ist es ein bisschen spät.

Es tut mir leid, dass es sich wie eine festgefahrene Aufzeichnung anhört, aber Konsolenwarnungen scheinen nicht zu funktionieren. ZB https://code.gov.

Es tut mir leid, dass es sich wie eine festgefahrene Aufzeichnung anhört, aber Konsolenwarnungen scheinen nicht zu funktionieren. ZB https://code.gov.

Eine einzige Gegeninstanz zeigt, dass es nicht unfehlbar ist - aber ich glaube nicht, dass irgendein Ansatz es sein wird.

Wenn eine Konsolenwarnung in der Lage ist, das Bewusstsein zu erhöhen und die Anzahl der Leute zu reduzieren, die fälschlicherweise den Dev-Modus ausführen, wenn sie es nicht sollten, dann scheint dies ein Schritt in die richtige Richtung zu sein. Perfektion ist der Feind des Guten.

@jakearchibald

Ja, aber wenn das Build-Tool von code.gov hier mit Hooks eingerichtet worden wäre, dann _hätte_ das Problem, das Sie beobachten, verhindert, zumindest im Zusammenhang mit React, das dafür Build-Time-Hooks verwendet. Sie verwenden immerhin Webpack.

Ich sage nicht, dass Webpack eine Build-Warnung ausgeben sollte. Ich sage, dass die richtige Lösung darin besteht, dass entweder das Webpack process.NODE_ENV für Sie festlegt oder dass das Webpack den Build standardmäßig fehlschlägt, wenn Sie versuchen, einen Produktions-Build ohne entsprechende Produktionskonfiguration zu erstellen.

Wollte schnell auf einen früheren Punkt von @addyosmani über „Verletzungen“ in DevTools reagieren. Wir entwickeln Prototypen , die stärkere Hinweise auf bestimmte Fehler in Chrome DevTools zeigen, aber diese Arbeit ist noch recht früh, und ich stimme @jakearchibald eher zu, dass das Anzeigen einer Warnung (auch wenn sie beängstigender als console.warn ist) nicht der Fall ist eine gute Lösung.

Was ist mit dem standardmäßigen Reagieren auf den Produktionsmodus und dem Einschalten des Entwicklungsmodus, wenn und nur wenn NODE_ENV == 'development' oder der Hostname localhost / 127.0.0.1 ist? Die meisten Entwickler erhalten sofort das richtige Verhalten und es wird immer eine Möglichkeit geben, den Entwicklungsmodus manuell zu erzwingen, wenn Sie es wirklich brauchen.

Scheint weniger als ideal zu sein, diesen Zweig immer noch mit einer möglicherweise ziemlich komplizierten Bedingung zu treffen (da Sie nicht nur auf Node scheitern müssten) die ganze Zeit.

Übrigens, -p ("Produktions"-Modus, der auch die Minimierung mit Standardeinstellungen ermöglicht) in Webpack 2 legt NODE_ENV für Benutzer fest: https://webpack.js.org/guides/production-build /#Knoten -Umgebungsvariable.

Dies erscheint mir ziemlich vernünftig und sollte dieses Problem für fast alle Benutzer von Webpack verhindern. Warum besteht man darauf, irgendetwas davon zur Laufzeit zu handhaben?

Übrigens, -p ("Produktionsmodus", der auch die Minimierung mit Standardeinstellungen ermöglicht) in Webpack 2 legt NODE_ENV für Benutzer fest: https://webpack.js.org/guides/production-build/#node -environment-variable.

Ja. Wir sind uns dessen bewusst. @TheLarkInn vom Webpack-Kern könnte dies mit Sicherheit bestätigen, aber ich verstehe, dass -p in der Webpack-Community atm nicht weit verbreitet ist. Das zugrunde liegende Problem hier ist auch, dass wir, wenn eine Lösung Opt-in ist, ähnlich wie beim aktuellen Status quo mit console.log-Warnungen, wahrscheinlich keine wirklichen Änderungen für React-Benutzer sehen werden. Wir möchten den Leuten eine bessere Abwechslung beim Versand der "schnellen" Sache geben.

Es ist erwähnenswert, dass die fehlende Möglichkeit, DEV- und PROD-Umgebungen in Webpack leicht zu erkennen (-p ist unzureichend), uns in https://github.com/webpack/webpack/issues/3216 auch einige Schmerzen bereitet hat.

Ich sage, dass die richtige Lösung darin besteht, dass entweder webpack process.NODE_ENV für Sie festlegt oder dass webpack den Build standardmäßig fehlschlägt, wenn Sie versuchen, einen Produktions-Build ohne entsprechende Produktionskonfiguration zu erstellen.

Ich bin dafür, dass wir das weiterverfolgen, aber es wäre eine bahnbrechende Veränderung für Webpack, soweit ich das beurteilen kann. Ich persönlich bin der Meinung, dass eine Laufzeitlösung, die eine klare Overlay-Nachricht enthält, die _nur_ mithilfe einiger intelligenter Heuristiken (localhost, devtools open usw.) angezeigt wird, uns angemessen abdecken würde.

Das heißt, da wir immer wieder zum Element Webpack process.NODE_ENV zurückkehren, wäre ich neugierig, ob @sokra oder @TheLarkInn irgendwelche Meinungen zu diesem Thema hätten.

Mein Verständnis weicht dort von Ihrem ab – ich glaube, dass -p de facto die Art und Weise ist, wie die meisten nicht erfahrenen Benutzer von Webpack Produktions-Builds einrichten.

Sogar prominente Pakete verwenden -p , um Produktions-Builds zu generieren:
https://github.com/ReactTraining/react-router/blob/5e69b23a369b7dbcb9afc6cdca9bf2dcf07ad432/package.json#L23
https://github.com/react-bootstrap/react-bootstrap/blob/61be58cfdda5e428d8fb11d55bf743661bb3f0b1/tools/dist/build.js#L10

Es ist ziemlich ungewöhnlich, das Uglify-Plug-in direkt im Webpack zu konfigurieren, sodass die Leute ohne -p nicht-minifizierte Builds verwenden würden, in welchem ​​Fall sie größere Probleme hätten.

Ich persönlich bin der Meinung, dass eine Runtime-Lösung, die eine klare Overlay-Nachricht beinhaltet, die nur mit einigen intelligenten Heuristiken (localhost, devtools open usw.) angezeigt wird, uns angemessen abdecken würde.

Ich habe das Gefühl, dass dies mehrfach abgeschossen wurde („Es ist inakzeptabel, dass ein Framework Dinge in das DOM injiziert“), ohne das _einzige_ Szenario zu schätzen, in dem dies passieren würde.

Ich stimme Ihnen voll und ganz zu, dass es nicht akzeptabel ist, während der Entwicklung ständig mit einer permanenten Meldung und unerwarteten Dingen im DOM fertig zu werden. Was wir hier jedoch vorschlagen, ist eine Meldung, die angezeigt wird, wenn und _nur_ wenn DevMode in der Produktion bereitgestellt wird (geben Sie Heuristiken ein!). Eine beliebige Anzahl von Überprüfungen und Konsolenmeldungen kann in Tools, CI und Browsererweiterungen eingebaut werden, um dies zu verhindern.

Aber als verzweifelte Notlösung halte ich ein sichtbares Banner auf dem Bildschirm für eine gute und angemessene Lösung.

angezeigt, wenn und nur wenn DevMode in der Produktion bereitgestellt wird (Heuristik eingeben!)

Also wird ein Entwickler diese Nachricht nie sehen, (vielleicht versehentlich) den Entwicklungsmodus in der Produktion bereitstellen und plötzlich sehen sie, dass dieser neue HTML-Code in ihrer Anwendung angezeigt wird, damit alle ihre Benutzer ihn sehen können?

Das klingt für mich eher nach einer Bestrafung. Wenn Sie den Dev-Modus noch nicht verstehen und diese theoretische neue Version von React mit der Nachricht bereitstellen, werden Sie eine Überraschung erleben und Ihre Benutzer in der Webanwendung zu diesem Zeitpunkt können es auch sehen. Ich kann nicht erkennen, wie dies irgendjemandem hilft, aber dazu dient, den Entwickler oder das Unternehmen in Verlegenheit zu bringen. Sicher, vielleicht bringt das sie dazu, es zu reparieren, aber diese Kosten sind meiner Meinung nach zu hoch und es fehlt ein bisschen Empathie.

Aber als verzweifelte Notlösung halte ich ein sichtbares Banner auf dem Bildschirm für eine gute und angemessene Lösung.

Das Problem bei dieser Lösung ist, dass sie viel zu idealistisch ist und Sie sich bei der Entwicklung eines Frameworks auf die Realität konzentrieren müssen , dass andere Unternehmen möglicherweise nicht die besten Bereitstellungsrichtlinien oder nicht einmal die beste QA (falls vorhanden) haben.

Ja, wenn jemand in der Produktion den Dev-Modus bereitstellt, sollte er in der Lage sein, ihn zu sehen und ihn schnell zu ändern. Leider ist dies gerade außerhalb der Technologiebranche einfach nicht oder nicht einfach möglich. Die Mehrheit der Leute, die hier kommentieren? Wahrscheinlich verfügen ihre Unternehmen über Bereitstellungsprozesse, die dieses Szenario problemlos bewältigen könnten. Google, Facebook, Playstation usw.; Alle diese Technologieunternehmen können damit gut umgehen, aber das ist nicht repräsentativ für die Mehrheit der Benutzer, die React verwenden, oder? (Haben wir eigentlich irgendwelche Statistiken über die Nutzung von React? Wäre praktisch!)

Ja, ja, diese Unternehmen und Regierungen sollten ihre Bereitstellungsprozesse und -richtlinien usw. usw. ändern. Aber die Realität sieht so aus: Die meisten Unternehmen haben beschissene Bereitstellungsprozesse und Mist zu nicht vorhandener QA.

Nehmen wir zwei Szenarien, die ich persönlich erlebt habe.

Erstens , während Sie in der Regierung arbeiten, haben Sie je nach Branche und Abteilung wahrscheinlich alle 3-6 Monate einen einzigen Einsatz. Diese Bereitstellungen rollen so viel Material wie möglich auf, und wenn ein Teil der gesamten Bereitstellung fehlschlägt, wird möglicherweise alles zurückgesetzt. Wir haben also diese Software namens OWF verwendet, die, falls Sie sich nicht auskennen, wie iSocial darin ist, dass sie mehrere Webanwendungen in einer einzigen Webanwendung mithilfe von Iframes anzeigt (ekelhaft, ich weiß, aber bleiben Sie hier bei mir). Es gab einen manuellen Konfigurationsschritt bei der Bereitstellung mehrerer unserer Anwendungen, der fehlschlug, was dazu führte, dass 404- und 500-Fehler in einigen der Iframes anstelle der beabsichtigten Anwendung angezeigt wurden.

Da Entwickler normalerweise keinen Zugriff auf das System haben, auf dem sie bereitgestellt werden, dauerte es viele Stunden, bis wir von Problemen erfuhren. An diesem Punkt mussten wir unseren Chef dazu bringen, den Chef einer anderen Person anzurufen, um deren Chef anzurufen, um ihnen mitzuteilen, dass es keine Auswirkungen auf irgendetwas anderes hatte, damit sie nicht die gesamte Bereitstellung rückgängig machen würden. Dann mussten wir jede Menge Papierkram und Dokumentation ausfüllen, bevor wir einige Tage später jemanden dazu bringen konnten, einen Teil der Konfiguration zu wiederholen. In der Zwischenzeit war die Anwendung während dieser gesamten Zeit funktionsunfähig.

Zweitens , als ich im Finanzwesen arbeitete, hatten wir eine Bereitstellung, die versehentlich den Namen eines Entwicklers anstelle eines tatsächlichen Artikellayouts auf der Website enthielt (ich glaube, er hat etwas getestet?). Wie auch immer, es wurde sofort bemerkt, aber um es zu beheben, mussten wir eine Notänderungskontrolle durchführen, die bis viel später an diesem Tag dauerte. Also mussten ihre Kunden dieses dumme Banner fast volle 8 Stunden sehen, bevor es repariert wurde.

Mein Punkt ist: Es muss sehr sorgfältig vorgegangen werden, wenn beliebige Elemente in das DOM eingefügt werden, die der Entwickler dort nicht eingefügt hat. Vor allem, wenn wir davon sprechen, es nur in einigen Szenarien anzuzeigen, dann wird jemand, wenn es das erste Mal zu sehen ist, herausfinden, wie es schnell deaktiviert werden kann, damit er sich nicht noch einmal darum kümmern muss.

@KrisSiegel

Wenn Sie den Dev-Modus noch nicht verstehen und diese theoretische neue Version von React mit der Nachricht bereitstellen, werden Sie eine Überraschung erleben und Ihre Benutzer in der Webanwendung zu diesem Zeitpunkt können es auch sehen.

Ich war neugierig, ob Ihre Gedanken zum Ansatz anders wären, wenn die Meldung nur angezeigt würde, während DevTools geöffnet war (dh etwas, das eine geringe Chance hat, von Produktionsbenutzern gesehen zu werden, die keine Entwickler sind). Quasi eine Erweiterung der aktuellen console.log-Strategie, die React bereits heute anwendet.

Ich war neugierig, ob Ihre Gedanken zum Ansatz anders wären, wenn die Meldung nur angezeigt würde, während DevTools geöffnet war (dh etwas, das eine geringe Chance hat, von Produktionsbenutzern gesehen zu werden, die keine Entwickler sind). Quasi eine Erweiterung der aktuellen console.log-Strategie, die React bereits heute anwendet.

Wenn Sie Entwicklungstools geöffnet haben, sehen Sie wahrscheinlich console.log-Meldungen, sodass DOM-Änderungen wie eine unnötige Komplexität zu verwalten scheinen und überflüssig sind. Sie könnten die Nachrichten der React-Konsole immer größer / ausgefallener machen. Vielleicht ein ASCII-React-Logo. Etwas, um die Aufmerksamkeit von jemandem zu erregen, falls er zufällig dort hineingeht.

Obwohl ich denke, dass jemand darauf stoßen würde, fragen Sie bei Stackoverflow, wie die Warnung deaktiviert werden kann. Jemand wird Code posten, der ihnen zeigt, wie es geht, und die Leute werden ihn einfach deaktivieren, wenn sie darauf stoßen. Es gibt zahlreiche Build-Tools, und viele Leute, mit denen ich in der Vergangenheit gesprochen habe, fanden sie verwirrend oder schwierig (die Veröffentlichung von Babel 6 war eine „lustige“ Zeit). Sie werden auf viele Leute stoßen, die sie einfach nie richtig verwenden.

Das ist zumindest meine Erfahrung ¯\_(ツ)_/¯

Puh, endlich bis zum Ende des Threads aufgeholt. Okay. Ich habe mir das ein bisschen überlegt.

Webpack könnte die Angabe von NODE_ENV erzwingen, die React dann verwenden könnte, um einfacher zu vermeiden, dass Leute DEV an PROD senden, aber das wäre eine bahnbrechende Änderung für Webpack. Ich spreche jetzt mit Sean darüber, wie machbar so etwas für Webpack 3 sein könnte. Ich weiß, dass es beiden Lagern wichtig ist, den React + Webpack-Stack anfänger- und leistungsfreundlich zu halten.

Das hat sich bisher wie mein Favorit angefühlt, aber ich bin noch nicht zu 100 % verkauft.

1. So könnte erzwungen werden, dass ein ENV übergeben wird, wenn jemand Webpack ausführt. Eine hilfreiche Fehlermeldung besagt, dass Sie eine env-Variable angeben müssen, um Webpack auszuführen.

Dies bietet jedoch einen erheblichen Sprungpunkt für Benutzer. Nicht jeder schreibt für ein Prod- oder Dev-Env oder weiß überhaupt, was ein Env ist. Ich werde ein Problem auf Webpack/Webpack aufwerfen, um Feedback dazu zu erhalten, da mein Bauchgefühl ist, dass nicht jeder dies wollen wird, und ob ich zustimme oder nicht, wir müssen den Pushback in Betracht ziehen.

1. <something in-between 1 and 3 I haven't figured out yet>

2. Die webpacky Lösung wäre, ein eigenständiges Plugin zu erstellen, das sich in den Compiler-Lebenszyklus einklinken, prüfen könnte, ob der Code entfernt wird oder ob kein ENV bereitgestellt wird, und eine freundliche Warnung oder einen Fehler Ihrer Wahl ausgeben könnte.

Ich kann mir jedoch vorstellen, dass die Antwort lautet: "Aber die Benutzer werden nie wissen, wie das geht usw." Also CRA, also dieses Problem gerade jetzt.

Wir könnten ein neues Resolver-Muster erstellen, das die package.json von React (oder jeder FW, die es benötigt) auf etwas wie das Folgende überprüft:

"webpack": {
  "plugin": "ReactEnviornmentPlugin"
}

das würde automatisch auf die Compiler-Konfiguration eines Benutzers angewendet, ohne dass dieser es wissen oder sich darum kümmern müsste.

Wieder nur wirklich Brainstorming.

@TheLarkInn Ich denke, das aktuelle Verhalten von -p in Webpack 2 ist ausreichend, oder? Der einzige Fehlerfall ist, wenn jemand UglifyJsPlugin selbst einrichtet und vergisst, DefinePlugin zu tun, aber das scheint ein weit weniger wahrscheinlicher Fall zu sein.

@taion Ja/Nein

-p wendet nur Produktions-"Behandlungen" auf Ihren Code an, wir machen jedoch keine Annahmen darüber und/oder haben keine Kenntnis darüber, auf was NODE_ENV eingestellt ist. Aus diesem Grund müssen die Leute DefinePlugin() verwenden.

Aber ich denke, es ist der nächste "_vernünftige_" Bereich, um zu _raten_ oder _implizieren_, dass der Benutzer seinen Code in einer Produktions-ENV ausführt. Das wäre der einzige Bereich, in dem wir sicherstellen möchten, dass die Community und das Team damit einverstanden sind.

@TheLarkInn Ich glaube, das hat sich in v2 geändert: https://webpack.js.org/guides/production-build/#node -environment-variable

Ah tut mir leid, das stimmt, ich irre mich. Es wird jedoch nicht häufig verwendet, da die Benutzer eine feinkörnigere Kontrolle darüber wünschen, was sie optimieren. (Wie @addyosmani erwähnt)

Ist das wirklich so üblich? Als ich mit Webpack anfing, schien -p eindeutig der richtige Weg zu sein. Wie ich oben erwähnt habe, verwenden sogar Bibliotheken mit vielen Gründen, weitere Optimierungen vorzunehmen, immer noch -p .

Wir könnten ein neues Resolver-Muster erstellen, das die package.json von React (oder jeder FW, die es benötigt) auf etwas wie das Folgende überprüft:

"Webpaket": {
"plugin": "ReactEnvironmentPlugin"
}
das würde automatisch auf die Compiler-Konfiguration eines Benutzers angewendet, ohne dass dieser es wissen oder sich darum kümmern müsste.

@TheLarkInn Wenn ich das richtig lese, müsste zum Auslösen des Resolver-Musters die package.json einer App die ReactEnvironmentPlugin manuell angeben, oder? Oder verstehe ich den Vorschlag falsch? :)

Ich könnte mir eine Auflösungsmagie in Webpack vorstellen, die erkennt, dass ein Projekt React verwendet, und die richtige Umgebung für sie wechselt, aber das klingt nach einer engen Kopplung von Framework-spezifischer Optimierung an einen Bundler und ist möglicherweise nicht so wünschenswert.

Weniger, dass es eine Reaktion erkennen würde, und mehr, dass es erkennen würde, dass die Beschreibungsfelder eines js-Moduls ein Webpack-Feld mit einem Plugin enthalten. Aber du hast recht, es ist sehr eng gekoppelt und auch nicht wirklich meine Lieblingsidee.

Ich glaube nicht, dass Ihnen dies wirklich irgendwelche Garantien gibt, es sei denn, Webpack hat ein Konzept des "Produktionsmodus", um herauszufinden, wie React konfiguriert wird - und dies erscheint überflüssig, da, wie oben besprochen, -p bereits das Richtige tut Ding und ist das, wonach Benutzer im Allgemeinen greifen werden, wenn sie ohnehin einen verkleinerten Produktions-Build mit Webpack erstellen.

Wir haben darüber ein bisschen mehr gesprochen und ich denke, es gibt eine vernünftige Lösung.

Wir haben lange darüber nachgedacht, eine „Warnbox“ für React-Warnungen in der Entwicklung zu aktivieren. Eine Demo können Sie hier sehen (PR: https://github.com/facebook/react/pull/7360). Es wird nur angezeigt, wenn Sie Warnungen haben, aber sie sind während der Entwicklung sehr häufig (und sollten immer behoben werden), also wird vermutlich jeder, der mehr als fünf Minuten mit der Entwicklung einer App verbracht hat, den Dialog sehen und wissen, dass er existiert.

Nach dieser Änderung wird es schwieriger, den Entwicklungsmodus zu ignorieren. Sie werden wahrscheinlich nach „How to remove the warning dialog“ suchen und mehr über das Erstellen für die Produktion erfahren. Wenn Sie dies nicht tun, erhalten Sie wahrscheinlich irgendwann einige Warnungen, die Ihren Benutzern angezeigt werden. Ich denke, dass die Leute in diesem Fall React nicht per se beschuldigen werden, weil wir nicht nur zeigen, dass die Box unausstehlich ist – wir tun einfach, was der Entwicklungsmodus tun soll.

(Übrigens verwenden wir bei Facebook seit langem eine ähnliche Warnbox in der Entwicklung, sodass sie der beabsichtigten Verwendung von React entspricht.)

Ich freue mich sehr über diesen Vorschlag, @gaearon! Es ist alles, was ich mir erträumt habe ;)

Nur so nebenbei: Vielleicht ist es eine Überlegung wert, einen Link direkt in der Box zu haben, damit die Entwickler nicht googlen müssen, wie man ihn loswird.

Ja, guter Punkt. Wir werden etwas hinzufügen.

@gaearon Ich finde diese Lösung sehr widerlich; Ich möchte niemals , dass Warnungen in das DOM eindringen, selbst während der Entwicklung. Das hat für den normalen Entwickler keinen Zweck und würde von den meisten wahrscheinlich vollständig deaktiviert werden. Die Entwicklertools zeigen aus einem bestimmten Grund Warnungen an, sie müssen nicht erfunden werden.

Ich finde es auch beunruhigend, dass DOM-Lösungen immer wieder auftauchen, ohne dass meine früheren Argumente dagegen widerlegt werden. Wenn meine Punkte ignoriert werden sollen, dann gut, das ist nicht mein Repository, also ist das fair genug, aber es ist entmutigend zu sehen, dass dasselbe Argument auftaucht, Leute dagegen posten, Leute scheinen für die Punkte zu sein, da es nie ein Argument gibt gegen sie , dann kommen sie gleich wieder hoch. Spülen, wiederholen.

Während ich zustimme, dass dies für die meisten Warnungen gilt, weisen React-Warnungen ausdrücklich auf die Fehler in Ihrem Code hin. Es sind nicht nur Vorschläge.

Der Dialog lässt sich leicht schließen und die einzelnen Warnungen lassen sich leicht ausschalten (falls Sie sich für eine Weile nicht um sie kümmern), aber sie müssen behoben werden.

Zum Vergleich sieht der Dialog in der Facebook-Codebasis so aus:

Tausende von Ingenieuren haben damit kein Problem und sind dadurch produktiver, daher halten wir dies für einen vernünftigen Standard. Um es klar zu sagen, die Open-Source-Version wird weniger schreien:

Wenn Sie Vorschläge zu Stilanpassungen haben, können Sie diese gerne auf https://github.com/facebook/react/pull/7360 kommentieren.

Ergänzend zu dem, was Dan gesagt hat, baue ich auf #7360 auf, um uns in unseren kürzlich hinzugefügten Fehlerprotokollierungsfluss einzuklinken. Ich probiere derzeit ein paar Arten von Toastbenachrichtigungen aus, die etwas weniger aufdringlich sind. Ich werde bald einige Screenshots und/oder ein Plnkr für Feedback posten.

Würden diese Warnungen die Warnung „minifizierter Entwicklercode“ enthalten? Das würde eine Menge Dinge ganz ordentlich lösen, wenn ja.

Ich sehe nicht ein, warum es nicht auch für diesen Zweck verwendet werden könnte.

@gaearon

Während ich zustimme, dass dies für die meisten Warnungen gilt, weisen React-Warnungen ausdrücklich auf die Fehler in Ihrem Code hin. Es sind nicht nur Vorschläge.

Das sollten meiner Meinung nach Fehler oder Ausnahmen sein. Warum sind sie es nicht? Ausnahmen erzwingen eine Korrektur, eine verwerfbare Warnung jedoch nicht.

Tausende von Ingenieuren haben damit kein Problem und sind dadurch produktiver, daher halten wir dies für einen vernünftigen Standard.

Ich habe dies in einem früheren Punkt erwähnt, aber ich würde vermuten, dass diese Ingenieure wahrscheinlich besser sind als gut 90 % der Leute, die die Open-Source-Version verwenden werden. Ich finde es das Gegenteil einer vernünftigen Vorgabe. Es gibt einen Grund, warum Entwicklungstools Warnungen haben; sie neu zu erfinden macht für mich keinen Sinn. Es wird deaktiviert und nie wieder gesehen.

Das sieht einfach so aus, als würde React meiner Meinung nach zu viel tun.

Als ich Regierungsaufträge machte, hatten wir eine gemeinsame Bibliothek, die alle Frontends verwenden mussten. Es würde Fehler in der Konsole aufnehmen und sie als Toast-Popup anzeigen. Es wurde nicht nur mehrmals von mehreren Teams in der Produktion bereitgestellt, sondern viele Entwickler sahen es einmal und fragten dann, wie man es dauerhaft deaktiviert. Ich sehe das als mehr vom Gleichen.

Wir haben lange darüber nachgedacht, eine „Warnbox“ für React-Warnungen in der Entwicklung zu aktivieren. Eine Demo können Sie sich hier ansehen (PR: #7360). Es wird nur angezeigt, wenn Sie Warnungen haben, aber sie sind während der Entwicklung sehr häufig (und sollten immer behoben werden), also wird vermutlich jeder, der mehr als fünf Minuten mit der Entwicklung einer App verbracht hat, den Dialog sehen und wissen, dass er existiert.

Ich mag #7360 wirklich, @gaearon. Es ist ermutigend, Unterstützung dafür zu hören, dass die Notwendigkeit hervorgehoben wird, für Bereitstellungen im neuen Warnfeld zu PROD zu wechseln. Es ist schön und visuell.

Ergänzend zu dem, was Dan gesagt hat, baue ich auf #7360 auf, um uns in unseren kürzlich hinzugefügten Fehlerprotokollierungsfluss einzuklinken. Ich probiere derzeit ein paar Arten von Toastbenachrichtigungen aus, die etwas weniger aufdringlich sind. Ich werde bald einige Screenshots und/oder ein Plnkr für Feedback posten.

@bvaughn Ich freue mich darauf, mehr von Ihren Iterationen zu sehen :)

Für Leute, die der Meinung sind, dass der Warnbox-Ansatz zu aufdringlich sein könnte, zeigen andere Bibliotheken (z. B. VueJS) bereits DOM-Overlays während Ihres Entwicklungs-/Iterations-Workflows an, um die Fehlerbehebung oder langsame Pfade zu fördern:

Meine eigene Erfahrung war, dass diese Meldungen zwar eine geringfügige Unannehmlichkeit darstellen, aber offensichtlicher sind als das, was Sie möglicherweise in der Konsole sehen. Ich denke, Dan hat Recht, dass es zumindest mehr Wert darauf legt, dass der Dev-Modus nicht etwas ist, das Sie für Prod bereitstellen sollten, und hoffentlich dazu führen wird, dass mehr Websites den "schnelleren Modus" an ihre Endbenutzer liefern.

Nach dieser Änderung wird es schwieriger, den Entwicklungsmodus zu ignorieren. Sie werden wahrscheinlich nach „How to remove the warning dialog“ suchen und mehr über das Erstellen für die Produktion erfahren. Wenn Sie dies nicht tun, erhalten Sie wahrscheinlich irgendwann einige Warnungen, die Ihren Benutzern angezeigt werden. Ich denke, dass die Leute in diesem Fall React nicht per se beschuldigen werden, weil wir nicht nur zeigen, dass die Box unausstehlich ist – wir tun einfach, was der Entwicklungsmodus tun soll.

Das sollten meiner Meinung nach Fehler oder Ausnahmen sein. Warum sind sie es nicht? Ausnahmen erzwingen eine Korrektur, eine verwerfbare Warnung jedoch nicht.

Obwohl sie behoben werden sollten, habe ich möglicherweise dringendere Angelegenheiten zur Hand. Zum Beispiel prototypiere/mockiere ich oft Benutzeroberflächen und schreibe dabei schnellen und normalerweise unterdurchschnittlichen Code, vor dem React warnen kann. Obwohl ich diese Warnungen beheben möchte, ist es mir egal, bis ich weiß, dass ich in der nächsten Stunde nicht den ganzen Code wegwerfen werde. Die Leute zu zwingen, sie sofort zu beheben, wird die experimentelle Entwicklung drastisch verlangsamen.

Für Leute, die der Meinung sind, dass der Warnbox-Ansatz zu aufdringlich sein könnte, zeigen andere Bibliotheken (z. B. VueJS) bereits DOM-Overlays während Ihres Entwicklungs-/Iterations-Workflows an, um die Fehlerbehebung oder langsame Pfade zu fördern:

Screenshot 2017-01-24 um 10 57 11 Uhr

Bist du sicher, dass das von Vue selbst kommt? Es sieht sehr nach Webpack-Build-Fehlern aus, die mit dem Fehler-Overlay von webpack-hot- middleware angezeigt werden. Wenn dies der Fall ist, ist es subtil anders, da es sich um ein Build-Tool zur Entwicklungszeit handelt, das das Overlay hinzufügt, und nicht um ein universelles Frontend-Framework.

Im Allgemeinen bin ich für das Warn-Overlay, aber ich denke, es sollte einen erklärenden Text enthalten, der sagt, was es ist, warum es da ist und dass es als Teil des Deaktivierens des Entwicklungsmodus deaktiviert werden kann und sollte. Hinter einem Expando, wenn das ein bisschen lang ist - aber es scheint ein so guter Ort wie jeder andere zu sein, um die Botschaft zu vermitteln.

Ich fürchte Updates wie 15.2.0 mit einem Overlay. kleine Beule und plötzlich haben Sie buchstäblich Hunderte von Warnungen über Requisiten, die an DOM-Knoten übergeben werden. Fehler vielleicht, aber ich denke nicht, dass Abschreibungswarnungen in einen so aufdringlichen Bereich gehören

Fehler vielleicht, aber ich denke nicht, dass Abschreibungswarnungen in einen so aufdringlichen Bereich gehören

Ich weiß nicht, ob dies vorher sehr klar kommuniziert wurde, aber die Idee bezüglich der Yellow-Box-Warnungen (#7360) bestand darin, nicht _alle_ Warnungen (Ablehnung oder andere) anzuzeigen. Vielmehr würden bestimmte Warnungen, die das Team für _besonders wichtig_ hielt, auf diese Weise hervorgehoben. Der Rest würde vermutlich in der Konsole verbleiben.

Das ist zumindest meine Erkenntnis aus dem Gespräch, das Tom und ich vor ein oder zwei Wochen über dieses Feature hatten.

Die Prop-Warnung in 15.2 war meiner Meinung nach auch ein Fehler und kein Hinweis auf unsere normale MO. Wir hätten gerne eine Möglichkeit, Warnstufen durch Nebenversionen zu steuern, um dies zu vermeiden.

Der Hauptgrund, warum unser Team den Produktions-Build nicht verwendet, ist, dass wir keine JS-Einheitentests ausführen können, da die Test-Dienstprogramme nicht enthalten sind.

Zunächst einmal ein weiterer Dank an das React-Team ( @sebmarkbage , @gaearon , @tomocchino und andere) dafür, dass sie dieses Problem mit uns diskutiert haben und so offen dafür waren, mit uns in diesem Quartal über Leistung und Mobilgeräte bei BlinkOn und anderen Synchronisierungen zu sprechen.

Statusprüfung

Laut @aweary in https://github.com/facebook/react/pull/7360 wurde die Yellow-Box-Lösung für dieses spezielle Problem auf Eis gelegt, bis die High-Prio-V16-Arbeit von React abgeschlossen ist, sollte aber weiterhin stattfinden. https://github.com/facebook/fbjs/pull/165 muss landen und in Fiber implementiert werden. Eine gute öffentliche API zum Offenlegen von Hooks muss ebenfalls erstellt werden. Werde die Finger behalten 🤞

Dieses Problem scheint immer noch weit verbreitet zu sein

Nicht wenige der Produktions-Apps, die auf meinen Schreibtisch gestoßen sind, liefern immer noch den DEV-Modus an die Produktion. Wir können den When deploying React apps to production Debug-String in ihren Builds hier sehen:

https://cdnjs.cloudflare.com/ajax/libs/react/15.3.1/react.js (tombraider.com)
https://shared.reliclink.com/dlls/vendor-f3e016f6037eb107ffc0.live-shared.min.js (dawnofwar.com)
https://d1xx3pvec9nqb7.cloudfront.net/media/js/thread.af65c1a02d15.js (thread.com)
http://www.sothebys.com/etc/designs/redesigns/sothebys/redesignlibs.min.js (sothebys.com)

Ich bin immer noch der Ansicht, dass ein Schritt vor der gelben Box zum Protokollieren der DEV-Modus-Warnung auf der Konsole für das oben Genannte einige Auswirkungen haben könnte. Sebastians Vorschlag, einen Konsolenfehler zu werfen, damit die Crash-Berichte diese aufgreifen, war meiner Meinung nach auch eine Überlegung wert.

Was können wir sonst noch tun, um die Nadel hier zu bewegen?

Bessere Interessenvertretung? Ich freue mich, mich weiterhin für Leute einzusetzen, die den DEV-Modus nicht in die Produktion schicken, aber ich möchte sehen, ob wir die offizielle Lösung nach V16 finden können :)

Kurzfristig sieht es so aus, als wäre create-react-app in einer guten Position, um neuen Projekten zu helfen, dieses Problem zu vermeiden.

Verbesserungen der Installationsdokumentation

Für alle anderen, würde es Unterstützung für https://facebook.github.io/react/docs/installation.html geben, einschließlich einer klaren, sichtbaren Legende unter der Überschrift Installing React , die die Leute daran erinnert, auf den DEV-Modus zu achten Produktion?

Als Benutzer sehe ich ansonsten keinen großen Anreiz, https://facebook.github.io/react/docs/installation.html#development -and-production-versions auf den ersten Blick zu lesen.

Die Gedanken?

Der Hauptgrund, warum unser Team den Produktions-Build nicht verwendet, ist, dass wir keine JS-Einheitentests ausführen können, da die Test-Dienstprogramme nicht enthalten sind.

Ich bin darüber verwirrt. Führen Sie Tests auf der Produktionswebsite durch? Wenn nicht, was hindert Sie daran, den Produktions-Build auf der Produktions-Website und den Entwicklungs-Build in der Entwicklung zu verwenden?

Würde es für alle anderen Unterstützung für https://facebook.github.io/react/docs/installation.html geben, einschließlich eines klaren, sichtbaren Callouts unter der Überschrift Installing React, der die Leute daran erinnert, den DEV-Modus in der Produktion zu beachten?

Sicher. Möchten Sie eine PR senden?

Sicher. Möchten Sie eine PR senden?

Mehr als gerne.

Vielleicht wäre ein Wort über Benchmarks auch nett, um diejenigen aufzuklären, die Perfs mit React im Dev-Modus vergleichen?

Lässt mich denken, dass die React-Devtools-Erweiterung genutzt werden könnte, um eine Benachrichtigung oder etwas Offensichtliches anzuzeigen, wenn eine Seite mit React im Dev-Modus geöffnet wird?

Ich mag diese Idee! Ich habe eine Reihe vorgeschlagener Symbole für die Devtools zusammengestellt (siehe facebook/react-devtools/pull/652).

Wir müssen entscheiden, wie wir dev vs. prod React auf eine Weise erkennen, die rückwärts und zukunftssicher ist, aber ich habe es auf die Tagesordnung des Montagsmeetings gesetzt.

Wir haben einige vernünftige Schritte unternommen, um dieses Problem zu beheben:

• React DevTools (mit ~700.000 Benutzern) zeigt jetzt ein markantes rotes Symbol für Entwicklungs-Builds an. Dies hilft den Benutzern, den Unterschied zwischen den Versionen frühzeitig zu erkennen. Es erzeugt auch einen gewissen Gruppenzwang, da Entwickler dies auf Websites bemerken, die sie besuchen, und den Leuten, die daran arbeiten, Bericht erstatten. Wir haben gesehen, dass einige große Websites das Problem innerhalb weniger Tage nach der Einführung behoben haben.

• Der Hinweis in React DevTools verlinkt auf unsere Website, auf der wir Anweisungen zum Erstellen des Produktions -Builds für alle wichtigen Bundler veröffentlicht haben . Wir haben es auch auf der Installationsseite deutlicher hervorgehoben.

• Die Create React App gewann weiter an Popularität. Diese Unterscheidung lehrt er schon früh mit separaten Befehlen. Es zeigt auch eine permanente Benachrichtigung über den Entwicklungsmodus im Terminal an.

• React 16 Beta 1 (und weitere Releases) werden mit react.development.js und react.production.min.js als Dateinamen ausgeliefert, um deutlich zu machen, dass nicht minimierte Builds nicht in der Produktion verwendet werden sollten.

Ich denke, dass wir in Zukunft weitere Möglichkeiten zur Lösung dieses Problems untersuchen werden, aber im Moment habe ich das Gefühl, dass wir ohne drastischere Maßnahmen vorankommen und sehen können, ob es hilft. Danke an alle für die Diskussion.