React: DEVモードを本番環境に出荷しないようにユーザーを促す方法を検討する

参考： https ：//github.com/facebook/react/pull/8782

コンテキストとして、ReactのDEVバージョンを縮小したことが検出された場合はすでに警告しています： https ：//github.com/facebook/react/blob/8791325db03725ef4801fc58b35a3bb4486a8904/src/renderers/dom/ReactDOM.js#L91 -L98

ユーザーに通知するための同様のヒューリスティックを見つけることができ、おそらくもっと積極的にDOMダイアログをポップアップできる限り、そうすべきです。

また、私たちが提供する警告は、人々がそれに注意を払うとパフォーマンスを大幅に向上させることができることを明確にしたいと思います。 このスレッドは、デフォルトでない場合に事後にこれをデプロイすることが難しい理由のいくつかの理論的根拠を説明しています。

また、単一のコンソールの提案でチャイムを鳴らしたいと思います。開発モードでrenderToStringが呼び出された場合は警告します。 明らかに、ほとんどの場合、 renderToStringはノードで呼び出され、DOMダイアログを警告したりポップアップしたりすることはできません。

残念ながら、 NODE_ENVがproductionに設定されているかどうかだけでなく、 process.env.NODE_ENVがコンパイルされているかどうかも検出できるようにしたいと思っています。 誰かがそれを行う方法を知っていますか？

スレッド@sebmarkbageに感謝し、事後に展開することの難しさを認めます。 また、現在の警告にも感謝しています。 一部の開発者は、デプロイされたサイトのコンソール出力をできるだけ頻繁にチェックしない可能性があるようです。 しかし、それは良い第一歩です。

ユーザーに通知するための同様のヒューリスティックを見つけることができ、おそらくもっと積極的にDOMダイアログをポップアップできる限り、そうすべきです。

ユーザーへの通知に使用されるヒューリスティックの改善に感謝します。 より積極的なDOMダイアログは、役に立ちます。 それはサイトがエンドユーザーのために働き続けることを確実にするでしょうが、開発者が選ぶことができるぶら下がっているパフォーマンスフルーツがあるというアクティブなヒントを提供します。

別の方法は、元の投稿で述べたように、ビルドツール/ ENVレベルでこれを修正する方法を見つけることです。 これにより、DOMインジェクションが不要になります。

DOMにメッセージングを挿入することは危険であり、少し想定しすぎているようです。 これにより、エンドユーザーが予期しない混乱を招くアラートを受け取る可能性があります。これは、IMOでは受け入れられないようです。

@thelarkinnは、このようなメッセージングの検出をより容易にするために必要なENV構成を標準化しようと提案していました。

これは、これに対処するための理想的なスペースのように感じます。 これはビルドの問題であり、可能であれば、ビルドツールで対処する必要があります。

事例：コンソールの警告は、過去に表示されなくなった（または無視された）ことがあります。 ここには明確な数字はありませんが、コンソールベースの警告では不十分だと思います。 @addyosmaniに同意します。これは、DOMベースの警告が大いに役立つということです。

@surmaおそらく、視認性を高めるためにconsole.warnまたはconsole.errorを使用する必要があります😉

アプリケーションが本番環境で実行されている場合にのみコンテンツをアプリケーションに挿入することが、どのシナリオでもどのように受け入れられるかわかりません。 あなたは、アプリケーションが実際のユーザーにプッシュされる前にメッセージがキャッチされるという大きな仮定を立てています。この場合、メッセージはUXに大きな打撃を与える可能性があります。

ところで、Fiberにさらに包括的なエラー処理サポートを追加して、障害（スローされたエラー）のあるコンポーネントをカスタムエラービューに置き換えることができるようにします。 デフォルトのシナリオでも、非常に積極的になる可能性があり、エラーが発生した場合はそのコンポーネントをツリーから削除するだけなので、とにかくユーザー用のカスタムエラーUIが必要になります。

この警告に対して、このようなエラーをトリガーできる可能性があります。

正直なところ、$ console.log console.{error,warn}が何かを変えたとは思いません。 私が言ったように、その話は逸話的です。

また、DOMダイアログを表示することが解決策であると言っているのではありません。 でも、それは私が個人的には快適だと思います。 開発モードにとどまることが悪影響を与える場合、少なくともユーザーは_何か_が間違っていることを知っており、おそらく「ヘルプ」ボタンなどを押し始めます。

結論：フレームワークは、ある時点で開発者の顔に触れる必要があると思います。 これについてブレインストーミングを行い、フレームワークの作成者が将来開発モードでの展開を防ぐためにどのような手順を実行し、妥協するかを確認したいと思います。

開発か製品かに関係なく、環境を提供しない限りReactがまったく機能しない場合はどうなりますか？ そうすれば、どちらかの方法で意識的な選択が行われることになります。

DOMに挿入されたメッセージについては、グローバルなどを使用して無効にすることができます。 大したIMOはありません。 無効にすると、自分が何をしているかを知っていることを認めることになります。

コンソールメッセージの問題は、多くのことをログに記録したり、無視する他の警告が表示されたりすることがあり、スクロールを過ぎた最初のコンソールメッセージが見られないことです...

必須のenvを使用すると、必然的にボイラープレートなどでenv varが設定されるため、使用を開始できます。恐れ入りますが：/

正直なところ、console.log上のconsole。{error、warn}が何かを変更したとは思いません。

開発者がコンソールをチェックしていない、またはコンソールが警告で過負荷になっているという問題だと思いますか？ これは、開発者教育に関するより一般的なアプローチで（部分的に）対処できますか？

また、DOMダイアログを表示することが解決策であると言っているのではありません。 でも、それは私が個人的には快適だと思います。 開発モードにとどまることが悪影響を与える場合、少なくともユーザーは何かが間違っていることを知っており、おそらく「ヘルプ」ボタンなどを押し始めます。

私はそれを理解していますが、私はそれが解決策であるとは言うまでもなく、その解決策ではないと言っているだけです。 快適に使用できるのは良いことですが、注意を怠って、ほとんどの人が予期しないエラーをユーザーに表示したくないと想定する方がよいと思います。

結論：フレームワークは、ある時点で開発者の顔に触れる必要があると思います。 これについてブレインストーミングを行い、フレームワークの作成者が将来開発モードでの展開を防ぐためにどのような手順を実行し、妥協するかを確認したいと思います。

私は💯開発者の顔を見ることができますが、適切な場所でそれを行うことが重要です。 私にとって、それは本番ではなくビルドステップです。

DOMに挿入されたメッセージについては、グローバルなどを使用して無効にすることができます。 大したIMOはありません。 無効にすると、自分が何をしているかを知っていることを認めることになります。

デフォルトで有効にすることは、構成可能にしないことと同じくらい悪いことです。デフォルトの動作は、エンドユーザーに予期しない動作をもたらす可能性があります。 どちらかといえば、デフォルトで無効にする必要がありますが、開発者は最初の問題に気付いたら修正できるため、目的全体が無効になります。

コンソールメッセージの問題は、多くのことをログに記録したり、無視する他の警告が表示されたりすることがあり、スクロールを過ぎた最初のコンソールメッセージが見られないことです...

私は完全にそれを理解しています、コンソールは混雑する可能性があり、物事を見逃しがちです。 しかし、私が主張している正確な理由で混雑しています。それは、開発者にフィードバックやエラーを提供する場所です。 挿入されたメッセージはそうではない、それはユーザーエクスペリエンスの邪魔にならない。

理にかなっています、私はその理由を理解しています。

おそらく、コンソールのフォーマットを使用して物事を飛び出させることは、少なくとも何かでしょう。

問題は、本番環境でコンソールを見る人がほとんどいないことです。 そこではどのフォントでも使用でき、人々はそれに気付かないでしょう。

ただし、本番環境でデフォルトで（16または17の）重大な変更としてメッセージを表示するようにすると、見逃すことはできません。 つまり、（新しいユーザーの場合）初めて展開しようとすると発生し、既存のユーザーは新しいメジャーに更新するときにリリースノートを読む必要があります。 ですから、私たちがそれについて非常に明確であり、メッセージを見逃すことは不可能である限り、それは実行可能だと思います。

問題は、本番環境でコンソールを見る人がほとんどいないことです。 そこではどのフォントでも使用でき、人々はそれに気付かないでしょう。

Chromeチームのこれに関する経験についてのみコメントできますが、同意します。 ほとんどの人は、反復ワークフロー中にコンソールメッセージに気付くでしょうが、実稼働サイトでの警告を見る割合ははるかに少なく、それらに作用するものはほとんどありません。

ただし、本番環境でデフォルトで（16または17の）重大な変更としてメッセージを表示するようにすると、見逃すことはできません。 つまり、（新しいユーザーの場合）初めて展開しようとすると発生し、既存のユーザーは新しいメジャーに更新するときにリリースノートを読む必要があります。 ですから、私たちがそれについて非常に明確であり、メッセージを見逃すことは不可能である限り、それは実行可能だと思います。

@gaearonのような変更を受け入れてくれてありがとう。 将来のリリースでデフォルトでメッセージを試すことに同意するには何が必要ですか？ 😄

私は、コンソールの警告が解決策ではなく、ページに表示される警告の方がはるかに優れていることに同意します。

ページに表示される警告は次のようになります。

• サイトが開発モードになっていることを開発者に警告します
• メリットとそれなしで出荷する方法に関するドキュメントへのリンク
• メッセージを無効にするためのリンク…2時間わからない？

メッセージを無効にすることは重要です。メッセージがページ上の何かを妨害/覆い隠している可能性があるからです。 この設定はローカルストレージに保存されるため、発信元が異なるため、警告は引き続きライブサーバーに表示されます。

ええ、実際のユーザーがライブサイトでこのメッセージを見るのはかなり恐ろしいことですが、開発者が修正するように促されるような問題があるように感じますが、開発者モードのパフォーマンスの問題に満足している人もいます。

その警告（DOMへの挿入）を初めて見たときに本番環境にあった場合、私はかなり動揺します。 警告は事前に発生する必要があります。

@rtorr私の提案は、サイトが開発モードのときはいつでも発生するということです。何かが足りない場合を除いて、事前に確認する必要がありますか？

@jakearchibald混乱してすみません、私の返事はあなたに向けられていませんでした。 'insert into the dom'ソリューションを使用する場合は、ユーザーが何かをプッシュする前に、非常に注意してユーザーに知らせておく必要があることをスレッドに指摘したいと思います（どういうわけか、ここではわかりません） 。

一部の開発者が設定などを忘れて、管理がおかしくなってしまうのを目にします。 本番環境で開発モードを使用した場合の結果として、その可能性は価値がありますか？

常に無効にする必要があるというDOMベースの警告は問題ありません。永久に無効にすることが可能である必要があり、ローカルホストではまったく表示されない可能性があります。

devtoolsをアクティブ化するために有効にする必要があるブラウザにある種のフラグを設定できるとしたら、私を驚かせたものです（おそらく、「あなたは開発者ですか？[はい/いいえ]」という大きなオーバーレイです。 ）ページが検出し、開発者向けの警告のみを表示できること。 正しく表現すると、自己XXS攻撃にも役立つ可能性があります。

私が常に無効にしなければならないというDOMベースの警告は大丈夫ではありません、、それを永久に無効にすることが可能でなければなりません

dev-modeをオンにして起動するサイトも問題ありません。 たぶん、メッセージは1日に1回だけ却下する必要がありますか？ ただし、期間が長いほど、ライブで終了する可能性が高くなります。 永久に無効にできる場合は、最初の場所に戻ります。

また、本番環境で意図しないdomノードは問題ないと思います。

いずれにせよ、私たちは常にエッジケースを持っていると思います。 この問題が常に発生する場合は、開発モードの配信が間違っている可能性があります。 完璧な世界では理想的ではありませんが、誰かのアプリケーションを変更することをいとわないほどprodモードが重要であることがわかった場合は、デフォルトでdevモードをオプトインする必要があります。

@rtorr

また、本番環境で意図しないdomノードは問題ないと思います。

どうして？ （私はあなたが間違っていると言っているのではなく、あなたの理由を聞きたいだけです）

たぶん、prodドメインを定義するための設定を追加します。 prodドメインが設定されていない場合は、常にDEVモードに関する警告が表示されます（ドメインURLの設定要求があります）。設定されている場合は、URLがprodドメインと一致する場合にのみ警告が表示されます。 開発者に通知したいサービスをバインドすることもできます

ここで建設的な議論ができてうれしいです。 私が問題を解決するのを見ることができる2つの解決策がここにあります。 WebpackはNODE_ENVを強制的に指定することができ、Reactはこれを使用してDEVをPRODに出荷する人々をより簡単に回避できますが、それはWebpackへの重大な変更になります。 私は今、Seanと、そのようなものがWebpack3でどれほど実現可能かについて話し合っています。React+ Webpackスタックの初心者とパフォーマンスを友好的に保つことは、両方のキャンプが気にかけていることです。

2番目（DOMインジェクションのアイデア）はReactが実行できることであり、Jakeが述べたように、メッセージを1日1回表示するか、却下することでUXのバランスを取ります。 問題を修正するための1行の変更であり、再デプロイする必要があります。 私は経営陣がびっくりすることを望まないことに完全に共感します。

より多くのReactサイトを出荷する場合は、FBが何かを提供するために取り組んだはるかに高速なエクスペリエンスを提供する必要があります。 誰かがより良いアイデアを持っているなら、それらを提案してください。

@jakearchibald

どうして？ （私はあなたが間違っていると言っているのではなく、あなたの理由を聞きたいだけです）

上記の私のコメントに戻ると、開発者に事前に知らせることができない限り（これは解決すべき実際の問題のようです）、開発者に警告を表示して製品の価値を下げるのは極端なことです。 多くの場合、これは開発モードのパフォーマンスよりも製品に悪影響を与える可能性があります。

私たちが何をしようとも、誰かがデフォルトのものを本番環境に出荷しようとしているのですが、本番環境をデフォルトにしてみませんか？ それほど大きな影響がないところまで開発モードを改善してみませんか？

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

@jakearchibaldええ、両側に問題があるようです。 私は、あなたが提案しているものであっても、このスレッドの人々が何か良いものを思い付くと信じています。 Y'allは素晴らしいFYIです。 多分極端なのが答えです。

ユーザーがReact開発ツールを実行している場合にDOMノードの警告を挿入して、通常のユーザーがそれを経験しないようにすることはできませんか？

@jakearchibald

dev-modeをオンにして起動するサイトも問題ありません。 たぶん、メッセージは1日に1回だけ却下する必要がありますか？ ただし、期間が長いほど、ライブで終了する可能性が高くなります。 永久に無効にできる場合は、最初の場所に戻ります。

サイトが立ち上げられたとき、誰かが「準備ができている」と判断したので、それは悪いことですが、大惨事ではありません。 ただし、（おそらく正確な数はわかりませんが）数十万の開発者がサイトを破棄する必要があります（DOM警告は、サイトの他の部分とどのように相互作用するかわからないため、そのように扱う必要があります）。また、警告が表示された状態でサイトを使用できる場合）1日に5回、または1回だけ警告することは大惨事です。 ほとんどの開発者はビルドチェーン（カスタム、create-react-appなど）を正しく設定しており、その警告をまったく使用しないため、それを取り除くことができる必要があります。

@ dan-gambleただし、React Dev Toolsを使用していない開発者は、この警告の最も緊急のターゲットです。

@Pajn潜在的に、Chrome拡張機能をダウンロードしたからといって、自動的にprod / devスイッチを意識するようになるとは思いません。

@ dan-gambleいいえ、もちろん違います。 しかし、それなしでアプリ全体を開発している人がいます。これは、開発ツールをあまり使用していないため、縮小されたコードに対する現在の警告が表示される可能性が低いことを示していると思います。

私は通常、ポイントがすでにもたらされていると感じたときにそのような長い議論に追加することはありませんが、これに同意し、このポイントを強調したいと思います：DOMに触れて、開発バージョンを使用していることを警告します大きな間違いになります。 私の知る限り、他のフレームワークにはその前例はありません。

すべてのチュートリアル、すべての遊び場、開発モードを使用してReactを教えるすべての小さなサイドプロジェクトを想像してみてください。 Reactで何か楽しいことを探求したり、テストケースを分離したりするために、私が一緒に投げる小さなテストサイトはすべてあります。 手動で無効にしなければならなかったこれらのサイトのすべての警告に反応するなら、私は信じられないほど怒っているでしょう。 それは圧倒的な親のように感じ、 Reactを使用することを積極的に思いとどまらせます。なぜなら、何か新しいことをしようとすると、手首を叩くからです。

2時間ごとでもやってる？ いいえ、結構です。 このような絶え間ないしつこいことは確かにユーザーがReactで開発することを思いとどまらせるでしょう、そして私は正直にそれが人々を他のフレームワークを採用するように遠ざけるだろうと思います。 たぶんそれはChrome開発者が望んでいることですか？

はい、これはどういうわけか本番環境に移行するという事実は言うまでもありません。特定のチームにReactを採用するよう説得するのはすでに十分に困難であり、それは彼らにとってそれに対する弾薬です。

私がReactで最も気に入っているのは、 ReactDOM.render(...)を呼び出すまで何も行わないことです。そうすると、指示された場所にのみデータが配置されます。 だからこそ、それはとても良い、孤立した、機能的なライブラリです。

人々が縮小されていないバンドルを出荷しているかどうかも検出する必要がありますか？ 必要なときにキャッシュしていない場合はどうでしょうか。 彼らがnginxを最適に構成していない場合はどうですか？ または、必要なときにshouldComponentUpdateを使用しないでください。 または、必要のないときにすべてを不必要にレンダリングしていますか？

パフォーマンスが悪いのにはいくつかの理由があり、Reactの開発モードだけでそれを非難するのは間違っています。 サイトを展開するときは、最適化されたサイトを展開する方法を理解していることが完全に期待されます。 私たちにできることがないというわけではありませんが、この問題の主な理由は、ベンチマークの作成者がデューデリジェンスを行っていないことであり、そのためにお金を払う必要はありません。 それを呼び出す別の方法を見つける必要があります。

私は、正しい解決策であると私が考えるものをフォローアップするつもりでした。ツールにこれらの種類の制限を入れてください。 Webpackや、本番用にサイトをビルドするために使用するツールが、これらのチェックを強制する必要がある場所であることを確認してください。ビルドプロセスで課したいあらゆる種類の制限があります。

WebpackがNODE_ENV設定を強制することに関して（おそらく、リポジトリにすでに問題があります）、env設定に依存しないライブラリを使用するのが難しくなりませんか？

それとも、NODE_ENVの使用を検出し、コードがそれを使用する場合にのみ強制するという考えですか？

「2時間」にこだわるのはやめましょう。 それが機能する限り、それは任意の期間である可能性があります。

さらに、ローカルストレージイベントは、オリジンごとに1回だけ却下する必要があることを意味します。 1つのページに複数のデモがある場合、1つを閉じると、他のデモも閉じられます。

警告が有効になった場合、それは迅速な修正を保証するのに十分な大きさです-ユーザーに利益をもたらすものです。 Reactが公の場でどのように見えるかが心配な場合は、このような不必要な速度低下を避けたいと考えています。

確かに、これは不正なキャッシュヘッダーなどを検出しません。これは、「開発モード」のみを検出することです。 また、「滑りやすい坂」の議論は役に立ちません。

開発者が別のビルドツールを使用したり、それを本番モードに移行しなかったりした場合にも同じ問題が発生するため、問題をビルドツールに移動することは有用ではないと思います。 開発モードフレームワークはすでにコンソール警告を生成しますが、それは明らかに機能していません。

これはベンチマークだけではなく、実際のWebサイトに関するものであり、スイッチが切り替えられなかったため、実際のユーザーの実行速度は遅くなります。

@jakearchibald私の感情的なものへの合理的な反応をありがとう。 Reactでサイトが遅くなる理由はたくさんあるのは確かなポイントだと思います。 開発モードの大まかなチェックやブラウザ内の警告よりも優れたパフォーマンスの改善を提案できる方法を知りたいと思います。 Reactアプリを分析し、開発モードなどのすべてから再レンダリングが多すぎるまで、パフォーマンスに関する真剣な提案を提供するツールがあれば、それははるかに便利です。 そのような一般的なツールは、webpack、browserifyなど、あらゆるパイプラインに接続できます。

これが私が言いたかった主なことです。いつか、jsbin、チュートリアル、さらには小さなテストサイトをまとめてfile：//プロトコルで開くなど、5〜10の異なる場所でReactdevモードを使用する予定です。 強制的なブラウザ内警告は、この種の柔軟な開発に対して敵対的であり、これはWebが非常に優れている点です。 Web上のドメイン間でReactを学習しているので、これらの警告はどこにでも表示されます。

警告が有効になった場合、それは迅速な修正を保証するのに十分な大きさです-ユーザーに利益をもたらすものです。 Reactが公の場でどのように見えるかが心配な場合は、このような不必要な速度低下を避けたいと考えています。

開発者固有の警告がエンドユーザーに表示される可能性を許可することでさえ、私には受け入れられないようです。 遅いサイトも1つですが、このようなメッセージは、特にセキュリティに重点を置いたサイトの場合、ユーザーの信頼を損なう可能性があります（銀行のサイトで突然不可解なエラーが表示された場合は、喜んでいただけますか？）Googleはすべてのサイトで問題ありませんかほんの一瞬でも、ユーザーは突然この警告を受け取りますか？

さらに、ローカルストレージイベントは、オリジンごとに1回だけ却下する必要があることを意味します。 1つのページに複数のデモがある場合、1つを閉じると、他のデモも閉じられます。

これを重複排除するためにlocalStorageに依存することはできません。 localStorage （またはその他のローカル永続データ）がどの間隔でもクリアされないという保証はありません。

編集：また、 {INTERVAL}ごとに1回だけエラーを表示することで、決定論的に再現できないため、再現とデバッグがはるかに困難になりました。

解決する必要がある2つのケースがあります：

• 偽のベンチマーク、パフォーマンステストの防止：大きな大きなコンソールメッセージで簡単に解決できます。
• DEVを本番サイトに出荷しないようにする：人々は本番環境でdevtoolsを開かない。

DOMに触れることに反対する議論は説得力があります。

大きくて派手で明白なコンソール警告がある場合、本番環境に出荷する前に、開発バージョンを使用して、この本当に明白なコンソールメッセージが表示される可能性があります。 あるいは、いくつかのコードがすでに本番環境に出荷されているかもしれませんが、別のプロジェクトでは、コンソールメッセージを見逃すことは不可能な次の反応バージョンを使用します。 多分彼らは彼らが本番環境に出荷したそのサイトを覚えていて、そこでDEVが有効になっているかどうかをチェックするでしょう。

コンソールメッセージは教育的なものになります。たとえば、React開発を行う人なら誰でも、DEVには本当に重要なことがあることを知っており、開発にReactを使用するたびにそれを目にします。

私はhttps://github.com/facebook/react/pull/8782について躊躇していました。なぜなら、人々は一般に、取り除くことができない警告を好まないからです（https://github.com/facebook/react/issues/を参照）。 3877）、しかし、代替案を考慮すると、それは許容できる解決策かもしれません。

奇妙。 localStorageを使用すると、他の方法ではカバーされていないサイトでEUのCookie法が適用されますか？

開発中の有益な警告が良い考えであるなら、なぜ他のライブラリがそれを行わないのですか？ さて、1つの理由はこのような問題のためです。 他の人がこれをしたい場合、彼らも同様のUIをポップアップする必要がありますか？ それらをすべて閉じる必要がありますか？

これを処理するために、より中心的なものがあれば理想的だと私には思えます。

おそらくChromeには開発モードがあるのでしょうか？ ライブラリはホストに開発モードであることを通知し、Chromeはバッジを追加するかポップアップしてそのことを示すことができます。

おそらく、react devtools拡張機能を利用して、devモードでreactを使用してページを開くときに、通知や明らかな何かを表示できると思いますか？

@sebmarkbage

開発中の有益な警告が良い考えであるなら、なぜ他のライブラリがそれを行わないのですか？

私は誰かが最初である必要があると思います。 Angularにも同様の問題があり、 http：//code.govのようなものが開発モードで起動します。 Reactが他のフレームワークでは捕まえられないようなものを捕らえ始めたら、私はそれらに同様の変更を加えるように促します。

私は彼らに同様の変更を加えるように促します。

@jakearchibaldは、各フレームワークが独自の警告を提供する必要があることを示唆していますか？ 本番環境で独自の開発警告を提供するフレームワーク/ライブラリの標準を設定することは素晴らしいアイデアではないと思います。 プラットフォームで標準化しようとすべきではありませんか？ @sebmarkbageが述べたように

おそらくChromeには開発モードがあるのでしょうか？ ライブラリはホストに開発モードであることを通知し、Chromeはバッジを追加するかポップアップしてそのことを示すことができます。

これは素晴らしいアイデアだと思います。 前例：Safariには、DevToolsにアクセスするために有効にする必要がある別のモードがあります。 Chromeが同じことをした場合、DEVモードのインジケーターとそれをトリガーするAPIを安全に追加することもできます。 このインジケーターは開発者にのみ表示されるため、ユーザーエクスペリエンスを損なうことはありません。

ブラウザベンダーがそのようなことを実装するのを待っていませんか？

@jideはい。ただし、この問題に迅速に対処するよりも正しく対処することが重要です。 また、標準化の取り組みを検討する前に、単一のブラウザーで実装することもできます（必要な場合）。

@aweary

各フレームワークが独自の警告を提供する必要があることを示唆していますか？

各フレームワークが独自の開発モードを提供していることを考えると（そしてそのモードはフレームワーク間で大きく異なる可能性があります）、フレームワークが同様に独自の方法で警告を実装する必要があることは完全に公正なようです。

ブラウザは、devtoolsがページに公開されないようにするためにある程度の長さになっています。 devtoolsをここへの参入障壁にしている場合、DOM警告が見逃すことのない多くのユーザーを見逃すことになります。 DOM警告は単純であるだけでなく、プラットフォームの依存関係が少なく、より多くの開発者に届きます。 よりシンプルで効果的なサウンドは勝利のようです。

@gaearon Chrome DevTools側では、ウェブプラットフォームとフレームワークの作成者が重要な警告を通知するために使用できるライブの「違反API」についてブレインストーミングを行ってきました。 これらは、今後の監査パネルの更新のようにどこかに表示されます。 それはあなたの質問に似ているように聞こえ、DEVモードの検出で警告をトリガーするために使用できます。

この特定の問題については、当初の計画よりも少し大きな音が聞こえる可能性があります。 コンソールログメッセージと同様の違反パネルでは、パネルが洞察を提供することを知っている必要があります。 おそらく、フレームワークがメッセージングで標準化できるページの下部に非常に目に見えるページオーバーレイを表示するための追加のUXルームがあります。 休日の週末の後、@ paulirishと@ s3ththompsonの考えをループします。

Fwiw、私の推測では、このAPIはあと数か月は準備ができていません。 その場合、最初はカナリアでのみ利用可能になり、6〜7週間後には安定する可能性があります。

DOM警告は、より単純であるだけでなく、より効果的であるように思われます。

私はこれについてジェイクに同意します。 DevToolsソリューションについておしゃべりを続けましょう。ただし、APIがニーズに合わない場合や、タイムラインがさらに進んでいない場合に備えて、Reactがフォールバックとして何を実行できるかについても理解したいと思います。

各フレームワークが独自の開発モードを提供していることを考えると（そしてそのモードはフレームワーク間で大きく異なる可能性があります）、フレームワークが同様に独自の方法で警告を実装する必要があることは完全に公正なようです。

@jakearchibald標準とは、複数のフレームワーク（またはスイートで続くライブラリ）を利用するページを設定すると、エンドユーザーに任意の量の非決定論的にレンダリングされた不可解な警告が表示される可能性があることを理解していますか？

ブラウザは、devtoolsがページに公開されないようにするためにある程度の長さになっています。

そして、その理由は少なくとも部分的には、開発者固有のメッセージングをエンドユーザーに公開してはならないためだと確信しています。

DOM警告は、より単純であるだけでなく、より効果的であるように思われます。

ソリューションの単純さや有効性に異議を唱える人は誰もいません。 それは機能しますが、ユーザーエクスペリエンスを損なうことを犠牲にして。 ユーザーに悪影響を与える可能性があるのは速度だけではありません。

Fwiw、私の推測では、このAPIはあと数か月は準備ができていません。 その場合、最初はカナリアでのみ利用可能になり、6〜7週間後には安定する可能性があります。

@addyosmaniがより良い解決策であるなら、それがどのように問題になるかはわかりません。 Reactへの変更はメジャーリリースに含まれますが、リリースのタイミングに関しては未定だと思います。

決定されたソリューションは、将来のすべての開発に影響を与える可能性があります。 その文脈での数週間対数ヶ月の問題は、許容可能なIMOです。

フレームワークが自分たちで配置しなかったものをDOMに挿入すると、一部の開発者が侵入したと感じることを理解しています。 しかし、ページの下部にある「このサイトはDevModeにあります」というバナーは、ユーザーエクスペリエンスに大きな影響を与えない、これに対する優れたソリューションになると思います。 多くの人がなぜ反対を考えるのかを理解したいと思います。

@aweary ：「セキュリティに重点を置いた」サイトがDevModeで起動した場合、問題が修正されるまで信頼されるべきではありません。 「devMode」には、無効化されたCORSチェックや公開されたテンプレートソースコードなど、あらゆる種類のセキュリティ関連のショートカットを含めることができます。サイトがセキュリティに重点を置いている場合、これは発生してはなりません。

（「DevMode」はReactで非常に特殊な意味を持っていることを認識していますが、ここでは開発者以外の視点を想定しようとしています）

@aweary

標準を設定すると、複数のフレームワークを利用するページが、エンドユーザーに表示される非決定論的にレンダリングされた不可解な警告の任意の量をもたらす可能性があることに気づきましたか？

私は絶対にそれを理解しています。 開発モードの複数のフレームワークを含むページは、正当な理由もなく、ユーザーエクスペリエンスに深刻なダメージを与えます。 あなたはむしろそれが見過ごされ、固定されていないことを望んでいるようです。 むしろ、開発者以外の人（開発者を対象とした目に見えるメッセージ）にとっては非常に悪いので、開発者はそれをすぐに修正して、はるかに優れたユーザーエクスペリエンスを作成したいと思います。

ユーザーに悪影響を与える可能性があるのは速度だけではありません。

誰かが他のことを主張しているのを見ませんか？ 私はこの種の反応についてかなり悲しいです😞

あなたはむしろそれが見過ごされて固定されていないことを望んでいるようです

@jakearchibaldそれは奇妙な結論のようなものです、私がこれを修正したくないのであれば、私はここであなたと話をするために私の自由な時間を費やすことはないと思いますか？ 私があなたの解決策に同意しないからといって、私がそれを未解決のままにすることを辞任したという意味ではありません。 それは本当に不公平です。

むしろ、開発者以外の人（開発者を対象とした目に見えるメッセージ）にとっては非常に悪いので、開発者はそれをすぐに修正して、はるかに優れたユーザーエクスペリエンスを作成したいと思います。

それは私が基本的に受け入れられないと思うことです：あなたは最初にユーザーを明示的に罰しているのです。

「セキュリティに重点を置いた」サイトがDevModeで起動した場合、問題が修正されるまで信頼されるべきではありません。

@surma devモードは本質的に安全ではありませんが、ユーザーにそれを伝えても問題ないと想定するために回線を踏み越えているにもかかわらずです。

開発ツールを開いたり有効にしたりする必要があるソリューションでは十分ではないと思います。 これに気付くには、QA、管理者、場合によってはエンドユーザーに表示される必要があります。 開発者はこれを見るのにあまりにも慣れているでしょう。 問題のあるssl構成が強調表示される方法と同様です。 それほど多くある必要はありませんが、誰かがそれについて質問し、それを修正することに気付くのに十分です。

DOMへの注入には、多くの理由で問題があります。 私たちはDOMライブラリであり、DOMエントリポイントを持っているので、Reactの方が少し実現可能です。 DOM固有ではなく、ワーカーで実行される可能性のあるライブラリの場合は困難です。

ファビコンを明示的にオーバーライドする方法を提供している限り、ファビコンを変更できる可能性があります。 多くのサイトには、開発モード用に個別のファビコンがすでにあります。

DOMを適切に維持できない可能性のあるReactのエラーを処理するためのデフォルトのエクスペリエンスを理解する必要があります。 マスターの現在のデフォルトの実装は、エラーがスローされた場合、ツリーからReactコンテンツを削除します。 それも侵襲的です。

開発モードになっていないことを検出する方法があれば、そのエラーモードをトリガーできます。 その場合、開発モードに永続的にオプトインするための確実な方法が本当に必要です。

問題のあるssl構成が強調表示される方法と同様です。

これはまさに私が完璧だと思うようなものです。 ユーザーは、アクセスしたサイトに関するセキュリティ情報を提供するブラウザにすでに慣れています。パフォーマンス情報は、そこから大きく飛躍するものではありません。 さらに、潜在的なパフォーマンスの問題を報告するすべてのフレームワーク/ライブラリで一貫性があり、ユーザーのワークフローに直接干渉することはありません。 👍

私はファビコンのアイデアが好きです：目立つ、devtoolsや拡張機能なしで動作し、誰もが目立つ、ユーザーに害を及ぼさない、注目を集めるためにアニメーション化できる、開発者が消えたくなるほど迷惑。

DEVモードをオプトインにするのはどうですか？
悪いDXは気づきやすいので、「良いUX」側で誤りを犯します（そして、このユーザーのような問題のIMHOは、開発者が選択できるのに対し、選択できないため「勝つ」必要があります）。
いくつかのフレームワークはすでにこれを行っていると確信しています（正しく思い出せばRelayのように）。

それを実装する方法に関する提案：

• NODE_ENVが明示的にdevelopmentに設定されている場合にのみ、開発モードを有効にします
• グローバル__DEV__が=== trueの場合、開発モードを有効にします
• ユーザーランドで有効にするデバッグツールモジュールをエクスポートする

他の2つはガードなしでハードコーディングされ（ if(NODE_ENV === 'development')ステートメントなど）、とにかく本番環境に出荷される可能性があるため、最初の方法が最適と思われます。

@mattecapuに関する私の2番目のコメントを参照してください。 https://twitter.com/sebmarkbage/status/820047144677584896

開発者がDEVモードで実行することから始めることを強制する同様の方法がある場合、デフォルトが何であるかは問題ではありません。 しかし、遅れると本当に悪いです。

ここでコメントすることはたくさんあり、私は考えていますが、開発者の警告を無効にする方法の問題だけを具体的に検討したいと思います。

私は、特定の1つのブラウザで一定時間DOM警告を無効にするボタンの大ファンではありません。 @jlong​​sterが指摘しているように、それが頻繁に発生する場合、開発者にとっては苦痛です。 しかし、私にとってもっと重要なことは、ブラウザ固有の動作の変動性を導入することです。これは、バグの再現性を「私のマシンでは正常に機能する」ことに簡単につながる可能性があります。

デフォルト値が["localhost", "127.0.0.1"]で、開発ボックスと見なされるドメインを一覧表示するレンダリングに送信されるパラメーターをお勧めします。 次のようになります。

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

現在のドメインがリストにある場合、開発者の警告は表示されません。 そうでなければ、そうします。 この体制の下で：

• localhostまたは127.0.0.1を使用してローカルマシンで開発ビルドを使用する：開発者への警告はなく、開発者のアクションも必要ありません。
• 別のホスト名を使用する開発マシンで開発ビルドを使用する： renderに渡されるリストにドメイン名を追加するまで、DOM警告が表示されます。 その後、DOM警告が表示されることはありません。
• prodマシンでdevビルドを使用する：Reactをprodバージョンに切り替えるまでDOM警告が表示されます。

このソリューションについて私が心配していることの1つは、開発者がコード内のすべての開発サーバードメインのリストを残す可能性があり、そのコードが本番環境に移行する可能性があることです。 開発サーバードメインを秘密だと考えている企業にとって、それは問題になるでしょう。 考え？

@aickinこのアプローチの問題は、ユーザーが構成を認識している必要があり、次に、それが解決している問題を認識している必要があることです。 問題は、人々がそもそもdev / prodの違いに気付いていないということです。

編集：気にしないでください、なるほど、開発中のDOM警告はまだあります。

サーバー側の環境では、デバッグの詳細を含む「特別な」エラーページを表示し、本番環境では提供しないように指示することで、これを修正しています。

カスタムエラー境界を指定しない限り、Reactを「フェイルファスト」にしてビューをアンマウントする予定なので、教育ページとして機能するデフォルトの「レッドボックス」エラー境界を開発に追加することもできます。

その後、ユーザーが本番環境で初めてバグを抱えたときに、特別な詳細なエラーメッセージが表示されます。 これは、DEVビルドについて教育する機会になる可能性があります。

しかし、ページの下部にある「このサイトはDevModeにあります」というバナーは、ユーザーエクスペリエンスに大きな影響を与えない、これに対する優れたソリューションになると思います。 多くの人がなぜ反対を考えるのかを理解したいと思います。

ほとんどのユーザーは、Webアプリであることがわかっている場合、Webアプリを嫌います。なぜですか。 以前のWebの一般的な考え方は、Webが画面に表示されたときに実行されるというものだったため、Webの動作がどれほど悪くても、ユーザーはWebが悪いことを知っていました。 ただし、Web上で優れたUXを作成することは完全に可能ですが、そのためにはDOMを所有している必要があります。 誰かがランダムなバナーを任意の場所に挿入すると、間違った要素がスクロールし始めたり、画面全体がスクロール時に再描画されたり、ドラッグジェスチャなどに干渉したりする可能性があります。 重要なのは、そのバナーが上がっている限り、そのバナーがなくなったときの経験が同じであることがわからないため、開発できないということです。

フレームワークソリューションとして、私はファビコンのアイデアが本当に好きです。それは開発を妨げず、ユーザーにとって奇妙に見えず、UXを破壊する可能性はありませんが、注目されるでしょう。 ただし、実際には、その時点で単一のライブラリまたはフレームワークに対してのみ機能し、ワーカーで実行されるライブラリに対してはまったく機能しません。 実際の解決策は、複数のフレームワークとライブラリをサポートでき、すべてのコンテキストからアクセスできるブラウザを介してこれを行うための優れた方法です。

複数のフレームワークとライブラリをサポートし、より明確であるが許可要求を必要とする別の解決策は、ブラウザー通知を表示することです。

アイデアは次のとおりです。reactのホームページにある入門ドキュメントを更新して、reactアプリの作成をより強力にプッシュします。 そして、それらのドキュメントでnpmビルドの重要性を強調します。 DOM警告は必要ありません。意識が必要です。

@ropilzは、スレッドの前半で「開発者に通知したいサービスをバインドすることもできます。

私が理解しているように、ここで解決される根本的な問題は

• 本番環境のエンドユーザーが開発モードで実行されているサイトを体験したときに、どういうわけか開発者に警告する
• 開発者が本番環境でconsole.logメッセージ（またはそのことについてはDOM警告）を見ることに頼ることはできません。ただし、それらの開発者が本番サイト自体を積極的に使用している場合を除きます（またはエンドユーザーに依存している場合、QA /これらの警告を開発者に報告するためのサポートチームなど）
• 開発者の聴衆を対象としたDOMの目に見える警告をエンドユーザーに示す（有効な）UX引数があります。

フレームワークがエンドユーザーに表示されるサイトにその場で警告を表示するのではなく、開発モードの警告を送信するCSPのreport-uriに類似したものがある場合はどうなりますか？

明らかに、次のような考慮すべきことがいくつかあります。

1. このようなレポートは、理想的にはデフォルトでオンになりますが、デフォルトのreport-uriはどうなりますか？ （ https://report-uri.ioのように、各フレームワークが独自の無料サービスをホストすることを期待しますか？ （これは、React＆Angularのような大規模な企業主催のフレームワークでは可能ですが、小規模なオープンソースフレームワークでは確かに実用的ではありません）。 Preact、Vueなど）
2. 警告が報告されたら、サイトの所有者/開発者はどのように通知されますか？ （おそらく、これらのレポートを監視し、保守者を追跡/通知するのを支援することにより、開発者以外の人がプロジェクトに参加するための良い方法ですか？）

私はこの提案が単なる思考バブルであることを完全に認めており、これがどれほど実用的であるか、または実際にどのように機能するかについては考慮していません。 しかし、CSP / HPKPレポートでは、「本番環境の問題に関するレポート」の課題はすでに部分的に解決されているように思われるので、それを提起したいと思いました。

一歩下がって、Reactがフレームワークであることを理解することが重要です。 してはいけません：

• 開発者へのリマインダーとして視覚的に何かを提示するようにDOMを変更します。 開発者の邪魔をせず、本番環境でポップアップが発生した場合にユーザーの信頼を失うことなく、すべての環境で機能するものを理解して開発しない限り、これが箱から出してうまく機能する方法はありません（私の経験が何らかの兆候である場合、これは起こります非常に頻繁に、多くの人がそれをオフにするためのクイックフィックスを展開することができません）。

• ファビコンを変更します。 ファビコンは煩わしくキャッシュされ、ブックマークに使用され、他のアイコンが指定されていない場合はモバイルデバイスに保存されたWebアプリアイコンなどに使用されます。これにより、誤って（または意図的に）開発モードに本番環境で展開してブランドのロゴを消去するリスクがあります。

• ブラウザの通知。 あなたが見られているとき、あなたはおそらくユーザーによって見られているでしょう。 通知をポップアップすると、ブラウザのアクセス許可が要求され、ユーザーが理解できない奇妙なことがポップアップ表示されます。 私の経験では、これらが開発者にほとんど見られるという仮定は、まったく逆であり、ユーザーの破滅を信頼する可能性があります。

ベビーシッターの開発者にとっては、Reactの仕事ではありません。 私は次のいずれかを提案します：

1. 開発モードをオプトインします。開発者が何かをデバッグできないことに気付いたら、それをオンにする方法を調べます（これはどこでも文書化する必要があります）。 いいえ、それをオフに戻すように指示するのはReactの仕事ではありません。 彼らの問題。

2. 単純なconsole.logメッセージのままにしておきます（これは無効にできる必要があります）。 開発者にそれを見つけて処理させます。 そうでなければ、まあ。 すべての組織に連絡を取り、組織に正しく行動させることはできません。 スケーラブルではありません。

警告を表示するためにDOMに触れることに同意しない必要があります。 ReactはDOMライブラリであるため、簡単でシンプルに見えますが、すべてのライブラリがDOMに独自の警告を表示する必要があるかどうかを想像してみてください。 それは完全な混乱になります。

開発者が使用するライブラリは非常に多く、おそらく独自の開発モードがあります。 process.env.NODE_ENVをproductionに設定することは、ブラウザのモジュールをバンドルする際の一般的な標準になっていると思います。 これは私たちが意識を向上させるために必要なものです。

私は、Reactのドキュメントが開発ビルドと本番ビルドの間に違いがあることを目立つように示していないことに同意します。 ドキュメントを開くときは、高度なガイドを読んで、開発ビルドと本番ビルドの違いを読む必要があります。 タイトルはOptimizingPerformanceです。これは、Reactを使用しているため、初心者は高速だと聞いているので、絶対に見てはいけません。 クイックスタートセクションに「本番環境でのReactの使用」などのタイトルの別のドキュメントを含めるようにドキュメントを改善できると思います。

初心者は通常、上級ガイドを読みませんが、タイトルが十分に明確で重要に見える場合は、クイックスタートでいくつかのリンクを開きます。 Reactを学び始めたとき、それが私がやっていることだからです。 スタートガイドは読みませんでしたが、クイックスタートセクションのいくつかのページを読みました。

私たちが取ることができる別のアプローチは、Reactが開発モードで使用されているときにコンソールに警告を表示し、そのポイントをドキュメントに修正するためのリンクを表示することです。 開発者向けに本番環境でコンソールを開くことは珍しいことですが、ローカル環境では開発時に確実にコンソールを開きます。 このようにローカルで開発する場合、本番環境に公開する前に何かを行う必要があることに気付くでしょう。

コンソールの警告にもかかわらず、 http：//code.govが起動しました。 これはまさに私たちが防ぐことを目指すべき種類のことです。 （そのサイトはAngularですが、同じことがReactにも当てはまります）

誰かが彼らに連絡したい（またはPRを送信したい）場合のcode.govの問題は次のとおりです： 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.

私はこれまでAngular2を使用したことがありません（この場合は初心者になります）。 警告が表示された後の最初の反応は、 enableProdMode()を呼び出してみることです。 動作しません。 Angularの場合のコンソールメッセージは改善できると思います。 魔法に頼るのではなく、ドキュメントを指す必要があります。

Angularドキュメントを開いても、本番ビルドについては何も表示されません。 これはAngularとReactの両方にとって問題だと思います。 どちらも開発モードを使用しますが、それを無効にする方法については、ドキュメントで事前に説明していません。 そのため、ドキュメントの改善は開発者の教育に大いに役立つ可能性があります

開発者が「間違い」を犯したときにユーザーに警告を表示することに反対しているわけではありませんが、ランダムなDOM要素を挿入するのは煩わしいだけです。 ブラウザーがHTTPSの問題を処理する方法が気に入っています。ブラウザーには、サイトが安全でないことを示す専用のUIがあります。 パフォーマンス関連のステータス用のものはありません。 一般的なWebパフォーマンスに関する懸念が高まっていることを考えると、ブラウザベンダーが、アクセスしているサイトがダメだとユーザーに伝える方法を考え出さない理由がわかりません。

これはツールレベルで対処する必要があるため、webpackとBabelが開発者にNODE_ENVを設定する利点を通知できる可能性があります。

@pveyes同意しました、私はAngularチームに同じことを言いました。

@matthewpこのhttps://github.com/presidential-innovation-fellows/code-gov-web/issues/129についてははるかに古い問題があり、Angularチームは直接連絡を取り、修正を提供しました-あるようですそれを適用したいという欲求はほとんどありません。 質問は、DOM警告がこの修正をより緊急にしたのでしょうか、それとも最初から開発モードでの起動を妨げたのでしょうか？

質問は、DOM警告がこの修正をより緊急にしたのでしょうか、それとも最初から開発モードでの起動を妨げたのでしょうか？

おそらく彼らは開発中の警告、グーグルがそれを無効にする方法、そしてそれを無効にする方法を見るでしょう。 その後、彼らが忘れているので、将来それを実現することなく、開発モードでそれを展開しました。 開発中は、DOMのランダムなチャンクを挿入できないように、本番環境のように見せたいと考えています。 QAまたはステージングシステムでこれを確認することはできません。これは、本番環境を示すものではないためです。

そのため、サイトのUXを台無しにするこのことを無効にする大量のジャンクコードになってしまいます。 開発中にそれを無効にした元のエンジニアが必ずしも覚えているとは限りません。 彼らはそれが生産に入る前に進んだかもしれません。

code.govでの展開プロセスがどのように機能するかはわかりませんが、政府の請負業者として経験したようなものである場合、本番環境への偶発的な開発モードの展開は次のいずれかになります。

1. 展開全体の完全なロールバックを強制し（そのうちのいくつかは、UIの変更からサーバーソフトウェアの更新まですべての承認を取得してバンドルするのに6か月かかります）、おそらく翌日、何が起こったのかに関する会議とフォローアップの書類を受け取ります。新しい展開ウィンドウをスケジュールします（UIに警告が1つあるために、DBスクリプトやサービスなどがすべて開発モードであったかどうかを何度も尋ねられます）。 私はこれが非常に小さなことで起こるのを見てきました。 YMMV以外の例外が発生する場合があります。

2. ユーザーに気づかれ、修正されますが、機能に影響を与えない可能性が高いため、次の展開ウィンドウまで更新されません。 したがって、すべてのユーザーが数週間または数か月間それを見ることができます。

少なくともそれは私の経験でした。 重要なのは、展開直後にDOMの侵入に気付いたとしても、インフラストラクチャ/プロセスがどのようなものかわからないため、すぐに修正できるものではない可能性があるということです（修正できるはずですが）。

＃7360（黄色のボックス）がマージされると、警告メッセージがより目立ちます。 黄色のボックスにメッセージを追加することもできます（「React開発モードの警告」と呼びますか？）。

Angularドキュメントを開いても、本番ビルドについては何も表示されません。 これはAngularとReactの両方にとって問題だと思います。 どちらも開発モードを使用しますが、それを無効にする方法については、ドキュメントで事前に説明していません。 そのため、ドキュメントの改善は開発者の教育に大いに役立つ可能性があります

インストールページにあります。

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

パフォーマンスの最適化について：

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

ドキュメントがそれについて前向きではないと言うのは公平ではないと思います。

ドキュメントを開くときは、高度なガイドを読んで、開発ビルドと本番ビルドの違いを読む必要があります。 タイトルはOptimizingPerformanceです。これは、Reactを使用しているため、初心者は高速だと聞いているので、絶対に見てはいけません。 クイックスタートセクションに「本番環境でのReactの使用」などのタイトルの別のドキュメントを含めるようにドキュメントを改善できると思います。

最初のページ（インストール）にあります。

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

あなたが正しい。 すみません、悪いです。 プロダクションビルドは別のセクションにあると想定したので、そこでは探しず、代わりにサイドバーで関連するタイトルを検索しました（そして、[パフォーマンスの最適化]ページを見つけました）。 私はもっ​​とよく知っているべきだった。

私は実際にはReactの初心者ではないので、ドキュメントを開いて自分の仮定を確認するときに、Reactドキュメントはprodとdevについて前向きではないという理由で、インストールドキュメントを開かなかった🙇

心配ない。 それが十分に見えない場合、私はより良い配置のための提案を受け入れます。 たとえば、専用のページ（ Deploying to Production ）を作成できます。

この問題は解決すべき重要な問題ですが、強調すべき最も重要な問題ではないことを忘れないでください。 また、一番上のページでハイライト表示しても、人々がそれを見て閲覧し、忘れて、「自分が何をしているのか知っている」と思うので、それで十分だとは思いません。 だから私はドキュメントのことを過度にピボットすることはしません。

これに対処する唯一の実際の方法は、検出して通知することです。

@KrisSiegelファビコンがキャッシュされるのは良い点です。 1、2秒後に切り替えてから、数秒ごとに少しの間元に戻す必要があるのではないかと思います。 そうすれば、キャッシュとブックマークの問題が、オーバーライドされたアイコンのときにタイミングを合わせる可能性はほとんどありません。

ファビコンへのJS操作はキャッシュされないと思いましたが、おそらく私は間違っています。

このためのフックを配置するのに適切な場所は、ChromeやFirefoxではなく、webpack、Browserify、またはRollupであると私は主張します。

Reactの本番バンドルとして意図されているものをビルドしますが、本番モードを有効にしないと、ビルドエラーになります。 実行時にこれをどのように提示するかについて合意がない理由は、これが実行時に処理されるべき問題ではないことを反映していると思います。

@taion同意します。 これは間違いなく、DOMではなくビルドツールに属していると思います。

ノードenvを本番コード用に本番環境に設定する必要があると想定するためのビルドツールの場所である必要があると思います。 すべてのプロジェクトで必須というわけではありませんが、それは良い仮定だと思います。

npm run buildがターミナルで実行され、envが本番環境に設定されていない場合、デフォルトの出力とともにターミナルで赤い警告が表示されます： env is not set to production, some scripts may be in development mode

現在、webpackからそのような警告は表示されません。

編集：説明を追加

または、実際にはNODE_ENVを設定するだけです。

コンソールの警告が機能しない場合、ビルドの警告が機能するかどうかはわかりません。

ビルドはあなたのために物事を構成するか、本番用に誤って構成された場合は失敗するはずです。 少なくともReactの場合、これはビルド時間フラグです。

@jakearchibaldまだ無視される人もいると思いますが、少なくとも、警告はブラウザコンソールに隠されているため、本番環境では開かない可能性があるため、表示されないのではなく、ビルド時に表示されます。 。 最も重要なことは、経験の少ない人に、コードの作成を準備するために何をすべきかについての手がかりを与えることです。

多くの開発者はライブラリを更新しますが、多くの人がそれが正しく機能すると想定しているため、webpackやより一般的にはツールを更新しないのが一般的であり、webpackなどを更新するのは面倒かもしれません。

Reactの本番バンドルとして意図されているものをビルドしますが、本番モードを有効にしないと、ビルドエラーになります。

CDNから事前にパッケージ化されたバージョンのReactを使用することもサポートされている構成ですが、そのワークフローにはビルドステップはまったくありません。 したがって、ビルドのみに焦点を当てたこの問題の解決策は、CDNのユースケースを無視します。

正直なところ、それについてどう思うかわかりません。 ReactCDNの使用に関する開発警告の賛成と反対の両方の議論を見ることができます。

@taionビルドのみのソリューションをサポートする人として、これはカバーする重要なユースケースだと思いますか？

他の人はどう思いますか？

そこにあるドキュメントは、本番環境で.min.jsバンドルを使用する必要があることをかなり明確に示していると思います。 多分それは太字の、より大きなフォントサイズ、そのようなものを使うことができます。 しかし、誰かが自分のWebサイトの本番環境で縮小されていないReactバンドルを使用している場合、とにかく他の問題が発生します。

そこにあるドキュメントは、本番環境で.min.jsバンドルを使用する必要があることをかなり明確に示していると思います。

同意しましたが、Reactをnpmパッケージとして含める場合、本番用にビルドツールを構成する方法についてもかなり明確になっています。 この問題の要点は、ドキュメントのそのページを注意深く読んでいない人々のために成功の落とし穴を作ろうとすることだったと思います。

ただし、同意できないようです。CDNからの開発ビルドを使用することは、より積極的な開発警告で防ぐための重要なケースではないと考えています。 それはあなたの立場の公正な要約ですか、それとも私はいくつかのニュアンスを逃していますか？

CDN + devの構成は、ユーザーがReactの縮小されていないビルドを使用する必要があるという点で、明らかに間違っていると思います。 _縮小されたビルドを使用するだけ_に必要な知識の負担が少ないため、この方法で失敗することはより困難です。

webpackまたはBrowserifyでミニファイを実行したために本番環境に対応していると_考える_構成ですが、実際にはNODE_ENVを設定しなかったためではありません。CDNバンドルを介してそれを取得することはできません。

Chrome Developer ToolsのReactタブは、 DEV Modeにいるかどうかを判断するのに十分だと思います。

DOM要素を開発モードでページに挿入するフレームワークにはいくつかの前例があることに注意する価値があると思います。

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

私が知る限り、これはデフォルトでオンになっているとは思いませんが。

上記の説明に続いて、すべての制約を満たしながら、あるべきではないときにすべての人が開発モードで実行されるのを確実に阻止する完璧なソリューションを実現するという一般的な目的があるようです。 OPは、開発者とユーザーの潜在的なエクスペリエンスの間にはトレードオフが必要であると述べており、これは非常に当てはまると思います。

問題を少し言い換えようとすると、次のようになります。

• ゼロ以外の数のReactサイトは、開発モードを無効にせずに本番環境に移行します
• この数を減らしたい
• React開発者を困らせたくない
• 新規参入者をReactに延期したくない
• Reactで構築されたサイトのエンドユーザーに、典型的な開発者の警告が表示されないようにする必要があります
• 外国のDOM要素が存在するためにサイトを壊したくない

これらを考えると、適切な最初のステップは、開発モードでReactが、本番環境で無効になっていることを確認するための指示とともに、 console.warnまたはconsole.infoを介して開発モードであることを発表することだと思います。展開。

確かに、これはすべての人を捕らえるわけではありませんが、_それはまともなスタートです_。これは、不注意で本番環境に出荷する人の数を減らし、将来の改善のためにドアを閉めることはありません。

これらを考えると、適切な最初のステップは、開発モードのReactが、本番デプロイメントでこれが無効になっていることを確認する手順とともに、console.warnまたはconsole.infoを介して開発モードであることをアナウンスすることだと思います。

あなたが...開発しているときでも、それが開発モードにあることは間違いではありません。 他にどのようなヒューリスティックを使用できますか？

また、本番環境でコンソールを読み取る人がいないことを考えると、クラッシュレポートソリューションを使用した場合にログに記録されるように、タイムアウト内にスローできるかどうか疑問に思います。

あなたが...開発しているときでも、それが開発モードにあることは間違いではありません。 他にどのようなヒューリスティックを使用できますか？

現在のReactDevToolsの通知に似ているはずだと思います

開発モードになっていること、および本番サイトでは開発モードを無効にする必要があることを通知するメッセージ。 これは（理論的には）より多くの開発者に区別があり、本番環境での使用に備えるために何らかのアクションを実行する必要があることを認識させるはずです。

あなたが言うように、実際の生産ではほとんど誰もコンソールの警告を見ることはありません-そしてその時点でそれは少し遅れています。

レコードがスタックしているように聞こえて申し訳ありませんが、コンソールの警告は機能していないようです。 例： https：//code.gov。

レコードがスタックしているように聞こえて申し訳ありませんが、コンソールの警告は機能していないようです。 例： https：//code.gov。

単一のカウンターインスタンスは、それが間違いのないものではないことを示していますが、どのようなアプローチもそうなるとは思いません。

コンソールの警告によって、認識を高め、誤って開発モードを実行すべきでない人の数を減らすことができれば、これは正しい方向への一歩のように思われます。 完璧は善の敵です。

@jakearchibald

はい。ただし、code.govのビルドツールがここでフックを使用してセットアップされている場合、少なくともビルド時フックを使用するReactのコンテキストでは、これにより、観察している問題を防ぐことができます。 結局、彼らはwebpackを使用しています。

webpackがビルド警告を発するべきだと言っているのではありません。 正しい修正は、webpackがprocess.NODE_ENVを設定するか、適切な本番構成なしで本番ビルドを作成しようとすると、デフォルトでWebpackがビルドに失敗することです。

DevToolsの「違反」に関する@addyosmaniからの以前のポイントに迅速に対応したかった。 Chrome DevToolsの特定のエラーのより強力な兆候を示すプロトタイプを作成していますが、この作業はまだかなり早い段階であり、警告を表示することは（ console.warnよりも怖い場合でも） @jakearchibaldに同意する傾向があります十分な解決策。

NODE_ENV == 'development'またはホスト名がlocalhost / 127.0.0.1の場合にのみ、デフォルトでReactを本番モードにし、開発モードをオンにするのはどうですか？ ほとんどの開発者は、すぐに使用できる正しい動作を取得し、本当に必要な場合は、開発モードを手動で強制する方法が常にあります。

常にかなり複雑な条件付き（ノードで失敗する必要がないため）でそのブランチをヒットするのは理想的とは言えないようです。

ところで、webpack2の-p （「本番」モード。デフォルト設定で縮小も可能）は、ユーザーにNODE_ENVを設定します： https ：//webpack.js.org/guides/production-build

これは私には非常に賢明なようであり、webpackを使用しているほとんどすべての人にとってこの問題を防ぐことができます。 なぜ実行時にこれを処理することに固執するのですか？

ところで、webpack 2の-p（「プロダクション」モード。デフォルト設定でミニファイも有効になります）は、ユーザーにNODE_ENVを設定します： https ：//webpack.js.org/guides/production-build/#node-environment-variable。

うん。 私たちはこれを認識しています。 Webpackコアの@TheLarkInnは確かに確認できますが、私の理解では、 -pはWebpackコミュニティのATMでは広く使用されていません。 ここでの根本的な問題は、console.log警告のある現状と同様に、いずれかのソリューションがオプトインである場合、Reactユーザーに実際の変更が見られない可能性があることです。 私たちは人々に「速い」ものを出荷する際により良い変化を与えたいと思っています。

ちなみに、WebpackでDEVおよびPROD環境を簡単に検出できないこと（-pが不十分）も、 https：//github.com/webpack/webpack/issues/3216で問題を引き起こしました。

正しい修正は、webpackがprocess.NODE_ENVを設定するか、適切な本番構成なしで本番ビルドを作成しようとすると、デフォルトでwebpackがビルドに失敗することです。

私はこれを追求するつもりですが、それは私が言えることからWebpackにとって大きな変化になるでしょう。 私は個人的に、いくつかのインテリジェントなヒューリスティック（localhost、DevTools openなど）を使用して表示される明確なオーバーレイメッセージを含むランタイムソリューションで十分にカバーできると感じています。

そうは言っても、Webpack process.NODE_ENVアイテムに戻り続けると、 @ sokraまたは@TheLarkInnがこれについて意見を持っているかどうか知りたいと思います。

私の理解はそこでのあなたの理解とは異なります– -pは、webpackのほとんどの非専門家ユーザーが本番ビルドをセットアップする事実上の方法であると信じています。

著名なパッケージでさえ、 -pを使用して本番ビルドを生成します。
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

WebpackでUglifyプラグインを直接構成することは非常にまれであるため、 -pがないと、縮小されていないビルドを使用することになり、その場合、より大きな問題が発生します。

個人的には、いくつかのインテリジェントなヒューリスティック（localhost、DevTools openなど）を使用してのみ表示される明確なオーバーレイメッセージを含むランタイムソリューションで十分にカバーできると思います。

これが発生する_only_シナリオを実際に理解することなく、これが何度も撃墜されたように感じます（「フレームワークがDOMに物事を注入することは受け入れられません」）。

開発中に絶えずDOM内の永続的なメッセージや予期しないことに対処しなければならないことは、まったく受け入れられません。 ただし、ここで提案しているのは、DevModeが本番環境にデプロイされた場合にのみ表示されるメッセージです（ヒューリスティックを入力してください）。 任意の数のチェックとコンソールメッセージをツール、CI、およびブラウザー拡張機能に組み込んで、それが発生しないようにすることができます。

しかし、必死の最後の手段として、画面に表示されるバナーは適切で適切な解決策だと思います。

DevModeが本番環境にデプロイされた場合にのみ表示されます（ヒューリスティックを入力してください！）

したがって、開発者はこのメッセージを目にすることはなく、（おそらく偶然に）開発モードを本番環境にデプロイすると、突然、すべてのユーザーが見ることができるように、この新しいHTMLがアプリケーションに表示されます。

それは私にとっては罰のように聞こえます。 まだ開発モードを理解しておらず、この理論上の新しいバージョンのReactとメッセージを使用してデプロイする場合は、驚きがあり、その時点のWebアプリケーションのユーザーもそれを見ることができます。 これが開発者や会社を困惑させるのに役立つ以外に、これがどのように役立つのかわかりません。 確かに、それは彼らにそれを修正させるかもしれませんが、そのコストは私の意見では高すぎて、少しの共感を欠いています。

しかし、必死の最後の手段として、画面に表示されるバナーは適切で適切な解決策だと思います。

このソリューションの問題は、それがあまりにも理想的であり、フレームワークを開発するときは、他の企業が最高の展開ポリシーや最高のQA（存在する場合）さえも持っていない可能性があるという現実に焦点を当てる必要があることです。

はい、誰かが本番環境で開発モードにデプロイした場合、それを確認してすばやく変更できるはずです。 残念ながら、特にテクノロジー業界以外では、これは単純に不可能であるか、簡単ではありません。 ここでコメントしている人の大多数は？ おそらく、彼らの会社には、このシナリオにうまく対処できる展開プロセスがあります。 Google、Facebook、PlayStationなど。 これらのテクノロジー企業はすべてこれをうまく処理できますが、これはReactを使用するユーザーの大多数を代表するものではありませんよね？ （実際、Reactの使用に関する統計はありますか？便利です！）

はい、はい、これらの企業と政府は、展開プロセスやポリシーなどを変更する必要があります。しかし、現実はこれです。ほとんどの企業は、展開プロセスが不十分で、QAが存在しません。

私が個人的に経験した2つのシナリオを考えてみましょう。

まず、政府で働いている間、支部や部門によっては、3〜6か月ごとに1回の展開が行われる可能性があります。 これらのデプロイメントは可能な限り多くのものをロールアップし、デプロイメント全体のいずれかの部分が失敗した場合、すべてがロールバックされる可能性があります。 そのため、OWFと呼ばれるこのソフトウェアを使用していました。これは、慣れていない場合は、iframeを使用して単一のWebアプリケーションに複数のWebアプリケーションを表示するという点でiSocialに似ています（グロス、私は知っていますが、ここにいてください）。 いくつかのアプリケーションの展開に手動の構成手順があり、失敗したため、意図したアプリケーションではなく、一部のiframeに404エラーと500エラーが表示されました。

開発者は通常、展開されているシステムにアクセスできないため、問題が見つかるまでに何時間もかかりました。 その時点で、上司に他の人の上司に電話をかけてもらい、他の人に影響がないことを伝えて、展開全体をロールバックしないようにする必要がありました。 その後、数日後に誰かに構成の一部をやり直してもらう前に、大量の書類とドキュメントを記入する必要がありました。 その間、アプリケーションはその全期間中、機能できずに座っていました。

第二に、私が財務で働いていたとき、ウェブサイト上の実際のアイテムのレイアウトの代わりに開発者の名前が誤って含まれていた展開がありました（彼は何かをテストしていたと思いますか？）。 とにかく、それはすぐに気づかれました、しかしそれを修正するために、我々はその日ずっと遅くまでかかった緊急の変更管理を取得しなければなりませんでした。 そのため、顧客はこのばかげたバナーを修正する前にほぼ8時間見なければなりませんでした。

私のポイントは、開発者がDOMに配置しなかった任意の要素をDOMに挿入する場合は、細心の注意を払う必要があるということです。 特に、一部のシナリオでのみ表示することについて話している場合、誰かが初めてそれを見ると、すぐに無効にする方法を理解するので、再度気にする必要はありません。

@KrisSiegel

まだ開発モードを理解しておらず、この理論上の新しいバージョンのReactとメッセージを使用してデプロイする場合は、驚きがあり、その時点のWebアプリケーションのユーザーもそれを見ることができます。

DevToolsが開いているときにのみメッセージが表示された場合（つまり、開発者ではない本番ユーザーに表示される可能性が低いもの）に、アプローチについてのあなたの考えが異なるかどうか興味がありました。 事実上、現在のconsole.log戦略の拡張です。Reactは今日すでに採用しています。

DevToolsが開いているときにのみメッセージが表示された場合（つまり、開発者ではない本番ユーザーに表示される可能性が低いもの）に、アプローチについてのあなたの考えが異なるかどうか興味がありました。 事実上、現在のconsole.log戦略の拡張です。Reactは今日すでに採用しています。

開発ツールを開いている場合は、おそらくconsole.logメッセージが表示されるため、DOMの変更は管理が不必要に複雑であるように見え、さらに冗長です。 あなたはいつでもReactコンソールメッセージをより大きく/より魅力的にすることができます。 たぶんASCIIReactのロゴ。 彼らがそこにたまたま入った場合に誰かの注意を引くための何か。

最終的に誰かがこれに遭遇すると思いますが、Stackoverflowで警告を無効にする方法を尋ねると、誰かが警告を無効にする方法を示すコードを投稿し、遭遇した場合は単に無効にします。 ビルドツールはたくさんあり、私が過去に話をした多くの人々は、それらが混乱したり難しいと感じました（Babel 6のリリースは「楽しい」時間でした）。 あなたは単にそれらを正しく使用しない多くの人々に出くわすでしょう。

少なくともそれは私の経験です¯\ _（ツ）_ /¯

ふぅ、ついに糸の底に追いついた。 わかった。 私はこれを少しブレインストーミングしてきました。

WebpackはNODE_ENVを強制的に指定することができ、Reactはこれを使用してDEVをPRODに出荷する人々をより簡単に回避できますが、それはWebpackへの重大な変更になります。 私は今、Seanと、そのようなものがWebpack3でどれほど実現可能かについて話し合っています。React+ Webpackスタックの初心者とパフォーマンスを友好的に保つことは、両方のキャンプが気にかけていることです。

これは今のところ私のお気に入りのように感じていますが、まだ100％売れているわけではありません。

1. したがって、誰かがwebpackを実行するたびに、ENVが渡されるように強制できます。 役立つエラーメッセージは、webpackを実行するためにenv変数を提供する必要があることを示しています。

ただし、これはユーザーに重要なバウンスポイントを提供します。 誰もがprodまたはdevenvのために書いているわけではなく、envが何であるかさえ知っているわけではありません。 これについてのフィードバックを得るために、webpack / webpackで問題を提起します。私の直感では、誰もがこれを望んでいるわけではなく、同意するかどうかにかかわらず、プッシュバックを考慮する必要があります。

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

2. webpackyの解決策は、コンパイラのライフサイクルにフックできるスタンドアロンプ​​ラグインを作成し、コードが削除されているかどうか、またはENVが提供されていないかどうかを確認し、選択したフレンドリーな警告またはエラーを発行することです。

しかし、「しかし、ユーザーはそれを行う方法などを知ることは決してないだろう」という反応を想像することができます。 したがって、CRA、したがってこの問題は今のところです。

React（またはそれを必要とする任意のfw）のpackage.jsonで次のようなものをチェックする新しいリゾルバーパターンを作成できます。

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

これは、ユーザーが知る必要も気にする必要もなく、ユーザーのコンパイラ構成に自動的に適用されます。

繰り返しになりますが、本当にブレインストーミングを行います。

@TheLarkInn webpack 2の-pの現在の動作で十分だと思いますよね？ 唯一の失敗のケースは、誰かが自分でUglifyJsPluginを設定し、 DefinePluginを実行するのを忘れた場合ですが、それははるかに少ないケースのようです。

@taionはい/いいえ

-pは、コードに本番環境の「処理」を適用するだけですが、 NODE_ENVが何に設定されているかについては、何も想定しておらず、知識もありません。 これは、人々がDefinePlugin()を使用する必要性をもたらすものです。

しかし、ユーザーが本番環境でコードを実行しているのは、_guess_または_imply_に最も近い「_reasonable_」領域だと思います。 それは、コミュニティとチームが問題ないことを確認したい1つの領域です。

@TheLarkInnこれはv2で変更されたと思います： https ：//webpack.js.org/guides/production-build/#node -environment-variable

ああすみません、そうです、私は間違っています。 ただし、最適化する対象をよりきめ細かく制御したいため、頻繁には使用されません。 （言及された@addyosmaniのように）

それは本当に一般的ですか？ 私がwebpackを使い始めたとき、 -p明らかに道のりのようでした。 上で参照したように、さらに微調整を適用する理由がたくさんあるライブラリでも、 -pを使用します。

React（またはそれを必要とする任意のfw）のpackage.jsonで次のようなものをチェックする新しいリゾルバーパターンを作成できます。

"webpack"：{
「プラグイン」：「ReactEnviornmentPlugin」
}
これは、ユーザーが知る必要も気にする必要もなく、ユーザーのコンパイラ構成に自動的に適用されます。

@TheLarkInnこれを正しく読んでいる場合、リゾルバーパターンをトリガーするには、アプリのpackage.jsonでReactEnvironmentPluginを手動で指定する必要があります。 それとも私はその提案を誤解していますか？ :)

プロジェクトがReactを使用していることを検出し、それらに対して適切な環境切り替えを行うWebpackの解決の魔法を想像できますが、それはフレームワーク固有の最適化とバンドラーの緊密な結合のように聞こえ、それほど望ましくない場合があります。

反応を検出するよりも少なく、jsモジュールの説明フィールドを検出するよりも多く、プラグインを含むwebpackフィールドが含まれます。 しかし、あなたは正しいです、それは非常に緊密に結合されており、私のお気に入りのアイデアでもありません。

WebpackにReactの構成方法を理解するための「本番」モードの概念がない限り、これが実際に保証されるとは思いません。前述のように、 -pがすでに適切に機能していることを考えると、これは冗長に思えます。とにかく、webpackを使用して縮小化された本番ビルドを作成するときに、ユーザーが一般的に到達するものです。

これについてはもう少し話しましたが、合理的な解決策があると思います。

私たちは長い間、開発中のReact警告の「警告ボックス」を有効にすることを検討してきました。 ここでデモを見ることができます（PR：https：//github.com/facebook/react/pull/7360）。 警告がある場合にのみ表示されますが、開発中に非常に一般的であるため（常に修正する必要があります）、アプリの開発に5分以上費やした人は、ダイアログが表示され、ダイアログが存在することに気付くでしょう。

この変更後は、開発モードに気付くことが難しくなります。 「警告ダイアログを削除する方法」を検索して、本番用のビルドについて学習する可能性があります。 そうしないと、ある時点で警告が展開される可能性が高く、ユーザーに警告が表示されます。 この場合、私たちは単にボックスを不快に見せるのではなく、開発モードが想定されていることを実行するだけなので、React自体を非難することはないと思います。

（ちなみに、Facebookで開発中の同様の警告ボックスを長い間使用しているので、Reactの使用目的に対応しています。）

@gaearon、その提案を見て本当にうれしいです！ それは私が夢見ていたすべてです;）

サイドとして：開発者がそれを取り除く方法をグーグルで検索する必要がないように、ボックスに直接リンクを含めることを検討する価値があるかもしれません。

ええ、良い点です。 何か追加します。

@gaearon私はその解決策が非常に不快だと思います。 開発中であっても、警告がDOMに侵入することは決してありません。 これは、一般的な開発者にとっては目的がなく、ほとんどの場合、完全に無効になっている可能性があります。 開発者ツールは理由のために警告を表示します、それらは発明される必要はありません。

また、DOMソリューションが、それに対する私の以前の議論のいずれに対しても反論がゼロになり続けるのは厄介だと思います。 私のポイントを無視して問題ない場合、これは私のリポジトリではないので十分に公平ですが、同じ議論が出てくるのを見るのはがっかりします、人々はそれに反対します、人々は彼らに反対する議論が決してないのでポイントを求めているようです、それから彼らはすぐに戻ってきます。 すすぎ、繰り返します。

これがほとんどの警告に当てはまることに同意しますが、Reactの警告はコードのバグを具体的に指摘しています。 それらは単なる提案ではありません。

ダイアログは簡単に閉じることができ、個々の警告は簡単にスヌーズできます（しばらく気にしない場合）が、修正する必要があります。

比較のために、Facebookコードベースでのダイアログの外観は次のとおりです。

何千人ものエンジニアが問題を抱えておらず、そのおかげで生産性が向上しているため、これは妥当なデフォルトであると考えています。 明確にするために、オープンソースバージョンはあまり叫びません：

スタイルの微調整について提案がある場合は、 https：//github.com/facebook/react/pull/7360にコメントしてください。

ダンが言ったことに加えて、私は最近追加されたエラーロガーフローにフックするために＃7360の上に構築しています。 私は現在、少し邪魔にならないトースト通知のいくつかのスタイルを試しています。 フィードバックのために、スクリーンショットやPlnkrをすぐに投稿します。

これらの警告には、「縮小された開発コード」の警告が含まれますか？ もしそうなら、それは多くのことをかなりきちんと解決するでしょう。

なぜその目的にも使えなかったのかわかりません。

@gaearon

これがほとんどの警告に当てはまることに同意しますが、Reactの警告はコードのバグを具体的に指摘しています。 それらは単なる提案ではありません。

それらはエラーまたは例外IMOである必要があります。 なぜそうではないのですか？ 例外は修正を強制しますが、却下可能な警告は修正しません。

何千人ものエンジニアが問題を抱えておらず、そのおかげで生産性が向上しているため、これは妥当なデフォルトであると考えています。

これについては前のポイントで述べましたが、オープンソースバージョンを使用する人の90％よりも、これらのエンジニアの方が優れていると思います。 私はそれが合理的なデフォルトの反対だと思います。 開発ツールに警告があるのには理由があります。 それらを再発明することは私には意味がありません。 無効になり、二度と表示されなくなります。

これは、ReactがIMOをやりすぎているように見えます。

私が政府と契約したとき、すべてのフロントエンドが使用しなければならなかった共通のライブラリがありました。 コンソールでエラーが発生し、トーストポップアップとして表示されます。 複数のチームによって複数回本番環境にデプロイされただけでなく、多くの開発者が一度それを見て、それを永続的に無効にする方法を尋ねました。 私はこれをもっと同じように見ています。

私たちは長い間、開発中のReact警告の「警告ボックス」を有効にすることを検討してきました。 ここでデモを見ることができます（PR：＃7360）。 警告がある場合にのみ表示されますが、開発中に非常に一般的であるため（常に修正する必要があります）、アプリの開発に5分以上費やした人は、ダイアログが表示され、ダイアログが存在することに気付くでしょう。

私は＃7360、@ gaearonが本当に好きです。 新しい警告ボックスでの展開のためにPRODに切り替える必要性を強調するためのサポートを聞くのは心強いです。 それは素晴らしくて視覚的です。

ダンが言ったことに加えて、私は最近追加されたエラーロガーフローにフックするために＃7360の上に構築しています。 私は現在、少し邪魔にならないトースト通知のいくつかのスタイルを試しています。 フィードバックのために、スクリーンショットやPlnkrをすぐに投稿します。

@bvaughnあなたのイテレーションをもっと見るのを楽しみにしています:)

警告ボックスのアプローチが煩わしいと感じる人のために、他のライブラリ（VueJSなど）は、バグ修正やスローパスを促進するために、開発/反復ワークフロー中にすでにDOMオーバーレイを表示しています。

私自身の経験では、それは小さな不便ですが、これらのメッセージは、コンソールに表示されるメッセージよりも明白です。 少なくとも開発モードをprodにデプロイする必要のないものに重点を置き、エンドユーザーに「より高速なモード」を提供するサイトが増えることを期待しているのはDanの権利だと思います。

この変更後は、開発モードに気付くことが難しくなります。 「警告ダイアログを削除する方法」を検索して、本番用のビルドについて学習する可能性があります。 そうしないと、ある時点で警告が展開される可能性が高く、ユーザーに警告が表示されます。 この場合、私たちは単にボックスを不快に見せるのではなく、開発モードが想定されていることを実行するだけなので、React自体を非難することはないと思います。

それらはエラーまたは例外IMOである必要があります。 なぜそうではないのですか？ 例外は修正を強制しますが、却下可能な警告は修正しません。

それらは修正されるべきですが、私はもっと緊急の問題を抱えているかもしれません。 たとえば、私はUIのプロトタイプを作成/モックアップすることがよくありますが、その間、Reactが警告できる迅速で通常は標準以下のコードを記述します。 これらの警告を修正したいのですが、少なくとも次の1時間ですべてのコードを破棄しないことがわかるまで、私は本当に気にしません。 人々にそれらを即座に修正することを強制することは、実験開発を劇的に遅くします。

警告ボックスのアプローチが煩わしいと感じる人のために、他のライブラリ（VueJSなど）は、バグ修正やスローパスを促進するために、開発/反復ワークフロー中にすでにDOMオーバーレイを表示しています。

スクリーンショット2017-01-24at 10 57 11 am

それはVue自体からのものですか？ これは、 webpack-hot-middlewareのエラーオーバーレイで表示されるwebpackビルドエラーによく似ています。 この場合、汎用のフロントエンドフレームワークではなく、オーバーレイを追加する開発時ビルドツールであるため、微妙に異なります。

一般的に私は警告オーバーレイに賛成ですが、それが何であるか、なぜそこにあるのか、そして開発モードをオフにする一環として無効にすることができ、無効にする必要があることを説明するテキストを含める必要があると思います。 それが少し長い場合はexpandoの後ろにありますが、メッセージを伝えるのに最適な場所のようです。

オーバーレイ付きの15.2.0のようなアップデートが怖いです。 小さなバンプで、突然、小道具がDOMノードに渡されることについて文字通り何百もの警告が表示されます。 エラーかもしれませんが、減価償却の警告はそのような邪魔なスペースに属しているとは思いません

エラーかもしれませんが、減価償却の警告はそのような邪魔なスペースに属しているとは思いません

これが以前に非常に明確に伝えられていたかどうかはわかりませんが、イエローボックス警告（＃7360）に関する考え方は、すべての警告（非推奨またはその他）を表示することではありませんでした。 むしろ、チームが_特に重要_であると見なした特定の警告は、この方法で強調表示されます。 残りはおそらくコンソールに残ります。

少なくとも、それはトムと私が1、2週間前にこの機能について持っていた会話からの私の持ち帰りです。

15.2の小道具の警告も、誤ったIMOであり、通常のMOを示すものではありません。これを回避するために、マイナーバージョンで警告レベルを制御する方法が必要です。

私たちのチームが本番ビルドを使用しない主な理由は、テストutilsが含まれていないため、JSユニットテストを実行できないためです。

まず、Reactチーム（ @ sebmarkbage 、 @ gaearon 、 @ tomocchinoなど）にこの問題について話し合い、今四半期のBlinkOnやその他の同期でのパフォーマンスとモバイルについて非常にオープンに話してくれたことに感謝します。

ステータスチェック

https://github.com/facebook/react/pull/7360の@awearyによると、この特定の問題に対するイエローボックスのソリューションは、Reactの優先度の高いV16作業が完了するまで保留されていますが、まだ発生しているはずです。 https://github.com/facebook/fbjs/pull/165を着陸させ、Fiberに実装する必要があります。 フックを公開するための優れたパブリックAPIも作成する必要があります。 私の指を保ちます🤞

この問題はまだ蔓延しているようです

私の机に出くわした本番アプリのかなりの数が、まだDEVモードを本番に出荷しています。 When deploying React apps to productionデバッグ文字列は、次のビルドで確認できます。

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 ）

イエローボックスより前のボックスが、上記のコンソールへのDEVモード警告のログ記録に移行すると、何らかの影響がある可能性があると私はまだ考えています。 クラッシュレポートがこれらを検出する可能性があるようにコンソールエラーをスローするというSebastianの提案も、検討する価値があると感じました。

ここで針を動かすために他に何ができるでしょうか？

より良いアドボカシー？ DEVモードを本番環境に出荷しない人々を引き続き支持することを約束できてうれしいですが、V16以降の公式ソリューションを上陸させることができるかどうかを確認したいと思います:)

短期的には、 create-react-appは、新しいプロジェクトがこの問題を回避するのに役立つ良い場所にあるように見えます。

インストールドキュメントの改善

他のすべての人のために、 https：//facebook.github.io/react/docs/installation.htmlのサポートがありますか？ Installing Reactの見出しの下に明確で目に見える呼び出しが含まれ、人々にDEVモードに注意するように注意を促します製造？

ユーザーとして、 https： //facebook.github.io/react/docs/installation.html#development-and-production-versionsを一目見ただけで読む大きなインセンティブはないと思います。

考え？

私たちのチームが本番ビルドを使用しない主な理由は、テストutilsが含まれていないため、JSユニットテストを実行できないためです。

私はこれについて混乱しています。 本番Webサイトでテストを実行していますか？ そうでない場合、本番Webサイトで本番ビルドを使用できず、開発ビルドを開発で使用できない理由は何ですか？

他のすべての人にとって、 https：//facebook.github.io/react/docs/installation.htmlのサポートはありますか？これには、Installing Reactの見出しの下に明確で目に見える呼び出しが含まれ、本番環境でのDEVモードに注意するように人々に思い出させますか？

もちろん。 PRを送りたいですか？

もちろん。 PRを送りたいですか？

幸せ以上に。

おそらく、ベンチマークについての言葉は、パフォーマンスを開発モードで反応するものと比較する人々を教育するのに役立つでしょう？

おそらく、react devtools拡張機能を利用して、devモードでreactを使用してページを開くときに、通知や明らかな何かを表示できると思いますか？

私はこのアイデアが好きです！ devtools用に提案されたアイコンのセットをまとめました（facebook / react-devtools / pull / 652を参照）。

devとprodのReactを逆方向に、そして将来的に安全な方法で検出する方法を決定する必要がありますが、月曜日の会議の議題に追加しました。

この問題に対処するために、いくつかの合理的な手順を実行しました。

• React DevTools（〜700Kユーザー）は、開発ビルド用の特徴的な赤いアイコンを表示するようになりました。 これは、人々がバージョン間の違いを早期に知るのに役立ちます。 また、開発者が訪問したサイトでこれに気づき、作業している人々に報告するため、仲間からのプレッシャーも生じます。 いくつかの主要なサイトが、これを展開してから数日以内に問題を修正するのを見てきました。

• React DevToolsの通知は、すべての主要なバンドラーの本番ビルドを作成するための手順を公開したWebサイトにリンクしています。 また、インストールページでも目立つようにしました。

• Create React Appは、引き続き人気を博しています。 それは別々のコマンドでこの区別を早い段階で教えます。 また、ターミナルの開発モードに関する永続的な通知も表示されます。

• React 16 Beta 1 （およびそれ以降のリリース）には、ファイル名としてreact.development.jsおよびreact.production.min.jsが付属しており、縮小されていないビルドを本番環境で使用してはならないことを明確にしています。

将来的にはこの問題を解決する方法をもっと模索するかもしれないと思いますが、今のところ、もっと抜本的な対策を講じることなく前進でき、それが役立つかどうかを確かめることができると思います。 議論してくれたみんなに感謝します。