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 ，我还想提出一个单独的 console.warn 的建议。 显然，在大多数情况下renderToString是在 node 中调用的，我们无法提醒或弹出 DOM 对话框。

不幸的是，我真的希望不仅能够检测NODE_ENV是否设置为production ，而且还能够检测process.env.NODE_ENV是否已被编译出来。 有谁知道这样做的方法？

感谢@sebmarkbage的线程，我承认事后部署的困难。 我也很欣赏当前的警告。 似乎一些开发人员可能不会尽可能频繁地检查其部署站点的控制台输出。 然而，这是一个很好的第一步。

只要我们能找到类似的启发式方法来通知用户，甚至可能更积极地弹出一个 DOM 对话框，我们就应该这样做。

对于用于通知用户的启发式方法的改进，我将不胜感激。 更具侵略性的 DOM 对话框将大有帮助。 这将确保该网站继续为最终用户服务，但提供了一个积极的暗示，即开发人员可以选择低挂的性能水果。

另一种方法是，我们找到了一种在构建工具/ENV 级别解决此问题的方法，如原始帖子中所述。 这将避免任何必要的 DOM 注入。

将任何消息注入 DOM 似乎很危险，而且有点过于假设了。 这为最终用户提供了意外和令人困惑的警报的可能性，这似乎是 IMO 不可接受的。

@thelarkinn提议我们尝试标准化所需的 ENV 配置，以更好地促进对此类消息的检测

这感觉像是解决这个问题的理想空间。 这是一个构建问题，如果可能，应该由构建工具解决。

轶事：过去，控制台中的警告已经消失（或忽略）。 我这里没有确切的数字，但我认为基于控制台的警告是不够的。 我同意@addyosmani的观点，即基于 DOM 的警告会大有帮助。

@surma也许他们应该使用console.warn或console.error以获得更好的可见性😉

我看不出在任何情况下，仅当应用程序在生产中运行时才将内容注入应用程序是可以接受的。 你做了一个巨大的假设，即在应用程序被推送给实际用户之前，该消息会被捕获，而该消息可能会在很大程度上损害用户体验。

顺便说一句，我们将在 Fiber 中添加更全面的错误处理支持，以便您可以使用自定义错误视图替换出现故障（抛出错误）的组件。 即使在默认情况下，我们也可能会非常激进，如果该组件出错，只需从树中删除该组件，因此无论如何您确实希望为您的用户提供自定义错误 UI。

我们可能会针对此警告触发此类错误。

老实说，我认为console.{error,warn}超过console.log不会改变任何东西。 正如我所说，这个故事是轶事。

我也不是说显示 DOM 对话框是_the_ 解决方案。 不过，我个人会对此感到满意。 如果保持在开发模式有负面影响，至少用户会知道_something_是错误的，并且可能会开始点击“帮助”按钮或其他东西。

底线：我认为框架需要在某些时候出现在开发人员面前。 我很想对此进行集思广益，看看框架作者愿意采取哪些步骤和妥协来防止人们在未来以开发模式进行部署。

如果 React 根本不工作，除非你提供一个环境，不管它是开发还是生产？ 这样，就有一种有意识的选择。

关于在 DOM 中注入的消息，可以使用全局或其他东西将其禁用。 没什么大不了的。 如果你禁用它，你就会承认你知道你在做什么。

控制台消息的问题是有时人们会记录很多事情，或者他们忽略了其他警告，并且很容易看不到滚动后的第一条控制台消息......

使用强制环境，不可避免的样板等会设置环境变量，所以你可以开始使用它，恐怕：/

老实说，我不认为 console.{error,warn} over console.log 会改变任何东西。

您认为这是开发人员不检查控制台的问题，还是控制台出现警告超载的问题？ 这可以（部分）通过更通用的开发人员教育方法来解决吗？

我也不是说显示 DOM 对话框是解决方案。 不过，我个人会对此感到满意。 如果停留在开发模式有负面影响，至少用户会知道出了点问题，可能会开始点击“帮助”按钮或其他东西。

我明白这一点，但我只是说我不认为它是一个解决方案，更不用说解决方案了。 您对此感到满意很好，但我认为最好谨慎行事，并假设大多数人不希望向用户显示意外错误。

底线：我认为框架需要在某些时候出现在开发人员面前。 我很想对此进行集思广益，看看框架作者愿意采取哪些步骤和妥协来防止人们在未来以开发模式进行部署。

我是💯，因为我在开发人员的脸上，但在正确的地方做这件事很重要。 对我来说，这是构建步骤，而不是生产。

关于在 DOM 中注入的消息，可以使用全局或其他东西将其禁用。 没什么大不了的。 如果你禁用它，你就会承认你知道你在做什么。

默认启用它与不使其可配置一样糟糕：默认行为可能会导致最终用户出现意外行为。 如果有的话，默认情况下应该禁用它，但这会破坏整个目的，因为开发人员一旦意识到它就可以修复最初的问题。

控制台消息的问题是有时人们会记录很多事情，或者他们忽略了其他警告，并且很容易看不到滚动后的第一条控制台消息......

我完全明白，控制台会变得拥挤，很容易错过东西。 但正是因为我争论的确切原因，它很拥挤：它是为开发人员提供反馈或错误的地方。 它不影响用户体验，而注入的消息则不然。

有道理，我明白其中的道理。

好吧，也许使用控制台格式弹出这个东西至少会是一些东西。

问题是几乎没有人在生产中查看控制台。 你可以在那里使用任何字体，人们不会注意到它。

但是，如果我们让它在生产中默认显示一条消息作为重大更改（在 16 或 17 中），那么将很难错过。 我的意思是，它会在您第一次尝试部署它时发生（对于新用户），并且现有用户在更新到新专业时应该阅读发行说明。 所以我认为这是可行的，只要我们对此非常明确并且不可能错过信息。

问题是几乎没有人在生产中查看控制台。 你可以在那里使用任何字体，人们不会注意到它。

我只能评论 Chrome 团队在这方面的经验，但我同意。 大多数人会在他们的迭代工作流程中注意到控制台消息，但是查看生产站点上的警告的百分比要小得多，并且很少对它们采取行动。

但是，如果我们让它在生产中默认显示一条消息作为重大更改（在 16 或 17 中），那么就很难错过。 我的意思是，它会在您第一次尝试部署它时发生（对于新用户），并且现有用户在更新到新专业时应该阅读发行说明。 所以我认为这是可行的，只要我们对此非常明确并且不可能错过信息。

感谢您对@gaearon 这样的变化持开放态度。 在未来的版本中默认尝试一条消息需要什么？ 😄

我同意控制台警告不是解决方案，页面可见警告要好得多。

页面可见警告可以：

• 提醒开发人员该站点处于开发模式
• 链接到有关好处的文档，以及如何在没有它的情况下发货
• 禁用消息的链接...我不知道 2 小时？

禁用消息很重要，因为它可能会干扰/覆盖页面上的某些内容。 由于此设置将存储在本地存储中，因此警告仍将出现在实时服务器上，因为它是不同的来源。

是的，如果真正的用户在实时网站上看到这条消息，那就太可怕了，但感觉就像是鼓励开发者解决这类问题，而有些人似乎乐于忍受开发模式的性能问题。

如果我第一次看到该警告（插入到 DOM 中）是在生产中，我会相当沮丧。 警告需要提前发生。

@rtorr我的建议是，只要网站处于开发模式，它就会发生，所以除非我遗漏了什么，否则应该提前看到它？

@jakearchibald很抱歉造成混乱，我的回复不是针对您的。 我只是想指出线程，如果我们要使用“插入到 dom”解决方案，我们应该非常小心并确保用户在推送之前知道（有些方法，我在这里没有好主意） .

我只是看到一些开发人员忘记了设置或其他东西，并且管理人员都吓坏了。 对于在生产中使用开发模式的后果，这种可能性是否值得？

我必须不断禁用基于 DOM 的警告是不行的，它必须可以永远禁用它，也许它根本不应该显示在本地主机上。

如果有可能在浏览器中有某种​​标志，您必须启用该标志来激活开发工具（可能在其中有一个很大的覆盖，“你是开发人员吗？[是/否]” ) 页面可以检测到并且只向开发人员显示警告。 措辞正确，它也可能有助于自我 XXS 攻击。

我必须经常禁用的基于 DOM 的警告是不行的，必须可以永远禁用它

使用开发模式启动的站点也不行。 也许该消息每天只需要关闭一次？ 但是时间越长，它就越有可能最终上线。 如果它可以永远禁用，我们就回到了我们开始的地方。

我也不认为生产中的意外 dom 节点是可以的。

我认为无论哪种方式，我们都会遇到极端情况。 如果这个问题一直发生，那么可能开发模式的交付是错误的。 虽然在完美世界中并不理想，但如果我们发现 prod 模式对我们愿意修改某人的应用程序很重要，那么它可能应该是默认的，并且应该选择加入 dev 模式。

@rtorr

我也不认为生产中的意外 dom 节点是可以的。

为什么？ （我不是说你错了，只是想听听你的理由）

也许添加一个设置来定义产品域。 如果没有设置 prod 域，那么我们总是会收到有关 DEV 模式的警告（请求设置域 URL），如果设置了，那么我们只会在 URL 与 prod 域匹配时收到警告。 我们甚至可以绑定任何我们想要通知开发者的服务

我很高兴这里有建设性的讨论。 这里有两个解决方案，我可以看到解决问题。 Webpack 可以强制指定 NODE_ENV，然后 React 可以使用它来更容易地避免人们将 DEV 运送到 PROD，但这将是对 Webpack 的重大更改。 我现在正在和 Sean 讨论这样的事情对于 Webpack 3 的可行性。保持 React + Webpack 堆栈初学者和性能友好是我知道两个阵营都关心的事情。

第二个（DOM 注入想法）是 React 可以做的事情，正如 Jake 提到的，通过允许消息每天显示一次或被忽略来平衡用户体验。 解决问题只需进行一行更改，然后您只需重新部署即可。 我完全同情不希望管理层吓坏了。

如果我们要让更多的 React 网站发布更快的体验 FB 努力推动一些东西可能不得不提供。 如果有人有更好的想法，请提出建议。

@jakearchibald

为什么？ （我不是说你错了，只是想听听你的理由）

回到我上面的评论，除非我们能够提前让开发人员知道（这似乎是要解决的实际问题），否则我发现通过在他们的生产页面上向开发人员显示警告来贬低某人的产品是一种极端的做法。 在很多情况下，这可能对产品造成的伤害比开发模式的性能更大。

无论我们做什么，都会有人将默认的东西运送到生产中，为什么不让生产默认呢？ 为什么不将开发模式改进到影响不大的程度呢？

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

@jakearchibald是的，我看到双方都有问题。 我相信这个帖子中的人们会想出一些好的东西，即使这是你所提议的。 你们都很棒，仅供参考。 也许极端就是答案。

如果用户正在运行 React 开发工具，那么您是否可以不插入 DOM 节点警告以使普通用户无法体验它？

@jakearchibald

使用开发模式启动的站点也不行。 也许该消息每天只需要关闭一次？ 但是时间越长，它就越有可能最终上线。 如果它可以永远禁用，我们就回到了我们开始的地方。

当网站启动时，有人决定它已经“准备好”，所以虽然它很糟糕，但它不是一场灾难。 但是有（可能，我不知道确切的数字）成千上万的开发人员不得不解雇一个站点破坏（必须将 DOM 警告视为那样，因为您不知道它如何与站点的其余部分交互如果该站点在警告可见的情况下可用），每天警告五次甚至一次警告是一场灾难。 大多数开发人员都有一个正确设置的构建链（自定义、create-react-app 或其他），并且根本不需要该警告，他们需要能够摆脱它。

@dan-gamble 我相信不使用 React 开发工具的开发人员是这个警告最紧迫的目标。

@Pajn可能，我不认为仅仅因为您下载了 Chrome 扩展程序，它就会自动让您意识到 prod / dev 切换

@dan-gamble 不，当然不是。 但是有些人在没有它的情况下开发了一个完整的应用程序，我认为这表明他们不经常使用开发工具，因此不太可能看到当前针对缩小代码的警告。

当我觉得这一点已经提出时，我通常不会添加这么长的讨论，但我必须同意并想强调这一点：React touch touch DOM 并警告我我正在使用开发版本会是一个很大的错误。 据我所知，在任何其他框架中都没有先例。

想象一下所有的教程，所有的游乐场，所有使用开发模式教授 React 的小项目。 我拼凑起来的每一个小测试站点都是为了探索 React 中的一些有趣的东西，或者尝试隔离一个测试用例。 如果 React 在我必须手动禁用的每个站点上都发出警告，我会非常生气。 感觉就像一个霸道的父母，并积极地劝阻你使用 React ，因为每当你尝试做一些新的事情时，它都会给你耳光。

甚至每2小时做一次？ 不，谢谢。 像这样不断的唠叨肯定会阻止用户使用 React 进行开发，老实说，我认为它会促使人们采用其他框架。 也许这就是 Chrome 开发者想要的？

更不用说这样一个事实，是的，这会以某种方式进入生产，并且已经很难说服某些团队采用 React，而这只是他们反对它的更多弹药。

我最喜欢 React 的一点是，在你调用ReactDOM.render(...)之前它什么都不做，当你这样做时，它只会将东西放入你告诉它的 DOM 中。 这就是为什么它是一个如此好的、孤立的、功能性的库。

我们是否还需要检测人们是否运送了未缩小的捆绑包？ 如果他们在应该缓存的时候没有缓存怎么办？ 当他们没有最佳配置 nginx 时怎么办？ 或者不应该使用shouldComponentUpdate ？ 还是在不需要时渲染所有内容？

性能不佳有几个原因，仅仅将其归咎于 React 的开发模式是错误的。 当您部署一个站点时，您完全期望您了解如何部署一个优化的站点。 我并不是说我们无能为力，但这个问题的核心原因是基准作者没有尽职尽责，我们不应该为此付出代价。 我们需要找到另一种方法来解决这个问题。

我打算跟进我认为正确的解决方案：将这些限制放在工具中。 确保 webpack 或您用来构建站点以进行生产的任何工具是我们应该强制进行这些检查的地方，并且我对我们希望在构建过程中放置​​的任何类型的限制感到失望。

关于 webpack 强制一个 NODE_ENV 设置（也许在他们的 repo 中已经存在这个问题），这不会让使用不依赖于 env 设置的库变得更加困难吗？

或者它会检测 NODE_ENV 使用并仅在代码使用它时强制它的想法？

让我们不要太拘泥于“2 小时”的事情。 只要它有效，它可以是任何时间段。

此外，本地存储事件意味着每个来源只需要解除一次。 如果您在一页上有多个演示，则关闭其中一个会关闭其他演示。

如果警告确实进入现场，它的响亮足以保证快速修复 - 一个有利于用户的。 如果我们担心 React 在公共场合的表现，我们真的想避免像这样不必要的减速。

当然，这不会检测到错误的缓存头等，这只是关于检测“开发模式”。 “滑坡”论点也无济于事。

我不认为将问题转移到构建工具是有用的，因为如果开发人员使用不同的构建工具，或者未能将其投入生产模式，您将遇到同样的问题。 开发模式框架已经产生控制台警告，这显然是行不通的。

这不仅仅是关于基准测试，而是关于真实网站，对于真实用户来说运行缓慢，因为没有切换开关。

@jakearchibald感谢您对我情绪激动的人的理性回应。 我确实认为，一个网站使用 React 可能会变慢的原因有很多。 我希望看到一种我们可以建议性能改进的方法，它比对开发模式的粗略检查和浏览器内警告更好。 如果我们有工具来分析 React 应用程序并为性能提供严肃的建议，从开发模式到过多的重新渲染，这将更加有用。 像这样的通用工具可以连接到任何管道中，无论是 webpack、browserify 等。

这是我想说的主要内容：有些日子我将在 5-10 个不同的地方使用 React 开发模式，例如 jsbin、教程，甚至拼凑一个小型测试站点并使用 file:// 协议打开它。 强制浏览器内警告对这种 Web 擅长的灵活开发是不利的。 我会到处看到这些警告，因为我正在网络上跨域学习 React。

如果警告确实进入现场，它的响亮足以保证快速修复 - 一个有利于用户的。 如果我们担心 React 在公共场合的表现，我们真的希望避免像这样不必要的减速。

即使允许向最终用户显示特定于开发人员的警告的可能性对我来说似乎也是不可接受的。 网站速度慢是一回事，但这样的消息可能会破坏用户的信任，尤其是对于以安全为重点的网站（如果您的银行网站突然显示神秘错误，您会高兴吗？）谷歌会接受他们所有的用户突然收到此警告，即使只是片刻？

此外，本地存储事件意味着每个来源只需要解除一次。 如果您在一页上有多个演示，则关闭一个会关闭其他演示。

您不能依靠localStorage来重复数据删除。 无法保证localStorage （或任何其他本地持久数据）不会在任何时间间隔内被清除。

编辑：此外，通过每{INTERVAL}只显示一次错误，您现在使重现和调试变得更加困难，因为它不是确定性可重现的。

有2种情况需要解决：

• 防止错误的基准测试、性能测试：通过大型控制台消息轻松解决。
• 防止将 DEV 运送到生产站点：人们不会在 prod 中打开 devtools。

反对接触 DOM 的论点是有说服力的。

如果有一个大的、华丽的、明显的控制台警告，很可能在交付生产之前人们会使用开发版本并看到这个非常明显的控制台消息。 或者也许一些代码已经交付到生产环境，但是对于另一个项目，他们将使用下一个反应版本，这个不可能错过控制台消息。 也许他们会记住他们交付生产的站点并检查那里是否启用了 DEV。

控制台消息将具有教育意义，例如，任何从事 React 开发的人都知道 DEV 有一些非常重要的东西，并且每次使用 React 进行开发时都会看到它。

我对https://github.com/facebook/react/pull/8782犹豫不决，因为人们通常不喜欢他们无法摆脱的警告（请参阅 https://github.com/facebook/react/issues/ 3877），但考虑到替代方案，它可能是一个可接受的解决方案。

好奇的。 localStorage 的使用会在其未涵盖的网站上调用欧盟 cookie 法吗？

如果开发期间的信息警告是个好主意，那么为什么其他库不这样做呢？ 嗯，一个原因是这样的问题。 如果其他人想这样做，他们是否也应该弹出类似的 UI？ 您必须关闭所有这些吗？

在我看来，最好有更核心的东西来处理这个问题。

也许 Chrome 可以有一个开发模式？ 图书馆可以告诉主机他们处于开发模式，然后 Chrome 可以添加一个徽章或弹出来表明这一点。

让我觉得在开发模式下使用 react 打开页面时，可以利用 react devtools 扩展来显示通知或明显的东西？

@sebmarkbage

如果开发期间的信息警告是个好主意，那么为什么其他库不这样做呢？

我想有人需要成为第一个。 Angular 也有类似的问题，像http://code.gov这样的东西在开发模式下启动。 如果 React 开始在其他框架没有的地方捕捉到这些东西，我会推动他们做出类似的改变。

我会推动他们做出类似的改变。

@jakearchibald您是否建议每个框架都应提供自己的警告？ 我不认为为在生产中提供自己的开发警告的框架/库设置标准是一个好主意。 我们不应该尝试在平台上标准化吗？ 正如@sebmarkbage 所述

也许 Chrome 可以有一个开发模式？ 图书馆可以告诉主机他们处于开发模式，然后 Chrome 可以添加一个徽章或弹出来表明这一点。

我认为这是一个很棒的点子。 先例：Safari 有一个单独的模式，您必须启用它才能访问 DevTools。 如果 Chrome 也这样做，那么它还可以安全地为 DEV 模式添加一个指示器和一个 API 来触发它。 该指标仅对开发人员可见，因此不会破坏用户体验。

等待浏览器供应商实施这样的事情不是需要时间吗？

@jide是的，但正确解决这个问题比快速解决更重要。 此外，在考虑标准化工作（如有必要）之前，它可以在单个浏览器中实现。

@骀

您是否建议每个框架都应提供自己的警告？

鉴于每个框架都提供了自己的开发模式（并且框架之间的模式可能非常不同），框架应该以类似独特的方式实现警告似乎是完全公平的。

浏览器已经竭尽全力避免将开发工具暴露给页面。 如果我们让 devtools 成为进入这里的障碍，我们将错过很多 DOM 警告不会错过的用户。 DOM 警告似乎不仅更简单，它对平台的依赖更少，而且会影响到更多的开发人员。 更简单、更有效听起来像是一场胜利。

@gaearon在 Chrome DevTools 方面，我们一直在集思广益一个实时的“违规 API”，Web 平台和框架作者可以使用它来发出重要警告。 这些将在即将到来的审核面板刷新之类的地方呈现。 这听起来与您的要求相似，可用于触发 DEV 模式检测警告。

对于这个特定的问题，您可能会追求比我们最初计划的更响亮的东西。 违规面板，类似于控制台日志消息，要求您知道面板将提供洞察力。 也许还有额外的 UX 空间来显示一个非常明显的页面覆盖在页面下方，框架可以对其进行标准化消息传递。 在假期周末后循环访问@paulirish和@s3ththompson以了解他们的想法。

Fwiw，我猜这个 API 还要几个月才能准备好。 如果是这样，它最初只会在 Canary 中可用，然后在 6-7 周后它可能会变得稳定。

DOM 警告似乎不仅更简单，而且更有效。

在这一点上，我同意杰克的看法。 让我们继续讨论 DevTools 解决方案，但我也想弄清楚 React 可能会做些什么作为备用，以防 API 最终无法满足您的需求或在时间轴上更远。

鉴于每个框架都提供了自己的开发模式（并且框架之间的模式可能非常不同），框架应该以类似独特的方式实现警告似乎是完全公平的。

@jakearchibald ，您意识到设置该标准意味着使用多个框架（或套件中遵循的库）的页面可能会导致向最终用户显示任意数量的非确定性呈现的神秘警告？

浏览器已经竭尽全力避免将开发工具暴露给页面。

而且我确信原因至少部分是因为开发人员特定的消息不应该暴露给最终用户。

DOM 警告似乎不仅更简单，而且更有效。

没有人反对解决方案的简单性或有效性。 它会起作用，但会以牺牲用户体验为代价。 速度并不是唯一会对用户产生负面影响的因素。

Fwiw，我猜这个 API 还要几个月才能准备好。 如果是这样，它最初只会在 Canary 中可用，然后在 6-7 周后它可能会变得稳定。

@addyosmani如果它是一个更好的解决方案，我不明白这将是一个问题。 对 React 的任何更改都将在一个主要版本中，我认为就发布时间而言，这是待定的。

决定的解决方案可能会影响所有未来的发展。 在这种情况下，几周而不是几个月是可以接受的 IMO。

我知道如果框架向他们的 DOM 中注入了他们自己没有放入的东西，一些开发人员会感到被入侵。 但我觉得页面底部的横幅显示“此站点处于开发模式”将是一个很好的解决方案，不会对用户体验产生太大影响。 我想了解为什么很多人的想法相反。

@aweary ：如果“以安全为中心”的网站曾经在 DevMode 下启动，那么在解决问题之前不应信任它们。 “DevMode”可能包括各种与安全相关的快捷方式，例如禁用 CORS 检查或暴露的模板源代码等。如果网站以安全为重点，则_不能_发生这种情况。

（我意识到“DevMode”在 React 中具有非常特殊的含义，但我在这里试图假设一个非开发人员的观点）

@骀

您是否意识到设置该标准意味着使用多个框架的页面可能会导致向最终用户显示任意数量的非确定性呈现的神秘警告？

我绝对意识到这一点。 在开发模式下具有多个框架的页面将无缘无故地严重损害用户体验。 看来你宁愿它不被注意和不固定。 我宁愿它对非开发人员（针对开发人员的可见消息）如此糟糕，开发人员及时修复它，创造更好的用户体验。

速度并不是唯一会对用户产生负面影响的因素。

我没有看到有人声称不是吗？ 我对这种反应感到非常难过😞

看来你宁愿它不被注意和不固定

@jakearchibald这是一个奇怪的结论，如果我不想解决这个问题，我想我不会花空闲时间在这里和你交谈吗？ 仅仅因为我不同意你的解决方案并不意味着我愿意让它悬而未决。 这真的很不公平。

我宁愿它对非开发人员（针对开发人员的可见消息）如此糟糕，开发人员及时修复它，创造更好的用户体验。

这就是我认为根本不可接受的：你首先明确地惩罚用户。

如果一个“以安全为中心”的站点曾经在 DevMode 下启动，那么在解决问题之前不应信任它们。

@surma开发模式本身并不是不安全的，但不管它是否越界假设您可以将其传达给用户。

我认为需要打开或启用开发工具的解决方案是不够的。 为了引起注意，它需要对 QA、管理层和可能的最终用户可见。 开发人员将习惯于看到这一点。 类似于如何突出显示有问题的 ssl 配置。 它不需要太多，但足以引起注意，有人会询问它然后修复它。

由于许多原因，注入 DOM 是有问题的。 这对 React 来说更可行，因为我们是一个 DOM 库并且有 DOM 入口点。 对于不是特定于 DOM 并且可能在工作人员中运行的库来说，这更难。

我们可以做的一件事是更改网站图标，只要我们提供一种明确覆盖它的方法。 许多网站已经为开发模式提供了单独的网站图标。

我们需要找出在 React 中处理错误的默认体验，这可能无法保持 DOM 就位。 如果抛出错误，master 中的当前默认实现会从树中删除 React 内容。 这也是侵入性的。

如果我们有办法检测到您未处于开发模式，我们可以触发该错误模式。 我们真的需要一种可靠的方法来永久选择开发模式。

类似于如何突出显示有问题的 ssl 配置。

这正是我认为完美的事情。 用户已经习惯了浏览器提供有关他们访问的站点的安全信息，性能信息从那里并没有很大的飞跃。 此外，它对于报告潜在性能问题并且不会直接干扰用户工作流程的所有框架/库都是一致的。 👍

我喜欢网站图标的想法：引人注目，无需开发工具或扩展即可工作，每个人都注意到，不会对用户造成伤害，可以动画来吸引注意力，烦人到让开发人员想要消失。

选择加入 DEV 模式怎么样？
我们在“良好的用户体验”方面犯了错误，因为糟糕的 DX 更容易被注意到（恕我直言，对于此类问题，用户应该“获胜”，因为他们无法选择，而开发人员可以）。
我确信一些框架已经这样做了（如果我没记错的话，比如 Relay）。

关于如何实施的建议：

• 仅当NODE_ENV明确设置为development时才启用开发模式
• 如果全局__DEV__为=== true ，则启用开发模式
• 导出要在用户空间中启用的调试工具模块

第一个似乎是最好的，因为其他两个可能在没有保护的情况下进行硬编码（例如if(NODE_ENV === 'development')语句），因此无论如何都会被运送到生产环境。

@mattecapu请参阅我的第二条评论。 https://twitter.com/sebmarkbage/status/820047144677584896

如果有类似的方法来强制开发人员从在 DEV 模式下运行开始，那么默认值是什么并不重要。 但如果你落后了，那就太糟糕了。

这里有很多要评论的地方，我也有想法，但我想特别谈谈如何禁用开发警告的问题。

我不喜欢在特定浏览器中禁用 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在您的本地计算机上使用开发构建：永远没有开发人员警告，也不需要开发人员操作。
• 在使用另一个主机名的开发机器上使用 dev 构建：您会收到 DOM 警告，直到您将域名添加到传递给render的列表中。 此后，您永远不会收到 DOM 警告。
• 在 prod 机器上使用 dev 构建：在将 React 切换到 prod 版本之前，您会收到 DOM 警告。

这个解决方案让我担心的一件事是，它可能会导致开发人员在代码中留下所有开发服务器域的列表，并且该代码可能会投入生产。 对于那些认为他们的开发服务器域是秘密的公司来说，这将是一个问题。 想法？

@aickin这种方法的问题在于它要求用户了解配置，进而了解它正在解决的问题。 问题是人们一开始并没有意识到开发/产品的区别。

编辑：没关系，我明白了，开发中仍然存在 DOM 警告。

服务器端环境通过显示包含调试详细信息的“特殊”错误页面来解决此问题，并告诉您不要在生产中提供它。

由于我们计划让 React “快速失败”并卸载视图，除非您提供自定义错误边界，我们不妨在开发中添加一个默认的“红框”错误边界，作为教育页面。

然后，用户第一次在生产中遇到错误时，他们会看到一条特殊的详细错误消息。 这可能是一个了解 DEV 构建的机会。

但我觉得页面底部的横幅显示“此站点处于开发模式”将是一个很好的解决方案，不会对用户体验产生太大影响。 我想了解为什么很多人的想法相反。

大多数用户如果知道它是 Web 应用程序，就会不喜欢 Web 应用程序，为什么？ 因为以前网络的一种普遍心态是，当它出现在屏幕上时，它就完成了，无论它表现得多么糟糕，并且用户已经知道网络是糟糕的。 然而，在 Web 上创建出色的 UX 是完全可能的，但要做到这一点，我必须拥有 DOM。 如果有人在任意位置注入随机横幅，则错误的元素可能会开始滚动，或者可能导致整个屏幕在滚动时重新绘制，或者可能会干扰例如拖动手势或其他操作。 关键是，只要那面旗帜升起，我就无法发展，因为我不知道当那面旗帜消失时，体验是一样的。

作为一个框架解决方案，我真的很喜欢 favicon 的想法，它不妨碍开发，它对用户来说并不陌生，它不可能破坏 UX，但它会引起注意。 但是，它实际上只适用于当时的单个库或框架，并且对于在 worker 中运行的库根本不起作用。 真正的解决方案是通过可以支持多个框架和库并且可以从所有上下文访问的浏览器来做到这一点的好方法。

另一个支持多个框架和库并且更清晰但确实需要权限请求的解决方案是显示浏览器通知。

这是一个想法：更新 react 主页上的入门文档，以更重地推动创建 react 应用程序。 并在这些文档中强调 npm build 的重要性。 我们不需要 DOM 警告，我们需要意识。

我认为@ropilz在线程的早些时候用他的“_..我们甚至可以绑定任何我们想要通知开发者的服务.._”评论谈到了这一点，但它可能没有被注意到（或未被承认）。

据我了解，这里要解决的根本问题是

• 当生产_最终用户_体验在开发模式下运行的站点时以某种方式提醒_开发人员_
• 我们不能依赖开发人员在生产中看到console.log消息（甚至是 DOM 警告），_除非_这些开发人员自己积极使用生产站点（或者我们依赖最终用户，QA/支持团队等将这些警告报告给开发人员）
• 有（有效的）UX 参数_反对_向最终用户显示针对开发人员受众的 DOM 可见警告。

如果有类似于 CSP 的report-uri的东西，让框架向其发送开发模式警告，而不是在最终用户可以看到的站点上就地显示警告，该怎么办？

显然，有很多事情需要考虑，例如：

1. 理想情况下，此类报告默认为 ON，但默认report-uri是什么？ （我们是否希望每个框架都托管自己的免费服务，类似于https://report-uri.io？ （这_可能_对于大型的、公司赞助的框架，如 React 和 Angular；但对于较小的开源框架肯定不切实际如 Preact、Vue 等）
2. 报告警告后，如何通知网站所有者/开发者？ （也许是非开发人员参与项目的好方法，自愿监控这些报告并帮助追踪/通知维护者？）

我完全承认这个建议只是一个想法，我还没有考虑过它的实用性或实际效果。 但我想提出它，因为在我看来，“报告生产问题”的挑战已经部分解决了 CSP/HPKP 报告，也许我们可以在这里探索类似的东西？

退后一步并意识到 React 是一个框架是很重要的。 您不得：

• 修改 DOM 以直观地呈现某些内容，以提醒开发人员。 除非您了解并开发出可以在所有环境中工作的东西，否则这不可能开箱即用，而不会妨碍开发人员并在生产中突然出现时失去用户的信任（如果我的经验表明这会发生）非常频繁，许多人将无法部署快速修复来关闭它）。

• 修改网站图标。 favicon 令人讨厌地被缓存，用于书签，如果未指定其他图标，则在移动设备上保存 Web 应用程序图标等。这会冒着意外（或故意）将生产部署到开发模式的风险，从而擦除品牌徽标。

• 浏览器通知。 当您被注视时，您很可能正在被用户注视。 弹出通知是要请求浏览器权限，弹出用户看不懂的奇怪东西。 以我的经验，这些将主要被开发人员看到的假设是完全相反的，并且可能会破坏用户的信任。

照顾开发人员不是 React 的工作。 我建议：

1. 启用开发模式。当开发人员意识到他们无法调试某些东西时，他们会查找如何打开它（这需要到处记录）。 不，告诉他们关闭它不是 React 的工作。 他们的问题。

2. 把它留给一个简单的 console.log 消息（这必须是可禁用的）。 让开发者找到并处理。 如果他们不这样做，哦，好吧。 您无法深入到每个组织并让他们正确地做事。 它只是不可扩展。

我不得不不同意触摸 DOM 来显示警告。 React 看起来很简单，因为它是一个 DOM 库，但想象一下，如果所有库都必须在 DOM 中显示它们自己的警告。 这将是一团糟。

开发人员使用的很多库可能都有自己的开发模式。 我认为将process.env.NODE_ENV设置为production已经是捆绑浏览器模块的通用标准。 这是我们需要提高的认识。

我同意 React 文档并没有显着地表明开发和生产构建之间存在差异。 当您打开文档时，您必须通过高级指南来阅读开发和生产构建之间的区别。 标题是Optimizing Performance ，初学者肯定不会看，因为他们使用 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.

我以前从未使用过 Angular 2（在这种情况下我是初学者）。 看到警告后，我的最初反应是尝试调用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 或登台系统看到这一点，因为它并不表示生产。

所以你最终会得到一堆垃圾代码来禁用这个与网站的用户体验有关的东西。 在开发过程中禁用它的原始工程师也不一定会记得。 他们甚至可能在它投入生产之前就已经继续前进了。

我不确定在 code.gov 上的部署过程是如何工作的，但如果它与我作为政府承包商所经历的一样，而不是意外的开发模式部署到生产中，要么：

1. 强制全面回滚整个部署（其中一些需要 6 个月的时间才能获得批准并捆绑从 UI 更改到服务器软件更新的所有内容），可能在第二天，然后您会召开会议并就所发生的事情进行后续文书工作安排一个新的部署窗口（你会被一遍又一遍地询问数据库脚本或服务或其他任何东西是否都处于开发模式，因为 UI 中有一个警告）。 我已经看到这种情况发生在非常小的事情上。 有时你会得到例外，但 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

我不认为说文档不坦率地说是不公平的。

当您打开文档时，您必须通过高级指南来阅读开发和生产构建之间的区别。 标题是优化性能，初学者肯定不会看的，因为他们使用 React，因为他们听说它很快。 我认为文档可以改进为在快速入门部分中有另一个名为“在生产中使用 React”或类似的文档。

它就在第一页（安装）上：

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

你说得对。 对不起这是我的错。 我假设生产版本位于不同的部分，所以我没有看那里，而是在侧边栏中搜索相关标题（并找到了优化性能页面）。 我应该知道的更好。

我并不是真正的 React 初学者，这就是为什么当我打开文档以验证我的假设时 - React 文档不是关于 prod 与 dev 的前期 - 我没有打开安装文档🙇

不用担心。 如果它不够明显，我愿意接受更好放置的建议。 例如，我们可以为它创建一个专用页面（ Deploying to Production ）。

我们不要忘记，这个问题是一个需要解决的重要问题，但不是最需要强调的问题。 我也不相信即使在首页突出显示它就足够了，因为人们会看到它并浏览它，忘记它，并认为“我知道我在做什么”。 所以我不会过度关注文档的事情。

解决它的唯一真正方法是检测和通知。

@KrisSiegel被缓存的图标是一个好点。 我想知道我们是否应该在一两秒后切换它，然后每隔几秒钟将其短暂翻转一次。 这样，缓存和书签问题不太可能在覆盖图标时对其进行计时。

我认为对 favicon 的 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 和 co 可能会很痛苦。

构建打算作为 React 的生产包但没有启用生产模式的东西就是这样 - 一个构建错误。

使用来自 CDN 的预打包版本的 React也是受支持的配置，但在该工作流程中根本没有构建步骤。 因此，仅关注构建的此问题的解决方案将忽略 CDN 用例。

老实说，我不确定我对此有何感受。 我可以看到支持和反对使用 React CDN 的开发警告的论点。

@taion作为支持仅构建解决方案的人，您认为这是一个需要涵盖的重要用例吗？

其他人怎么看？

我认为那里的文档很清楚你应该使用.min.js包进行生产。 也许它可以使用粗体，更大的字体大小，类似的东西。 但是如果有人在他们的网站的生产环境中使用未缩小的 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-redesign-web-debug-toolbar

尽管据我所知，我不认为这是默认情况下启用的。

按照上面的讨论，似乎有一个总体目标是实现一个完美的解决方案，该解决方案满足所有约束，但在不应该的情况下可靠地阻止每个人在开发模式下运行。 OP 表示需要在开发人员和用户的潜在体验之间进行权衡，我认为情况非常如此。

尝试重新陈述问题：

• 非零数量的 React 站点在不禁用开发模式的情况下投入生产
• 我们想减少这个数字
• 我们不想惹恼 React 开发者
• 我们不想让 React 的新手望而却步
• 我们不希望使用 React 构建的网站的最终用户看到神秘的开发人员警告
• 我们不想因为存在外来 DOM 元素而破坏网站

鉴于这些，我认为一个不错的第一步是让 React 在开发模式下通过console.warn或console.info来宣布它处于开发模式，并带有说明以确保在生产中禁用它部署。

当然，这不会吸引所有人，但 _这是一个不错的开始_ 这应该会减少无意中运送到生产环境的人数，并且不会关闭任何未来改进的大门。

鉴于这些，我认为一个不错的第一步是让 React 在开发模式下通过 console.warn 或 console.info 宣布它处于开发模式，并提供说明以确保在生产部署中禁用它。

尽管当您正在开发时，它处于开发模式并没有错。 我们还可以使用哪些其他启发式方法？

此外，鉴于没有人在生产环境中读取控制台，我想知道我们是否可以设置超时，以便在您使用崩溃报告解决方案时记录下来。

尽管当您正在开发时，它处于开发模式并没有错。 我们还可以使用哪些其他启发式方法？

我觉得应该和现在的 React DevTools 通知差不多

一条信息性消息，提醒您处于开发模式，并且应该为生产站点禁用开发模式。 这（理论上）应该让更多的开发人员意识到存在区别，并且需要采取一些措施来为生产使用做准备。

就像你说的，几乎没有人会在实际生产中看到控制台警告——到那时已经有点晚了。

很抱歉听起来像是一张卡住的唱片，但控制台警告似乎不起作用。 例如https://code.gov。

很抱歉听起来像是一张卡住的唱片，但控制台警告似乎不起作用。 例如https://code.gov。

一个单一的反例表明它并非万无一失-但我认为任何方法都不会。

如果控制台警告能够提高意识并减少错误运行开发模式的人数，那么这似乎是朝着正确方向迈出的一步。 完美是善的敌人。

@jakearchibald

是的，但是如果 code.gov 的构建工具在这里设置了钩子，那么这_将_阻止您观察到的问题，至少在 React 使用构建时钩子的上下文中。 毕竟他们正在使用 webpack。

我并不是说 webpack 应该发出构建警告。 我是说正确的解决方法是 webpack 为您设置process.NODE_ENV ，或者如果您尝试在没有适当的生产配置的情况下进行生产构建，则 webpack 默认会失败构建。

想要快速回复@addyosmani 早先关于 DevTools“违规”的观点。 我们的原型设计显示了 Chrome DevTools 中某些错误的更强迹象，但这项工作还很早，我倾向于同意@jakearchibald的观点，即显示警告（即使它比console.warn更可怕）不是一个足够好的解决方案。

当且仅当NODE_ENV == 'development'或主机名是localhost / 127.0.0.1时，默认 React 到生产模式并打开开发模式怎么样？ 大多数开发人员将获得开箱即用的正确行为，并且如果您确实需要，总会有一种手动强制开发模式的方法。

似乎仍然不理想地仍然使用可能相当复杂的条件（因为你需要不只是在节点上失败）一直打那个分支。

顺便说一句，webpack 2 中的-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 来说将是一个重大变化。 我个人觉得一个运行时解决方案，涉及一个清晰的覆盖消息_only_使用一些智能启发式（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 等）显示会充分覆盖我们。

我觉得这已经被多次击落（“框架将东西注入 DOM 是不可接受的”），而没有真正意识到会发生这种情况的_only_场景。

我完全同意你们在开发过程中不断地处理 DOM 中的永久消息和意想不到的事情是不可接受的。 但是，我们在这里建议的是，当且仅当 DevMode 部署到生产环境时才会显示一条消息（输入启发式方法！）。 可以在工具、CI 和浏览器扩展中内置任意数量的检查和控制台消息，以防止这种情况发生。

但作为一个绝望的、万不得已的故障保险，我认为屏幕上可见的横幅是一个很好且合适的解决方案。

当且仅当 DevMode 部署到生产环境时才显示（输入启发式方法！）

因此，开发人员将永远不会看到此消息，将开发模式（可能是偶然的）部署到生产环境中，然后突然他们看到这个新的 HTML 显示在他们的应用程序上供所有用户查看？

这对我来说更像是一种惩罚。 如果你还不了解开发模式并且你使用这个理论上的新版本的 React 和消息进行部署，那么你会得到一个惊喜，并且你当时在 Web 应用程序上的用户也会看到它。 我看不出这对任何人有什么帮助，只会让开发人员或公司难堪。 当然，也许这会让他们修复它，但在我看来，这个成本太高了，而且缺乏一点同理心。

但作为一个绝望的、万不得已的故障保险，我认为屏幕上可见的横幅是一个很好且合适的解决方案。

这个解决方案的问题在于它过于理想化，当您开发一个框架时，您必须关注其他公司可能没有最好的部署策略甚至最好的 QA（如果有的话）的现实。

是的，如果有人在生产中部署到开发模式，他们应该能够看到它并快速更改它。 不幸的是，尤其是在技术行业之外，这根本不可能或不容易。 大多数人在这里评论？ 他们的公司可能有可以很好地应对这种情况的部署流程。 谷歌、Facebook、PlayStation 等； 所有这些技术公司都可以处理这个问题，但这并不能代表大多数使用 React 的用户，对吧？ （实际上，我们有没有关于 React 使用的统计数据？会很方便！）

是的，是的，这些公司和政府应该改变他们的部署流程和政策等。但现实是这样的：大多数公司都有垃圾部署流程和垃圾到不存在的质量保证。

让我们以我亲身经历的两个场景为例。

首先，在政府工作期间，根据分支机构和部门的不同，您可能每 3-6 个月进行一次部署。 这些部署尽可能多地汇总，如果整个部署的任何部分失败，一切都可能被回滚。 所以我们使用了这个名为 OWF 的软件，如果你不熟悉，它就像 iSocial 一样，它使用 iframe 在一个 Web 应用程序中显示多个 Web 应用程序（我知道，很糟糕，但请留在我这里）。 在部署我们的几个应用程序时有一个手动配置步骤失败，导致在某些 iframe 中显示 404 和 500 错误，而不是在预期的应用程序中显示。

由于开发人员通常无法访问部署到其中的系统，因此我们花了好几个小时才发现任何问题。 那时，我们不得不让我们的老板打电话给别人的老板，打电话给他们的老板，告诉他们这不会影响其他任何事情，这样他们就不会回滚整个部署。 然后，在我们让任何人在几天后重做一些配置之前，我们需要填写大量的文书工作和文档。 同时，在整个时间段内，应用程序都无法运行。

其次，当我在金融部门工作时，我们进行了一次部署，无意中包含了开发人员的姓名，而不是网站上实际项目的布局（我相信他正在测试什么？）。 无论如何，它马上就被注意到了，但为了修复它，我们必须进行紧急变更控制，直到那天晚些时候才通过。 因此，他们的客户必须看到这个愚蠢的横幅几乎整整 8 小时才能修复。

我的观点是：在向 DOM 中注入开发人员没有放入的任意元素时需要非常小心。 尤其是如果我们谈论仅在某些情况下显示它，那么当有人第一次看到它时，他们会想办法快速禁用它，这样他们就不需要再被它打扰了。

@克里斯西格尔

如果你还不了解开发模式并且你使用这个理论上的新版本的 React 和消息进行部署，那么你会得到一个惊喜，并且你当时在 Web 应用程序上的用户也会看到它。

如果消息仅在 DevTools 打开时显示（即，非开发人员的生产用户看到的可能性很小），我很好奇您对方法的想法是否有任何不同。 有效地扩展了 React 今天已经采用的当前 console.log 策略。

如果消息仅在 DevTools 打开时显示（即非开发人员的生产用户看到的可能性很小），我很好奇您对方法的想法是否有任何不同。 有效地扩展了 React 今天已经采用的当前 console.log 策略。

如果您打开了开发工具，那么您可能会看到 console.log 消息，因此 DOM 更改似乎是管理不必要的复杂性，而且它是多余的。 你总是可以让 React 控制台消息更大/更漂亮。 也许是一个 ASCII React 标志。 如果他们碰巧进入那里，可以引起某人注意的东西。

最终，尽管我认为有人会遇到这种情况，但在 Stackoverflow 上询问如何禁用警告，有人会发布代码向他们展示如何执行此操作，然后人们会在遇到它时简单地禁用它。 构建工具有很多，我过去与之交谈过的许多人都发现它们令人困惑或困难（Babel 6 的发布是一个“有趣”的时期）。 你会遇到很多从不正确使用它们的人。

至少这是我的经验¯\_(ツ)_/¯

呼，终于赶上了线程的底部。 好的。 我一直在头脑风暴这一点。

Webpack 可以强制指定 NODE_ENV，然后 React 可以使用它来更容易地避免人们将 DEV 运送到 PROD，但这将是对 Webpack 的重大更改。 我现在正在和 Sean 讨论这样的事情对于 Webpack 3 的可行性。保持 React + Webpack 堆栈初学者和性能友好是我知道两个阵营都关心的事情。

到目前为止，这感觉像是我最喜欢的，但我还没有 100% 售出。

1. 因此可以强制在任何人运行 webpack 时传入 ENV。 一条有用的错误消息指出您必须提供一个 env 变量才能运行 webpack。

然而，这为用户提供了一个重要的反弹点。 不是每个人都在为 prod 或 dev env 写作，甚至不知道 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_”区域。 这将是我们希望确保社区和团队能够接受的一个领域。

@TheLarkInn我相信这在 v2 中发生了变化： https: //webpack.js.org/guides/production-build/#node -environment-variable

啊对不起，我错了。 然而，它并不经常使用，因为人们希望对他们优化的内容进行更细粒度的控制。 （就像@addyosmani提到的）

真的那么普遍吗？ 当我开始使用 webpack 时， -p显然是我要走的路。 就像我上面提到的那样，即使有充分理由应用进一步调整的库仍然使用-p 。

我们可以创建一个新的解析器模式，它将检查 React（或任何需要它的 fw）的 package.json 中的以下内容：

“网络包”：{
“插件”：“反应环境插件”
}
这将自动应用于用户编译器配置，而无需他们知道或关心。

@TheLarkInn如果我没看错的话，要触发解析器模式，应用程序的 package.json 需要手动指定ReactEnvironmentPlugin ，对吗？ 还是我误解了这个提议？ :)

我可以想象 Webpack 中的一些解析魔法，它检测到一个项目正在使用 React 并为它们进行正确的环境切换，但这听起来像是特定于框架的优化与捆绑器的紧密耦合，可能并不理想。

更少的是它会检测到反应，更多的是它会检测到一个 js 模块描述字段，包括一个带有插件的 webpack 字段。 但你是对的，它是非常紧密耦合的，也不是我最喜欢的想法。

我不认为这真的给你任何保证，除非 webpack 有一个“生产”模式的概念来弄清楚如何配置 React——这似乎是多余的，因为如上所述， -p已经做对了无论如何，这也是用户在使用 webpack 进行小型生产构建时通常会达到的目标。

我们已经讨论了更多，我认为有一个合理的解决方案。

我们长期以来一直在考虑为开发中的 React 警告启用“警告框”。 你可以在这里看到一个演示（公关：https://github.com/facebook/react/pull/7360）。 它仅在您有警告时显示，但它们在开发过程中很常见（并且应该始终修复），因此大概任何花费超过五分钟开发应用程序的人都会看到该对话框并知道它存在。

这种变化之后，开发模式就很难不被察觉了。 您可能会搜索“如何删除警告对话框”并了解如何构建生产环境。 如果不这样做，您可能会在某个时候部署一些警告，并且您的用户会看到它们。 我认为在这种情况下人们不会责怪 React 本身，因为我们不只是将盒子展示为令人讨厌——我们只是做开发模式应该做的事情。

（顺便说一句，我们在 Facebook 的开发中使用类似的警告框已经很长时间了，所以它与我们打算如何使用 React 相对应。）

我真的很高兴看到这个提议，@gaearon！ 这是我梦寐以求的一切；）

作为一个方面：也许值得考虑直接在框中有一个链接，而不需要开发人员谷歌如何摆脱它。

是的，好点。 我们会添加一些东西。

@gaearon我发现该解决方案非常令人讨厌； 即使在开发过程中，我也不希望警告侵入 DOM。 这对普通开发人员来说是零用途，并且可能会被大多数人完全禁用。 开发人员工具显示警告是有原因的，它们不需要被发明。

我还发现令人不安的是，DOM 解决方案不断出现，对我之前反对它的任何论点的反驳为零。 如果我的观点被忽略，那很好，这不是我的存储库，所以这很公平，但是看到同样的论点出现令人沮丧，人们发表反对意见，人们似乎是为了要点，因为从来没有反对他们的论点，然后他们就回来了。 冲洗，重复。

虽然我同意大多数警告都是如此，但 React 警告特别指出了代码中的错误。 它们不仅仅是建议。

该对话框很容易关闭，个别警告很容易打盹（以防您暂时不关心它们），但需要修复它们。

为了比较，这是对话框在 Facebook 代码库中的外观：

成千上万的工程师对此没有任何问题，并且由于它而提高了生产力，因此我们认为这是一个合理的默认设置。 说清楚点，开源版本会少喊几句：

如果您对样式调整有任何建议，请随时在https://github.com/facebook/react/pull/7360 上发表评论。

再加上 Dan 所说的，我正在 #7360 之上构建以连接到我们最近添加的错误记录器流。 我目前正在尝试几种不那么侵入性的 Toast 通知样式。 我会尽快发布一些屏幕截图和/或 Plnkr 以获得反馈。

这些警告是否包括“缩小的开发代码”警告？ 如果是这样，那会很好地解决很多事情。

我不明白为什么它也不能用于此目的。

@gaearon

虽然我同意大多数警告都是如此，但 React 警告特别指出了代码中的错误。 它们不仅仅是建议。

这些应该是国际海事组织的错误或例外。 他们为什么不呢？ 例外情况会迫使事情得到纠正，但可忽略的警告不会。

成千上万的工程师对此没有任何问题，并且由于它而提高了生产力，因此我们认为这是一个合理的默认设置。

我在前面提到过这一点，但我猜这些工程师可能比 90% 将使用开源版本的人更好。 我发现它与合理的默认值相反。 开发工具有警告是有原因的； 重新发明它们对我来说没有意义。 它会被禁用，再也见不到了。

这看起来像 React 试图做太多的 IMO。

当我做政府合同时，我们有一个公共图书馆，所有前端都必须使用。 它会在控制台中出现错误并将它们显示为吐司弹出窗口。 它不仅被多个团队多次部署到生产环境中，而且许多开发人员曾经看过它，然后询问如何永久禁用它。 我认为这更像是一样的。

我们长期以来一直在考虑为开发中的 React 警告启用“警告框”。 你可以在这里看到一个演示（PR：#7360）。 它仅在您有警告时出现，但它们在开发过程中非常常见（并且应该始终修复），因此大概任何花费超过五分钟开发应用程序的人都会看到该对话框并知道它存在。

我真的很喜欢#7360，@gaearon。 听到有人支持在新的警告框中强调需要切换到 PROD 进行部署，这令人振奋。 它很好看。

加上 Dan 所说的，我正在 #7360 之上构建以连接到我们最近添加的错误记录器流。 我目前正在尝试几种不那么侵入性的 Toast 通知样式。 我会尽快发布一些屏幕截图和/或 Plnkr 以获得反馈。

@bvaughn期待看到更多你的迭代:)

对于那些觉得警告框方法可能过于干扰的人，其他库（例如 VueJS）已经在您的开发/迭代工作流程中显示 DOM 覆盖，以鼓励修复错误或慢速路径：

我自己的经验是，虽然这是一个小小的不便，但这些消息比您在控制台中看到的更明显。 我认为 Dan 的观点是正确的，它至少会更加强调开发模式，而不是你应该部署到 prod 的东西，并有望导致更多的网站向最终用户提供“更快的模式”。

这种变化之后，开发模式就很难不被察觉了。 您可能会搜索“如何删除警告对话框”并了解如何构建生产环境。 如果不这样做，您可能会在某个时候部署一些警告，并且您的用户会看到它们。 我认为在这种情况下人们不会责怪 React 本身，因为我们不只是将盒子展示为令人讨厌——我们只是做开发模式应该做的事情。

这些应该是国际海事组织的错误或例外。 他们为什么不呢？ 例外情况会迫使事情得到纠正，但可忽略的警告不会。

虽然它们应该被修复，但我手头可能有更紧急的事情。 例如，我是否经常对 UI 进行原型制作/模拟，同时我会编写快速且通常低于标准的代码，React 会发出警告。 虽然我想修复这些警告，但我真的不在乎，直到我知道至少在接下来的一个小时内我不会丢弃所有代码。 强迫人们立即修复它们将大大减慢实验开发的速度。

对于那些觉得警告框方法可能过于干扰的人，其他库（例如 VueJS）已经在您的开发/迭代工作流程中显示 DOM 覆盖，以鼓励修复错误或慢速路径：

屏幕截图 2017-01-24 上午 10 点 57 分 11 点

你确定那是来自 Vue 本身吗？ 它看起来很像webpack-hot-middleware的错误覆盖显示的 webpack 构建错误。 如果是这种情况，它会略有不同，因为它是添加覆盖的开发时构建工具，而不是通用前端框架。

一般来说，我赞成警告覆盖，但我认为它应该包含解释性文本，说明它是什么，为什么它在那里，并且它可以&应该作为关闭开发模式的一部分被禁用。 如果那有点长，那么在expando后面 - 但它似乎是传达信息的好地方。

我害怕像 15.2.0 这样带有覆盖的更新。 轻微的颠簸，突然之间你收到了 100 条关于 props 被传递到 DOM 节点的警告。 错误可能，但我不认为折旧警告属于这样一个侵入性的空间

错误可能，但我不认为折旧警告属于这样一个侵入性的空间

我不知道这之前是否已经非常清楚地传达过，但是关于黄框警告 (#7360) 的想法是不显示 _all_ 警告（弃用或其他）。 相反，团队认为_特别重要_的某些警告将以这种方式突出显示。 其余的可能会保留在控制台中。

至少这是我从汤姆和我一两个星期前关于这个功能的谈话中得出的结论。

15.2 中的道具警告也是 IMO 错误，并不代表我们的正常 MO 我们希望有一种方法可以通过次要版本控制警告级别以避免这种情况。

我们的团队不使用生产构建的主要原因是因为我们无法运行 JS 单元测试，因为不包括测试工具。

首先，再次感谢 React 团队（ @sebmarkbage 、 @gaearon 、 @tomocchino和其他人）与我们讨论这个问题，并如此开放地与我们讨论 BlinkOn 的性能和移动以及本季度的其他同步。

状态检查

根据https://github.com/facebook/react/pull/7360中的@aweary ，该特定问题的 Yellow Box 解决方案已被搁置，直到 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 。

想法？

我们的团队不使用生产构建的主要原因是因为我们无法运行 JS 单元测试，因为不包括测试工具。

我对此感到困惑。 您是否在生产网站上运行测试？ 如果没有，是什么阻止您在生产网站上使用生产构建，以及在开发中构建开发？

对于其他所有人，是否会支持https://facebook.github.io/react/docs/installation.html ，包括在安装 React 标题下的清晰可见的标注，提醒人们注意生产中的 DEV 模式？

当然。 想发送 PR？

当然。 想发送 PR？

乐此不疲。

也许关于基准的一个词也会很好地帮助教育那些将性能与开发模式下的反应进行比较的人？

让我觉得在开发模式下使用 react 打开页面时，可以利用 react devtools 扩展来显示通知或明显的东西？

我喜欢这个主意！ 我为 devtools 整理了一组建议的图标（参见 facebook/react-devtools/pull/652）。

我们需要决定如何以一种向后和未来安全的方式检测 dev 与 prod React，但我已将其添加到周一会议议程中。

我们已经采取了一些合理的步骤来解决这个问题：

• React DevTools（拥有约 700K 用户）现在为开发构建显示一个独特的红色图标。 这有助于人们及早了解版本之间的差异。 这也会造成一些同行压力，因为开发人员会在他们访问的网站上注意到这一点，并向工作人员报告。 我们已经看到一些主要网站在推出后几天内解决了这个问题。

• React DevTools 中的通知链接到我们的网站，我们在其中发布了为所有主要捆绑程序创建生产构建的说明。 我们还在安装页面上使其更加突出。

• Create React App 继续受到欢迎。 它通过单独的命令及早教导这种区别。 它还在终端中显示有关开发模式的永久通知。

• React 16 Beta 1 （和更多版本）附带react.development.js和react.production.min.js作为文件名，以明确非缩小版本不应在生产中使用。

我想未来我们可能会探索更多的方法来解决这个问题，但现在我觉得我们可以在没有更激烈的措施的情况下继续前进，看看它是否有帮助。 感谢大家的讨论。