React: Explore alentar a los usuarios a no enviar el modo DEV a producción

Para referencia: https://github.com/facebook/react/pull/8782

Por contexto ya avisamos si detectamos que has minimizado una versión DEV de React: https://github.com/facebook/react/blob/8791325db03725ef4801fc58b35a3bb4486a8904/src/renderers/dom/ReactDOM.js#L91 -L98

En la medida en que podamos encontrar heurísticas similares para notificar a los usuarios, y tal vez incluso mostrar un cuadro de diálogo DOM de manera más agresiva, deberíamos hacerlo.

También quiero dejar claro que las advertencias que brindamos pueden mejorar significativamente el rendimiento si las personas les prestan atención. Este hilo explica algunas razones por las que es difícil implementar esto después del hecho si no es el predeterminado.

También me gustaría participar con una sugerencia de una sola consola. Advertir si renderToString se llama en modo de desarrollo. Obviamente, en la mayoría de las situaciones renderToString se llama en el nodo, donde no podemos alertar ni abrir un cuadro de diálogo DOM.

Desafortunadamente, realmente me gustaría poder detectar no solo si NODE_ENV está establecido en production , sino también si se ha compilado process.env.NODE_ENV . ¿Alguien sabe de una manera de hacer eso?

Gracias por el hilo @sebmarkbage y reconozco las dificultades de implementar después del hecho. También agradezco las advertencias actuales. Parece que algunos desarrolladores pueden no verificar la salida de la consola de sus sitios implementados tan a menudo como podrían. Sin embargo, es un buen primer paso.

En la medida en que podamos encontrar heurísticas similares para notificar a los usuarios, y tal vez incluso mostrar un cuadro de diálogo DOM de manera más agresiva, deberíamos hacerlo.

Estaría agradecido por las mejoras en la heurística utilizada para notificar a los usuarios. Un diálogo DOM más agresivo sería de gran ayuda. Garantizaría que el sitio siguiera funcionando para los usuarios finales, pero proporciona una pista activa de que hay frutos de bajo rendimiento que los desarrolladores pueden elegir.

La alternativa es que encontremos una manera de arreglar esto en un nivel de herramienta de compilación/ENV como se menciona en la publicación original. Eso evitaría que sea necesaria cualquier inyección de DOM.

Inyectar cualquier mensaje en el DOM parece peligroso y demasiado presuntivo. Eso abre la posibilidad de que los usuarios finales reciban alertas inesperadas y confusas, lo que parece inaceptable en mi opinión.

@thelarkinn proponía que tratáramos de estandarizar las configuraciones ENV requeridas para facilitar mejor la detección de mensajes como este

Este se siente como el espacio ideal para abordar esto. Es un problema de compilación y debe ser, si es posible, abordado por las herramientas de compilación.

Anecdótico: Las advertencias en la consola han pasado desapercibidas (o ignoradas) en el pasado. No tengo números concretos aquí, pero creo que las advertencias basadas en la consola no son suficientes. Estoy de acuerdo con @addyosmani en que una advertencia basada en DOM sería muy útil.

@surma tal vez deberían usar console.warn o console.error para una mejor visibilidad 😉

No veo cómo sería aceptable en cualquier escenario inyectar contenido en una aplicación solo cuando se está ejecutando en producción. Está asumiendo que el mensaje se detectaría antes de que la aplicación se enviara a los usuarios reales, donde el mensaje podría dañar la experiencia de usuario de manera importante.

Por cierto, agregaremos un soporte de manejo de errores más completo en Fiber para que puedas reemplazar los componentes que tienen fallas (errores arrojados) con vistas de error personalizadas. Incluso en el escenario predeterminado, es probable que seamos muy agresivos y simplemente eliminemos ese componente del árbol si falla, por lo que realmente querrá tener una interfaz de usuario de error personalizada para sus usuarios de todos modos.

Es posible que podamos activar un error de este tipo para esta advertencia.

Sinceramente, no creo que console.{error,warn} por encima console.log hubieran cambiado nada. Como dije, esa historia es anecdótica.

Tampoco estoy diciendo que mostrar un diálogo DOM sea _la_ solución. Sin embargo, es algo con lo que personalmente me sentiría cómodo. Si permanecer en el modo de desarrollo tiene un impacto negativo, al menos los usuarios sabrán que _algo_ está mal y probablemente comiencen a presionar el botón "Ayuda" o algo así.

En pocas palabras: creo que los marcos deben estar en la cara del desarrollador en algún momento. Me encantaría hacer una lluvia de ideas sobre esto para ver qué pasos y compromisos están dispuestos a tomar los autores del marco para evitar que las personas implementen en modo desarrollador en el futuro.

¿Qué sucede si React simplemente no funciona a menos que proporcione un entorno, independientemente de si es desarrollo o producción? De esa manera, se hace una elección consciente de una forma u otra.

Sobre el mensaje inyectado en el DOM, podría deshabilitarse usando un global o algo así. No es gran cosa en mi opinión. Si lo desactivas, reconoces que sabes lo que estás haciendo.

El problema con un mensaje de la consola es que a veces las personas registran muchas cosas o tienen otras advertencias que ignoran, y es fácil no ver ese primer mensaje de la consola más allá del desplazamiento...

Con un env obligatorio, inevitablemente repeticiones, etc. establecerán el env var para que pueda comenzar a usarlo, me temo:/

Sinceramente, no creo que console.{error,warn} sobre console.log haya cambiado nada.

¿Crees que es un problema con los desarrolladores que simplemente no revisan la consola o que la consola está sobrecargada con advertencias? ¿Podría abordarse esto (parcialmente) con un enfoque más general con respecto a la educación para desarrolladores?

Tampoco estoy diciendo que mostrar un diálogo DOM sea la solución. Sin embargo, es algo con lo que personalmente me sentiría cómodo. Si permanecer en el modo de desarrollo tiene un impacto negativo, al menos los usuarios sabrán que algo está mal y probablemente comiencen a presionar el botón "Ayuda" o algo así.

Lo entiendo, pero solo digo que no creo que sea una solución y mucho menos la solución. Es bueno que te sientas cómodo con él, pero creo que es mejor errar por el lado de la precaución y asumir que la mayoría de las personas no quieren que se muestren errores inesperados a sus usuarios.

En pocas palabras: creo que los marcos deben estar en la cara del desarrollador en algún momento. Me encantaría hacer una lluvia de ideas sobre esto para ver qué pasos y compromisos están dispuestos a tomar los autores del marco para evitar que las personas implementen en modo desarrollador en el futuro.

Estoy 💯 por ponerme en la cara del desarrollador, pero es importante hacerlo en el lugar correcto. Para mí, ese es el paso de construcción, no la producción.

Sobre el mensaje inyectado en el DOM, podría deshabilitarse usando un global o algo así. No es gran cosa en mi opinión. Si lo desactivas, reconoces que sabes lo que estás haciendo.

Tenerlo habilitado de forma predeterminada es tan malo como no hacerlo configurable: el comportamiento predeterminado podría resultar en un comportamiento inesperado para el usuario final. En todo caso, debería estar deshabilitado de forma predeterminada, pero eso anula todo el propósito, ya que los desarrolladores podrían solucionar el problema inicial una vez que lo sepan.

El problema con un mensaje de la consola es que a veces las personas registran muchas cosas o tienen otras advertencias que ignoran, y es fácil no ver ese primer mensaje de la consola más allá del desplazamiento...

Lo entiendo totalmente, la consola puede llenarse y es fácil perderse cosas. Pero está abarrotado por las razones exactas que estoy argumentando: es el lugar donde los desarrolladores brindan comentarios o errores. Está fuera del camino de la experiencia del usuario, lo que no ocurre con los mensajes inyectados.

Tiene sentido, entiendo el razonamiento.

Bueno, tal vez hacer que la cosa salga usando el formato de la consola sería algo al menos.

El problema es que casi nadie mira la consola en producción. Puede usar cualquier fuente allí y la gente no lo notará.

Sin embargo, si hacemos que muestre un mensaje de forma predeterminada en producción como un cambio importante (en 16 o 17), sería difícil pasarlo por alto. Quiero decir, sucedería la primera vez que intentaría implementarlo (para nuevos usuarios), y los usuarios existentes deberían leer las notas de la versión al actualizar a una nueva especialidad. Así que creo que es factible siempre y cuando seamos muy explícitos al respecto y sea imposible perderse el mensaje.

El problema es que casi nadie mira la consola en producción. Puede usar cualquier fuente allí y la gente no lo notará.

Solo puedo comentar sobre la experiencia del equipo de Chrome con esto, pero estoy de acuerdo. La mayoría de la gente notará los mensajes de la consola durante su flujo de trabajo de iteración, pero un porcentaje mucho menor verá las advertencias en los sitios de producción y menos actuará en consecuencia.

Sin embargo, si hacemos que muestre un mensaje de forma predeterminada en producción como un cambio importante (en 16 o 17), sería difícil pasarlo por alto. Quiero decir, sucedería la primera vez que intentaría implementarlo (para nuevos usuarios), y los usuarios existentes deberían leer las notas de la versión al actualizar a una nueva especialidad. Así que creo que es factible siempre y cuando seamos muy explícitos al respecto y sea imposible perderse el mensaje.

Gracias por estar abierto a un cambio como ese @gaearon. ¿Qué se necesitaría para llegar a un acuerdo sobre intentar un mensaje de forma predeterminada en una versión futura? 😄

Estoy de acuerdo en que las advertencias de la consola no son la solución y una advertencia visible en la página es mucho mejor.

La advertencia visible en la página podría:

• Alertar al desarrollador que el sitio está en modo de desarrollo
• Enlace a los documentos sobre los beneficios y cómo realizar envíos sin él
• Un enlace para deshabilitar el mensaje por… no sé 2 horas?

Deshabilitar el mensaje es importante, ya que puede estar interfiriendo/cubriendo algo en la página. Dado que esta configuración se almacenaría en el almacenamiento local, la advertencia seguirá apareciendo en el servidor en vivo porque tiene un origen diferente.

Sí, es bastante horrible si los usuarios reales ven este mensaje en los sitios en vivo, pero se siente como el tipo de problema que se alentará a los desarrolladores a solucionar, mientras que algunos parecen estar felices de vivir con los problemas de rendimiento del modo de desarrollo.

Si la primera vez que vi esa advertencia (la inserción en DOM), estaba en producción, estaría bastante molesto. Las advertencias deben suceder antes de tiempo.

@rtorr, mi sugerencia es que suceda siempre que el sitio esté en modo de desarrollo, por lo que debería verse con anticipación a menos que me esté perdiendo algo.

@jakearchibald perdón por la confusión, mi respuesta no fue dirigida a la tuya. Solo quiero señalarle al hilo que si tuviéramos que usar la solución 'insertar en el dom', deberíamos tener mucho cuidado y asegurarnos de que los usuarios sepan antes de presionar algo (de alguna manera, no tengo una buena idea aquí) .

Solo veo a algunos desarrolladores olvidando una configuración o algo así y la administración se asusta. ¿Vale la pena esa posibilidad por las consecuencias de tener el modo de desarrollo en producción?

Una advertencia basada en DOM que tengo que deshabilitar constantemente no está bien, debe ser posible deshabilitarla para siempre, y tal vez nunca debería mostrarse para localhost.

Una cosa que me acaba de ocurrir es si sería posible tener algún tipo de bandera en el navegador que debas habilitar para activar las herramientas de desarrollo (tal vez una gran superposición en ellas con "¿Eres un desarrollador? [Sí/No]" ) que la página puede detectar y solo mostrar la advertencia para los desarrolladores. Redactado correctamente, también podría ayudar con los ataques auto-XXS.

Una advertencia basada en DOM que tengo que deshabilitar constantemente no está bien, debe ser posible deshabilitarla para siempre

Los sitios que se inician con el modo dev activado tampoco están bien. ¿Quizás el mensaje solo debe descartarse una vez al día? Pero cuanto más largo sea el período, más probable es que termine en vivo. Si se puede desactivar para siempre, estamos justo donde empezamos.

Tampoco creo que un nodo dom no deseado en producción esté bien.

Creo que de cualquier manera, siempre tendremos un caso extremo. Si este problema ocurre todo el tiempo, entonces tal vez la entrega del modo dev sea incorrecta. Aunque no es ideal en un mundo perfecto, pero si encontramos que el modo de producción es tan importante que estamos dispuestos a modificar la aplicación de alguien, tal vez debería ser predeterminado y el modo de desarrollo debería estar habilitado.

@rtorr

Tampoco creo que un nodo dom no deseado en producción esté bien.

¿Por qué? (No digo que estés equivocado, solo me gustaría escuchar tus razones)

Tal vez agregando una configuración para definir prod Domain. Si el dominio prod no está configurado, siempre recibimos la advertencia sobre el modo DEV (con una solicitud para configurar la URL del dominio), si está configurado, solo recibimos una advertencia cuando la URL coincide con el dominio prod. Incluso podríamos vincular cualquier servicio que queramos notificar a los desarrolladores.

Me alegro de que haya una discusión constructiva aquí. Hay dos soluciones aquí que puedo ver resolviendo el problema. Webpack podría obligar a especificar NODE_ENV que React podría usar para evitar más fácilmente que la gente envíe DEV a PROD, pero eso sería un cambio importante para Webpack. Estoy hablando con Sean ahora sobre cuán factible podría ser algo así para Webpack 3. Mantener la pila de React + Webpack para principiantes y fácil de usar es algo que les importa a ambos campos.

La segunda (idea de inyección de DOM) es algo que React podría hacer y, como mencionó Jake, equilibrar la UX al permitir que el mensaje se muestre una vez al día o se descarte. Es un cambio de una línea para solucionar el problema, luego solo tiene que volver a implementar. Me identifico completamente con no querer que la gerencia se asuste.

Si queremos que más sitios de React envíen la experiencia mucho más rápida en la que FB trabajó para impulsar algo que podría ofrecer. Si alguien tiene mejores ideas por favor sugiéralas.

@jakearchibald

¿Por qué? (No digo que estés equivocado, solo me gustaría escuchar tus razones)

Volviendo a mi comentario anterior, a menos que podamos informar a los desarrolladores con anticipación (que parece ser el problema real a resolver), me parece un poco extremo devaluar el producto de alguien al mostrar una advertencia a los desarrolladores en su página de producción. En muchos casos, esto podría dañar el producto más que el rendimiento del modo de desarrollo.

No importa lo que hagamos, alguien enviará lo que sea predeterminado a producción, ¿por qué no hacer que la producción sea predeterminada? ¿Por qué no mejorar el modo de desarrollo hasta el punto en que no tenga un impacto tan grande?

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

@jakearchibald sí, veo que ambos lados tienen problemas. Tengo fe en la gente de este hilo para que se le ocurra algo bueno, incluso si es lo que estás proponiendo. Todos ustedes son geniales FYI. Tal vez extremo es la respuesta.

¿No podría insertar la advertencia del nodo DOM si el usuario está ejecutando las herramientas de desarrollo de React para que los usuarios normales no lo experimenten?

@jakearchibald

Los sitios que se inician con el modo dev activado tampoco están bien. ¿Quizás el mensaje solo debe descartarse una vez al día? Pero cuanto más largo sea el período, más probable es que termine en vivo. Si se puede desactivar para siempre, estamos justo donde empezamos.

Cuando se lanzó el sitio, alguien tomó la decisión de que estaba "listo", por lo que si bien es malo, no es una catástrofe. Sin embargo, tener (posiblemente, no sé los números exactos) cientos de miles de desarrolladores que tienen que descartar la destrucción de un sitio (una advertencia DOM debe tratarse como tal, ya que no tiene idea de cómo interactúa con el resto del sitio y si el sitio es utilizable con la advertencia visible) la advertencia cinco o incluso solo una vez al día es una catástrofe. La mayoría de los desarrolladores tienen una cadena de compilación configurada correctamente (personalizada, crear-reaccionar-aplicación u otra) y no tienen ningún uso para esa advertencia, necesitan poder deshacerse de ella.

@dan-gamble Sin embargo, creo que los desarrolladores que no usan React Dev Tools son el objetivo más urgente para esta advertencia.

@Pajn Potencialmente, no creo que solo porque descargue una extensión de Chrome automáticamente lo haga consciente del cambio de producción / desarrollo

@dan-gamble No, por supuesto que no. Pero hay personas que desarrollan una aplicación completa sin ella, lo que creo que indica que no usan mucho las herramientas de desarrollo y, por lo tanto, es menos probable que vean la advertencia actual de código minimizado.

Por lo general, no agrego a una discusión tan larga cuando siento que el punto ya se ha planteado, pero tengo que estar de acuerdo con esto y quiero enfatizar este punto: reaccionar tocando el DOM y advirtiéndome que estoy usando una versión de desarrollo sería ser un gran error. Hasta donde yo sé, no hay precedentes de eso en ningún otro marco.

Imagina todos los tutoriales, todos los patios de recreo, todos los pequeños proyectos paralelos que usan el modo de desarrollo para enseñar React. Cada pequeño sitio de prueba que junté para explorar algo divertido en React, o tratar de aislar un caso de prueba. Si React mostrara una advertencia en cada uno de estos sitios que tuve que deshabilitar manualmente, estaría increíblemente enojado. Se sentiría como un padre autoritario y lo desalienta activamente a usar React porque cada vez que intenta hacer algo nuevo, lo golpea en la muñeca.

Incluso haciéndolo cada 2 horas ? No gracias. Una molestia constante como esta ciertamente disuadirá a los usuarios de desarrollar en React y, sinceramente, creo que alejaría a las personas para adoptar otros marcos. ¿Quizás eso es lo que quieren los desarrolladores de Chrome?

Sin mencionar el hecho de que sí, esto entrará en producción de alguna manera, y ya es bastante difícil convencer a ciertos equipos para que adopten React y eso es solo más munición para ellos contra él.

Lo que más me gusta de React es que no hace nada hasta que llamas a ReactDOM.render(...) y cuando lo haces, solo pone cosas en el DOM donde tú lo indicaste. Por eso es una biblioteca tan buena, aislada y funcional.

¿También necesitamos detectar si las personas envían un paquete sin minificar? ¿Qué pasa si no están almacenando en caché cuando deberían? ¿Qué pasa cuando no han configurado nginx de manera óptima? ¿O no usa shouldComponentUpdate cuando debería? ¿O están renderizando todo innecesariamente cuando no es necesario?

Hay varias razones para el mal rendimiento y culpar únicamente al modo de desarrollo de React es incorrecto. Cuando implementa un sitio, se espera que comprenda cómo implementar un sitio optimizado. No digo que no haya cosas que podamos hacer, pero la razón principal de este problema es que los autores de referencia no hacen su debida diligencia y no deberíamos tener que pagar por eso. Necesitamos encontrar otra manera de llamar eso.

Tenía la intención de seguir con lo que creo que es la solución correcta: poner este tipo de restricciones en las herramientas. Asegurándonos de que el paquete web o cualquier herramienta que use para construir su sitio para producción es donde debemos forzar estos controles y estoy de acuerdo con cualquier tipo de restricción que queramos colocar en el proceso de construcción.

Con respecto al paquete web que fuerza una configuración de NODE_ENV (tal vez ya haya un problema para esto en su repositorio), ¿no sería más difícil usar bibliotecas que no dependan de la configuración de env?

¿O la idea es que detectaría el uso de NODE_ENV y lo forzaría solo si el código lo usa?

No nos obsesionemos demasiado con el asunto de las "2 horas". Podría ser cualquier período de tiempo mientras funcione.

Además, los eventos de almacenamiento local significan que solo sería necesario descartarlo una vez por origen. Si tiene varias demostraciones en una página, descartar una descartaría las demás.

Si la advertencia se activa, es lo suficientemente fuerte como para garantizar una solución rápida, una que beneficie a los usuarios. Si nos preocupa cómo se ve React en público, realmente queremos evitar una desaceleración innecesaria como esta.

Claro, esto no detectaría encabezados de almacenamiento en caché incorrectos, etc., se trata de detectar solo el "modo de desarrollo". Además, los argumentos de "pendiente resbaladiza" no son útiles.

No creo que mover el problema a las herramientas de compilación sea útil, ya que tendrá el mismo problema si los desarrolladores usan una herramienta de compilación diferente, o si no la ponen en modo de producción. Los marcos de trabajo del modo Dev ya generan advertencias en la consola, y eso claramente no funciona.

No se trata solo de puntos de referencia, se trata de sitios web reales, que funcionan lentamente para usuarios reales, porque no se cambió un interruptor.

@jakearchibald Gracias por la respuesta racional a mi respuesta cargada de emociones. Creo que es un punto válido que hay muchas razones por las que un sitio puede ser lento con React. Me gustaría ver una forma en que podamos sugerir mejoras de rendimiento que sean mejores que una verificación cruda del modo de desarrollo y una advertencia en el navegador. Si tuviéramos herramientas para analizar una aplicación React y proporcionar sugerencias serias para el rendimiento, desde todo como el modo de desarrollo hasta demasiadas representaciones, eso sería mucho más útil. Una herramienta genérica como esa se puede conectar a cualquier tubería, ya sea webpack, browserify, etc.

Sin embargo, esto es lo principal que quería decir: algunos días usaré el modo de desarrollo de React en 5 a 10 lugares diferentes, como jsbin, tutoriales e incluso armaré un pequeño sitio de prueba y lo abriré con el protocolo file://. Una advertencia forzada en el navegador es hostil a este tipo de desarrollo flexible, que es en lo que la web sobresale. Estaría viendo estas advertencias en todas partes porque estoy aprendiendo React en todos los dominios en la web.

Si la advertencia se activa, es lo suficientemente fuerte como para garantizar una solución rápida, una que beneficie a los usuarios. Si nos preocupa cómo se ve React en público, realmente queremos evitar una desaceleración innecesaria como esta.

Incluso permitir la posibilidad de que se muestre una advertencia específica del desarrollador a los usuarios finales me parece inaceptable. Un sitio lento es una cosa, pero un mensaje como este podría socavar la confianza del usuario, especialmente para los sitios centrados en la seguridad (¿le gustaría que su sitio bancario mostrara errores crípticos de repente?) ¿Google estaría de acuerdo con todos sus los usuarios reciben repentinamente esta advertencia, aunque solo sea por un momento?

Además, los eventos de almacenamiento local significan que solo sería necesario descartarlo una vez por origen. Si tiene varias demostraciones en una página, descartar una descartaría las demás.

No puede confiar en localStorage para deduplicar esto. No hay garantía de que localStorage (o cualquier otro dato persistente local) no se borre en ningún intervalo.

editar : Además, al mostrar solo el error una vez cada {INTERVAL} , ahora ha hecho que sea mucho más difícil de reproducir y depurar, ya que no es reproducible de manera determinista.

Hay 2 casos que necesitan ser resueltos:

• Evite puntos de referencia falsos, pruebas de rendimiento: se resuelve fácilmente con un gran mensaje de consola grande.
• Evite el envío de DEV a los sitios de producción: las personas no abren herramientas de desarrollo en producción.

Los argumentos en contra de tocar el DOM son convincentes.

Si hay una advertencia de consola grande, llamativa y obvia, es probable que antes del envío a producción, las personas usen la versión de desarrollo y vean este mensaje de consola realmente obvio. O tal vez algún código ya se envió a producción, pero para otro proyecto usarán la próxima versión de reacción con este mensaje de consola imposible de perder. Tal vez recuerden el sitio que enviaron a producción y verifiquen si DEV está habilitado allí.

El mensaje de la consola sería educativo, como que cualquiera que desarrolle React sabe que hay algo realmente importante sobre DEV, y lo ven cada vez que usan React para el desarrollo.

Tenía mis dudas acerca de https://github.com/facebook/react/pull/8782 porque a las personas generalmente no les gustan las advertencias de las que no pueden deshacerse (ver https://github.com/facebook/react/issues/ 3877), pero considerando las alternativas podría ser una solución aceptable.

Curioso. ¿El uso de localStorage invocaría la ley de cookies de la UE en un sitio que no está cubierto por ella?

Si las advertencias informativas durante el desarrollo son una buena idea, ¿por qué no lo están haciendo otras bibliotecas? Bueno, una de las razones es por problemas como este. Si otros quisieran hacer esto, ¿deberían también mostrar interfaces de usuario similares? ¿Hay que cerrarlos todos?

Me parece que sería ideal tener algo más central para manejar esto.

¿Quizás Chrome podría tener un modo de desarrollo? Las bibliotecas podrían decirle al host que están en modo de desarrollo y luego Chrome podría agregar una insignia o una ventana emergente para indicarlo.

Me hace pensar que la extensión reaccionar devtools podría aprovecharse para mostrar una notificación o algo obvio al abrir una página usando reaccionar en modo de desarrollo, ¿quizás?

@sebmarkbage

Si las advertencias informativas durante el desarrollo son una buena idea, ¿por qué no lo están haciendo otras bibliotecas?

Supongo que alguien tiene que ser el primero. Angular tiene un problema similar, con cosas como http://code.gov iniciando en modo de desarrollo. Si React comienza a detectar estas cosas donde otros marcos no lo hacen, presionaré para que realicen cambios similares.

Los presionaré para que hagan cambios similares.

@jakearchibald , ¿está sugiriendo que cada marco debería proporcionar su propia advertencia? No creo que establecer el estándar para marcos/bibliotecas que proporcionen sus propias advertencias de desarrollo en producción sea una gran idea. ¿No deberíamos estar tratando de estandarizar en la plataforma? Como lo menciona @sebmarkbage

¿Quizás Chrome podría tener un modo de desarrollo? Las bibliotecas podrían decirle al anfitrión que están en modo de desarrollo y luego Chrome podría agregar una insignia o una ventana emergente para indicarlo.

Creo que esta es una gran idea. Precedente: Safari tiene un modo separado que debe habilitar para acceder a DevTools. Si Chrome hiciera lo mismo, también podría agregar de manera segura un indicador para el modo DEV y una API para activarlo. Este indicador solo sería visible para los desarrolladores, por lo que no interrumpiría la experiencia del usuario.

¿No llevará tiempo esperar a que los proveedores de navegadores implementen tal cosa?

@jide sí, pero es más importante abordar este problema correctamente que rápidamente. Además, se puede implementar en un solo navegador antes de considerar los esfuerzos de estandarización (si es necesario).

@aweary

¿Está sugiriendo que cada marco debería proporcionar su propia advertencia?

Dado que cada marco proporciona su propio modo de desarrollo (y ese modo puede ser muy diferente entre los marcos), parece completamente justo que el marco implemente la advertencia de una manera única similar.

Los navegadores han hecho todo lo posible para evitar exponer las herramientas de desarrollo a la página. Si estamos haciendo devtools la barrera de entrada aquí, vamos a perder muchos usuarios que una advertencia DOM no pasaría por alto. Una advertencia de DOM no solo parece más simple, tiene menos dependencias de plataforma y llegará a más desarrolladores. Más simple y más efectivo suena como una victoria.

@gaearon En el lado de Chrome DevTools, hemos realizado una lluvia de ideas sobre una "API de infracciones" en vivo que los autores de marcos y plataformas web podrían usar para señalar advertencias importantes. Estos se presentarían en algún lugar como la próxima actualización del panel Auditorías. Suena similar a su pregunta y podría usarse para activar una advertencia en la detección del modo DEV.

Para este problema en particular, es posible que esté buscando algo un poco más ruidoso de lo que planeábamos originalmente. Un panel de infracciones, similar a los mensajes de registro de la consola, requiere que sepa que un panel le proporcionará información. Tal vez haya espacio adicional de UX para algo que muestre una superposición de página muy visible en la parte inferior de la página para la cual los marcos podrían estandarizar la mensajería. En bucle @paulirish y @s3ththompson para conocer sus pensamientos después del fin de semana festivo.

Fwiw, creo que esta API no estará lista hasta dentro de unos meses. Cuando lo esté, inicialmente solo estará disponible en Canarias y luego, 6 o 7 semanas después, podría llegar a ser estable.

Una advertencia DOM parece no solo más simple, sino más efectiva.

Estoy de acuerdo con Jake en esto. Sigamos conversando sobre la solución DevTools, pero también me gustaría averiguar qué podría estar dispuesto a hacer React como respaldo en caso de que la API no termine satisfaciendo sus necesidades o esté más alejada de la línea de tiempo.

Dado que cada marco proporciona su propio modo de desarrollo (y ese modo puede ser muy diferente entre los marcos), parece completamente justo que el marco implemente la advertencia de una manera única similar.

@jakearchibald , ¿se da cuenta de que establecer ese estándar significa que las páginas que utilizan múltiples marcos (o bibliotecas que siguieron en la suite) podrían generar una cantidad arbitraria de advertencias crípticas no deterministas que se muestran a los usuarios finales?

Los navegadores han hecho todo lo posible para evitar exponer las herramientas de desarrollo a la página.

Y estoy seguro de que la razón se debe, al menos en parte, a que los mensajes específicos del desarrollador no deben exponerse a los usuarios finales.

Una advertencia DOM parece no solo más simple, sino más efectiva.

Nadie discute en contra de la simplicidad o la eficacia de la solución. Funcionaría , pero a expensas de comprometer la experiencia del usuario. La velocidad no es lo único que puede afectar negativamente a los usuarios.

Fwiw, creo que esta API no estará lista hasta dentro de unos meses. Cuando lo esté, inicialmente solo estará disponible en Canarias y luego, 6 o 7 semanas después, podría llegar a ser estable.

@addyosmani si es una mejor solución, no veo cómo sería un problema. Cualquier cambio en React estaría en un lanzamiento importante, que creo que está por determinar en lo que respecta al momento del lanzamiento de todos modos.

La solución que se decida afectará potencialmente todo el desarrollo futuro. En mi opinión, una cuestión de semanas frente a meses en ese contexto es aceptable.

Entiendo que algunos desarrolladores se sientan invadidos si un marco inyecta algo en su DOM que no pusieron ellos mismos. Pero siento que un banner en la parte inferior de la página que dice "Este sitio está en DevMode" sería una gran solución para esto que no tiene un gran impacto en la experiencia del usuario. Me gustaría entender por qué mucha gente piensa lo contrario.

@aweary : si un sitio "centrado en la seguridad" alguna vez se lanza en DevMode, no se debe confiar en ellos hasta que solucionen el problema. "DevMode" podría incluir todo tipo de accesos directos relacionados con la seguridad, como comprobaciones CORS deshabilitadas o código fuente de plantilla expuesto, etc. Si un sitio se centra en la seguridad, esto _debe_ no suceder.

(Me doy cuenta de que "DevMode" tiene un significado muy específico en React, pero estoy tratando de asumir la perspectiva de un no desarrollador aquí)

@aweary

¿Se da cuenta de que establecer ese estándar significa que las páginas que utilizan múltiples marcos podrían generar una cantidad arbitraria de advertencias crípticas no deterministas que se muestran a los usuarios finales?

Absolutamente me doy cuenta de eso. Una página con múltiples marcos en modo de desarrollo dañará severamente la experiencia del usuario sin una buena razón. Parece que prefieres que pase desapercibido y sin arreglar. Prefiero que sea tan malo para los no desarrolladores (mensajes visibles dirigidos a los desarrolladores) que el desarrollador lo arregle rápidamente, creando una experiencia de usuario mucho mejor.

La velocidad no es lo único que puede afectar negativamente a los usuarios.

No veo a nadie que diga lo contrario? Estoy bastante triste por este tipo de reacción 😞

Parece que prefieres que pase desapercibido y sin arreglar

@jakearchibald esa es una conclusión extraña, no creo que estaría pasando mi tiempo libre aquí hablando contigo si no quisiera que esto se arreglara. El hecho de que no esté de acuerdo con su solución no significa que me resigne a dejarla sin resolver. Eso es realmente injusto.

Prefiero que sea tan malo para los no desarrolladores (mensajes visibles dirigidos a los desarrolladores) que el desarrollador lo arregle rápidamente, creando una experiencia de usuario mucho mejor.

Eso es lo que creo que es fundamentalmente inaceptable: estás castigando explícitamente a los usuarios primero.

Si un sitio "centrado en la seguridad" alguna vez se lanza en DevMode, no se debe confiar en ellos hasta que solucionen el problema.

El modo de desarrollo de @surma no es intrínsecamente inseguro, pero a pesar de eso, se está pasando de la raya para asumir que está bien que se lo comunique a los usuarios.

No creo que una solución que requiera abrir o habilitar herramientas de desarrollo sea suficiente. Para que esto se note, debe ser visible para el control de calidad, la administración y posiblemente los usuarios finales. Los desarrolladores estarán demasiado acostumbrados a ver esto. Similar a cómo se resaltan las configuraciones SSL problemáticas. No es necesario que sea mucho, pero lo suficiente como para que se note que alguien preguntará al respecto y luego lo arreglará.

Inyectar en el DOM es problemático por muchas razones. Es un poco más factible para React ya que somos una biblioteca DOM y tenemos puntos de entrada DOM. Es más difícil para las bibliotecas que no son específicas de DOM y pueden ejecutarse en un trabajador.

Una cosa que podríamos hacer es cambiar el favicon siempre que proporcionemos una forma de anularlo explícitamente. Muchos sitios ya tienen favicons separados para el modo de desarrollo.

Necesitamos encontrar una experiencia predeterminada para manejar errores en React que tal vez no pueda mantener el DOM en su lugar. La implementación predeterminada actual en el maestro elimina el contenido de React del árbol si se produce un error. Eso también es invasivo.

Si tuviéramos una forma de detectar que no está en modo de desarrollo, podríamos activar ese modo de error. Entonces realmente necesitamos una forma sólida de optar por un modo de desarrollo de forma permanente.

Similar a cómo se resaltan las configuraciones SSL problemáticas.

Este es exactamente el tipo de cosa que creo que sería perfecto. Los usuarios ya están acostumbrados a que los navegadores proporcionen información de seguridad sobre los sitios que visitan, la información de rendimiento no es un gran salto a partir de ahí. Además, sería consistente para todos los marcos/bibliotecas que informan posibles problemas de rendimiento y no interferiría directamente con el flujo de trabajo del usuario. 👍

Me gusta la idea del favicon: notable, funciona sin devtools o extensión, visible para todos, no daña a los usuarios, se puede animar para llamar la atención, lo suficientemente molesto como para hacer que los desarrolladores quieran desaparecer.

¿Qué hay de habilitar el modo DEV?
Nos equivocamos en el lado de la "buena UX", porque la DX mala es más fácil de notar (y en mi humilde opinión, para problemas como este, los usuarios deberían "ganar" porque no pueden elegir, mientras que los desarrolladores sí).
Estoy seguro de que algunos marcos ya hacen esto (como Relay, si no recuerdo mal).

Propuestas sobre cómo implementarlo:

• habilite el modo de desarrollo solo si NODE_ENV se establece explícitamente en development
• habilite el modo de desarrollo si el __DEV__ global es === true
• exportar un módulo de herramientas de depuración para habilitarlo en el espacio del usuario

El primero parece el mejor porque los otros dos pueden estar codificados sin protección (como una instrucción if(NODE_ENV === 'development') ) y, por lo tanto, enviarse a producción de todos modos.

@mattecapu Ver mi segundo comentario sobre. https://twitter.com/sebmarkbage/status/820047144677584896

Si hay una forma similar de hacer cumplir que los desarrolladores comiencen ejecutándose en modo DEV, entonces no importa cuál sea el valor predeterminado. Pero es realmente malo si te atrasas.

Hay mucho que comentar aquí, y tengo ideas, pero me gustaría opinar específicamente sobre la cuestión de cómo deshabilitar una advertencia de desarrollo.

No soy un gran admirador de un botón que desactiva una advertencia DOM durante un período de tiempo determinado en un navegador en particular. Como señala @jlongster , es un dolor para los desarrolladores si sucede con frecuencia. Pero lo que es más importante para mí, introduce una variabilidad específica del navegador en el comportamiento, lo que podría conducir fácilmente a la irreproducibilidad de los errores "pero funciona bien en mi máquina".

Preferiría que se envíe un parámetro para renderizar que enumere los dominios que se consideran cajas de desarrollo, con un valor predeterminado de ["localhost", "127.0.0.1"] . Se vería algo como esto:

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

Si el dominio actual está en la lista, la advertencia de desarrollo nunca aparece. De lo contrario, lo hace. Bajo este régimen:

• Usando la compilación de desarrollo en su máquina local usando localhost o 127.0.0.1 : nunca se advierte al desarrollador y no se necesita ninguna acción del desarrollador.
• Usando una compilación de desarrollo en una máquina de desarrollo con otro nombre de host : recibe la advertencia DOM hasta que agrega el nombre de dominio a la lista que se pasa a render . A partir de entonces, nunca recibe la advertencia DOM.
• Usando la compilación de desarrollo en una máquina de producción : recibe la advertencia de DOM hasta que cambia React a la versión de producción.

Lo único que me preocupa de esta solución es que podría llevar a los desarrolladores a dejar una lista de todos los dominios de su servidor de desarrollo en el código, y ese código podría llegar a producción. Para las empresas que consideran que sus dominios de servidores de desarrollo son secretos, eso sería un problema. ¿Pensamientos?

@aickin el problema con ese enfoque es que requiere que los usuarios conozcan la configuración y, a su vez, el problema que está resolviendo. El problema es que las personas no son conscientes de la distinción entre desarrollo y producción en primer lugar.

Editar : no importa, ya veo, todavía hay una advertencia de DOM en desarrollo.

Los entornos del lado del servidor solucionan esto al mostrar una página de error "especial" que incluye detalles de depuración y también le indica que no lo sirva en producción.

Dado que planeamos hacer que React "falle rápido" y desmonte las vistas a menos que proporcione un límite de error personalizado, también podríamos agregar un límite de error de "recuadro rojo" predeterminado en el desarrollo que actúe como una página educativa.

Luego, la primera vez que el usuario tenga un error en producción, verá un mensaje de error detallado especial. Esta podría ser una oportunidad para educar sobre la compilación DEV.

Pero siento que un banner en la parte inferior de la página que dice "Este sitio está en DevMode" sería una gran solución para esto que no tiene un gran impacto en la experiencia del usuario. Me gustaría entender por qué mucha gente piensa lo contrario.

A la mayoría de los usuarios no les gustan las aplicaciones web si saben que es una aplicación web, ¿por qué? Porque una mentalidad antes común de la web era que cuando aparece en la pantalla está hecho, no importa lo mal que se comporte y los usuarios han aprendido que la web es mala. Sin embargo, es perfectamente posible crear una gran UX en la web, pero para hacerlo debo tener el DOM. Si alguien inyecta banners aleatorios en lugares arbitrarios, el elemento incorrecto puede comenzar a desplazarse, o puede hacer que toda la pantalla se vuelva a pintar al desplazarse o puede interferir, por ejemplo, con gestos de arrastre u otra cosa. El punto es que, mientras esa pancarta esté activa, no puedo desarrollar porque no puedo saber que la experiencia es la misma cuando esa pancarta no está.

Como solución de marco, me gusta mucho la idea del favicon, no obstaculiza el desarrollo, no parece extraño para los usuarios, posiblemente no destruya la UX, pero se notará. Sin embargo, en realidad solo funciona para una sola biblioteca o marco en ese momento y no funciona en absoluto para bibliotecas que se ejecutan en trabajadores. La solución real es una buena manera de hacer esto a través del navegador que puede admitir múltiples marcos y bibliotecas y se puede acceder desde todos los contextos.

Otra solución que admite múltiples marcos y bibliotecas y es más clara, pero requiere una solicitud de permiso, es mostrar una notificación del navegador.

Aquí hay una idea: actualice los documentos de inicio en la página de inicio de Reaccionar para impulsar la creación de la aplicación Reaccionar con más fuerza. Y resalte la importancia de compilar npm en esos documentos. No necesitamos una advertencia DOM, necesitamos conciencia.

Creo que @ropilz se refirió a esto anteriormente en el hilo con su comentario "_...podríamos vincular cualquier servicio que queramos notificar a los desarrolladores..._", pero puede haber pasado desapercibido (o no reconocido).

Según tengo entendido, el problema fundamental que se resuelve aquí es

• para alertar de alguna manera a los _desarrolladores_ cuando los _usuarios finales_ de producción experimentan un sitio que se ejecuta en modo de desarrollo
• no podemos confiar en que los desarrolladores vean mensajes de console.log (o incluso advertencias DOM) en producción, _a menos que_ esos desarrolladores estén usando activamente el sitio de producción ellos mismos (o estamos confiando en los usuarios finales, QA/ equipos de soporte, etc. para informar estas advertencias al desarrollador)
• hay argumentos UX (válidos) _en contra_ que muestran a los usuarios finales una advertencia visible DOM que está destinada a las audiencias de desarrolladores.

¿Qué pasaría si hubiera algo análogo a report-uri de CSP, para que los marcos envíen advertencias de modo de desarrollo, en lugar de mostrar una advertencia in situ en el sitio donde serían visibles para los usuarios finales?

Obviamente, hay una serie de cosas a considerar, tales como:

1. Lo ideal sería que tales informes estuvieran ACTIVADOS de forma predeterminada, pero ¿cuál sería el report-uri predeterminado? (¿esperaríamos que cada marco albergue su propio servicio gratuito, similar a https://report-uri.io? (esto _puede_ ser posible para grandes marcos patrocinados por empresas como React y Angular; pero ciertamente poco práctico para marcos de código abierto más pequeños como Preact, Vue, etc.)
2. Una vez que se ha informado una advertencia, ¿cómo se notifica al propietario/desarrollador del sitio? (¿Quizás una buena manera para que los que no son desarrolladores se involucren en un proyecto, ofreciéndose como voluntarios para monitorear estos informes y ayudar a rastrear/notificar al mantenedor?)

Admito plenamente que esta sugerencia es solo una burbuja de pensamiento, y no he considerado cuán práctico sería o cómo funcionaría realmente; pero quería plantearlo porque me parece que el desafío de "informar sobre problemas de producción" ya se ha resuelto parcialmente para los informes de CSP/HPKP, y tal vez podríamos explorar algo similar aquí.

Es importante dar un paso atrás y darse cuenta de que React es un marco. No debes :

• Modifique el DOM para presentar algo visualmente como un recordatorio para los desarrolladores . No hay forma de que esto funcione bien desde el primer momento a menos que comprenda y desarrolle algo que pueda funcionar en todos los entornos sin obstaculizar a los desarrolladores y perder la confianza de sus usuarios en caso de que aparezca en producción (si mi experiencia es una indicación de que esto sucederá con bastante frecuencia y muchos no podrán implementar una solución rápida para apagarlo).

• Modificar el favicon. El favicon se almacena en caché de manera molesta, se usa para marcadores, se guardan íconos de aplicaciones web en dispositivos móviles si no se especifican otros, etc. Esto corre el riesgo de que una implementación de producción accidental (o intencional) en el modo de desarrollo borre el logotipo de una marca.

• Notificaciones del navegador. Cuando te miran, es probable que te mire un usuario. Aparecer una notificación solicitará permisos del navegador y aparecerán cosas extrañas que los usuarios no entenderán. La suposición de que estos serían vistos principalmente por los desarrolladores, en mi experiencia, es exactamente inversa y posiblemente arruine la confianza de los usuarios.

No es el trabajo de React cuidar a los desarrolladores. Propongo:

1. Active el modo de desarrollo. Cuando los desarrolladores se den cuenta de que no pueden depurar algo, buscarán cómo activarlo (que debe documentarse en todas partes ). No, no es trabajo de React decirles que lo apaguen. Su problema.

2. Déjalo en un simple mensaje de console.log (y esto debe ser deshabilitable). Deje que los desarrolladores lo encuentren y lo manejen. Si no lo hacen, bueno. No se puede llegar a todas las organizaciones y hacer que hagan las cosas correctamente. Simplemente no es escalable.

No estoy de acuerdo con tocar el DOM para mostrar una advertencia. Parece fácil y simple para React porque es una biblioteca DOM, pero imagina si todas las bibliotecas tienen que mostrar su propia advertencia en el DOM. Será un desastre total.

Hay tantas bibliotecas que usan los desarrolladores que probablemente tengan su propio modo de desarrollo. Creo que establecer process.env.NODE_ENV en production ya ha sido un estándar común en la agrupación de módulos para el navegador. Esto es lo que tenemos que mejorar la conciencia de.

Estoy de acuerdo en que React docs no muestra de manera destacada que existe una diferencia entre la compilación de desarrollo y producción. Cuando abre los documentos, debe consultar las Guías avanzadas para leer la diferencia entre la compilación de desarrollo y producción. El título es Optimización del rendimiento , algo que los principiantes definitivamente no verán porque usan React porque escucharon que es rápido. Creo que los documentos podrían mejorarse para tener otros documentos titulados "Uso de React en producción" o similar en la sección de Inicio rápido .

Los principiantes no suelen leer las Guías avanzadas, pero abrirán algunos enlaces en Inicio rápido si el título es lo suficientemente claro y parece importante. Sé que lo hice porque eso es lo que hago cuando empiezo a aprender React. No leí la guía de inicio, pero sí leí algunas páginas en la sección Inicio rápido.

Otro enfoque que podríamos tomar es mostrar una advertencia en la consola cuando React se usa en modo dev con un enlace para corregir ese punto en los documentos. Abrir la consola en producción para los desarrolladores es inusual, pero en un entorno local durante el desarrollo, seguramente abrirán la consola. De esta manera, al desarrollar localmente, sabrán que deben hacer algo antes de publicar en producción.

http://code.gov se lanzó a pesar de las advertencias de la consola. Este es exactamente el tipo de cosas que deberíamos tratar de prevenir. (Ese sitio es Angular, pero lo mismo se aplica a React)

Aquí está el problema de code.gov si alguien quiere comunicarse con ellos (o enviar un PR): 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.

Nunca antes había usado Angular 2 (lo que me convierte en principiante en este caso). Mi reacción inicial después de ver la advertencia es intentar llamar a enableProdMode() . no funciona Creo que el mensaje de la consola para el caso Angular podría mejorarse. En lugar de confiar en la magia, deberían señalar los documentos.

Al abrir los documentos de Angular, no veo nada sobre la compilación de producción. Creo que este es un problema tanto para Angular como para React. Ambos usan el modo de desarrollo, pero no le dicen a la gente por adelantado en los documentos cómo deshabilitarlo. Es por eso que mejorar los documentos podría contribuir en gran medida a educar a los desarrolladores.

No estoy en contra de mostrar una advertencia al usuario cuando los desarrolladores cometen "errores", pero inyectar algún elemento DOM aleatorio es simplemente intrusivo. Me encanta cómo los navegadores manejan el problema de HTTPS donde el navegador tiene una interfaz de usuario dedicada para mostrar que el sitio no es seguro. No tenemos uno para el estado relacionado con el rendimiento. Dadas las crecientes preocupaciones sobre el rendimiento web en general, no veo por qué el proveedor del navegador no encuentra formas de decirle al usuario que el sitio que está visitando apesta.

Esto debe abordarse a nivel de herramientas, por lo que posiblemente webpack y Babel puedan notificar a los desarrolladores sobre los beneficios de configurar un NODE_ENV.

@pveyes De acuerdo, le he dicho lo mismo al equipo de Angular.

@matthewp hay un problema mucho más antiguo sobre este https://github.com/presidential-innovation-fellows/code-gov-web/issues/129 y el equipo de Angular se comunicó directamente y les dio la solución: parece haber pocas ganas de aplicarlo. La pregunta es, ¿una advertencia DOM habría hecho que esta solución fuera más urgente o habría impedido que se iniciara en modo de desarrollo para empezar?

La pregunta es, ¿una advertencia DOM habría hecho que esta solución fuera más urgente o habría impedido que se iniciara en modo de desarrollo para empezar?

Lo más probable es que vean la advertencia en desarrollo, Google cómo deshabilitarla y deshabilitarla. Luego lo implementó en modo dev sin darse cuenta en el futuro porque lo olvidan. Durante el desarrollo, desea que se vea como producción, por lo que no puede insertar una parte aleatoria de DOM. Tampoco puede tener un control de calidad o un sistema de preparación que vea esto, ya que no sería indicativo de producción.

Entonces terminas con un montón de código basura que deshabilita esta cosa que arruina la experiencia de usuario del sitio. No es como si el ingeniero original que lo deshabilitó durante el desarrollo necesariamente recordaría tampoco; es posible que incluso se hayan mudado antes de que entrara en producción.

No estoy seguro de cómo funciona el proceso de implementación en code.gov, pero si se parece a lo que experimenté como contratista del gobierno, una implementación accidental del modo de desarrollo en producción sería:

1. Fuerce una reversión completa de toda la implementación (algunas de las cuales tardan 6 meses en obtener la aprobación y agrupar todo, desde cambios en la interfaz de usuario hasta actualizaciones de software del servidor), probablemente al día siguiente, luego tendrá reuniones y documentos de seguimiento sobre lo que sucedió y programar una nueva ventana de implementación (se le preguntará, una y otra vez, si los scripts o servicios de base de datos o lo que sea estaban en modo de desarrollo debido a una sola advertencia en la interfaz de usuario). He visto que esto sucede por cosas muy pequeñas. A veces puede obtener excepciones pero YMMV.

2. Los usuarios lo notarían, se corregiría, pero dado que es probable que no afecte la función, no se actualizará hasta la próxima ventana de implementación. Entonces todos los usuarios pueden verlo durante semanas o meses.

Al menos esa fue mi experiencia. El punto es que, incluso si se detecta una intrusión DOM inmediatamente después de la implementación, no sabe cómo es su infraestructura/proceso y es posible que no sea algo que puedan solucionar de inmediato (aunque deberían poder hacerlo).

Los mensajes de advertencia serán más evidentes cuando se fusione #7360 (cuadro amarillo). También podríamos agregar un mensaje al cuadro amarillo (¿llamarlo "Advertencias del modo de desarrollo de reacción"?).

Al abrir los documentos de Angular, no veo nada sobre la compilación de producción. Creo que este es un problema tanto para Angular como para React. Ambos usan el modo de desarrollo, pero no le dicen a la gente por adelantado en los documentos cómo deshabilitarlo. Es por eso que mejorar los documentos podría contribuir en gran medida a educar a los desarrolladores.

Está justo en la página de Instalación:

https://facebook.github.io/react/docs/installation.html#desarrollo-y-versiones-de-producción

Y sobre la optimización del rendimiento:

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

No creo que sea justo decir que los médicos no son sinceros al respecto.

Cuando abre los documentos, debe consultar las Guías avanzadas para leer la diferencia entre la compilación de desarrollo y producción. El título es Optimización del rendimiento, algo que los principiantes definitivamente no verán porque usan React porque escucharon que es rápido. Creo que los documentos podrían mejorarse para tener otros documentos titulados "Uso de React en producción" o similar en la sección de Inicio rápido.

Está justo ahí, en la primera página (Instalación):

https://facebook.github.io/react/docs/installation.html#desarrollo-y-versiones-de-producción

Estás bien. Disculpa, me equivoque. Asumí que la compilación de producción está en una sección diferente, así que no busqué allí y busqué un título relevante en la barra lateral (y encontré la página Optimización del rendimiento). Debería haberlo sabido mejor.

Realmente no soy un principiante en React, es por eso que cuando abro los documentos para verificar mi suposición, que los documentos de React no son directos sobre producción vs desarrollo, no abrí los documentos de instalación 🙇

No hay problema. Si no es lo suficientemente visible, estoy abierto a sugerencias para una mejor ubicación. Por ejemplo, podríamos hacer una página dedicada para ello ( Deploying to Production ).

No olvidemos que este tema es un tema importante a resolver pero no el tema más importante a destacar. Tampoco estoy convencido de que sea suficiente incluso si se destaca en la primera página porque la gente lo verá y navegará, se olvidará y pensará "Sé lo que estoy haciendo". Así que no me volvería loco en lo de los documentos.

La única forma real de abordarlo es detectando y notificando.

@KrisSiegel El favicon que se almacena en caché es un buen punto. Me pregunto si deberíamos cambiarlo después de un segundo o dos y luego volverlo a girar brevemente cada pocos segundos. De esa manera, es muy poco probable que el problema del almacenamiento en caché y los marcadores se cronometre en el momento del icono anulado.

Pensé que las manipulaciones de JS a favicon no se almacenan en caché, pero tal vez me equivoque.

Yo diría que el lugar correcto para tener ganchos para esto no es Chrome o Firefox, sino webpack, Browserify o Rollup.

Construir lo que pretende ser un paquete de producción para React pero sin habilitar el modo de producción es solo eso: un error de construcción. Creo que la razón por la que no hay acuerdo sobre cómo presentar esto en tiempo de ejecución refleja que este no es un problema que deba manejarse en tiempo de ejecución.

@taion Estoy de acuerdo. Creo que esto definitivamente pertenece a la herramienta de compilación, no al DOM.

Creo que debería ser el lugar de las herramientas de compilación para asumir que el entorno del nodo debe establecerse en producción para el código de producción. Puede que no sea necesario para todos los proyectos, pero creo que es una buena suposición.

Si npm run build se ejecuta en la terminal y el env no está configurado para producción, debería recibir una advertencia roja en la terminal junto con la salida predeterminada: env is not set to production, some scripts may be in development mode

Actualmente no recibo tal advertencia de webpack.

Editar: aclaración agregada

O simplemente configure NODE_ENV para usted, de verdad.

Si las advertencias de la consola no funcionan, no estoy seguro de que lo hagan las advertencias de compilación.

La compilación debería configurar las cosas por usted o fallar si está mal configurada para la producción. Al menos para React, esto _es_ un indicador de tiempo de compilación.

@jakearchibald Estoy seguro de que algunos aún lo ignorarán, pero al menos se les mostrará la advertencia cuando lo construyan, en lugar de no ser visto porque la advertencia está oculta en la consola del navegador que es posible que nunca abran en producción. . Lo que es más importante, les da a aquellos con menos experiencia una pista sobre lo que deberían hacer para preparar la producción del código.

Si bien muchos desarrolladores actualizarán las bibliotecas, es común no actualizar el paquete web y, en general, las herramientas, porque muchas personas asumen que simplemente funciona, y puede ser una molestia actualizar el paquete web y compañía.

Construir lo que pretende ser un paquete de producción para React pero sin habilitar el modo de producción es solo eso: un error de construcción.

El uso de una versión preempaquetada de React desde una CDN también es una configuración admitida , pero no hay ningún paso de compilación en ese flujo de trabajo. Por lo tanto, una solución a este problema que solo se centre en la compilación ignoraría el caso de uso de CDN.

Sinceramente, no estoy seguro de cómo me siento al respecto; Puedo ver argumentos tanto a favor como en contra de tener advertencias de desarrollo para el uso de React CDN.

@taion Como alguien que admite una solución de solo compilación, ¿cree que este es un caso de uso importante para cubrir?

¿Qué piensan otras personas?

Creo que la documentación allí es bastante clara de que debe usar los paquetes .min.js para la producción. Tal vez podría usar negrita, un tamaño de fuente más grande, algo así. Pero si alguien está usando el paquete React sin minimizar en producción para su sitio web, de todos modos tiene otros problemas.

Creo que la documentación allí es bastante clara de que debe usar los paquetes .min.js para la producción.

De acuerdo, pero la página también es bastante clara sobre cómo configurar su herramienta de compilación para producción si incluye React como un paquete npm. Creo que el objetivo de este problema era tratar de crear un pozo de éxito para las personas que no leen detenidamente esa página de documentación.

Sin embargo, parece que no está de acuerdo y que cree que usar la compilación de desarrollo de la CDN no es un caso importante para prevenir con una advertencia de desarrollo más agresiva. ¿Es ese un resumen justo de su posición, o me estoy perdiendo algunos matices?

Creo que la configuración de CDN+dev es más obviamente incorrecta, ya que requiere que el usuario use una versión no minimizada de React. Es más difícil fallar de esta manera porque la carga de conocimiento requerida para _solo usar la compilación minimizada_ es menor.

La configuración en la que _piensas_ que las cosas están listas para producción porque ejecutó minificación en webpack o Browserify, pero en realidad no lo está porque no configuró NODE_ENV ; no puede obtener eso a través de los paquetes de CDN.

Creo que la pestaña React en Chrome Developer Tools es suficiente para saber si estamos en DEV Mode .

Creo que vale la pena señalar que existe un precedente para un marco que inyecta un elemento DOM en la página en modo de desarrollo:

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

Aunque por lo que puedo decir, no creo que esto esté activado de forma predeterminada.

Siguiendo la discusión anterior, parece haber un objetivo general para lograr una solución perfecta que satisfaga todas las restricciones pero impida de manera confiable que todos se ejecuten en modo de desarrollo cuando no deberían hacerlo. El OP declaró que tendría que haber una compensación entre las experiencias potenciales para los desarrolladores y los usuarios, y creo que este es el caso.

Para intentar volver a plantear el problema un poco:

• Un número distinto de cero de sitios React llegan a producción sin el modo de desarrollo deshabilitado
• Nos gustaría reducir este número.
• No queremos molestar a los desarrolladores de React.
• No queremos desanimar a los recién llegados a React
• No queremos que los usuarios finales de sitios creados en React vean advertencias crípticas para desarrolladores.
• No queremos romper sitios debido a la presencia de elementos DOM extranjeros

Dado esto, creo que un primer paso decente sería que React en modo de desarrollo anuncie que está en modo de desarrollo a través de console.warn o console.info con instrucciones para asegurarse de que esté deshabilitado para la producción. despliegue.

Claro, esto no atrapará a todos, pero _es un comienzo decente_ que debería reducir la cantidad de personas que envían inadvertidamente a producción y no cierra ninguna puerta para futuras mejoras.

Dado esto, creo que un primer paso decente sería que React en modo dev anuncie que está en modo dev a través de console.warn o console.info con instrucciones para asegurarse de que esté deshabilitado para la implementación de producción.

Sin embargo, no está mal que esté en modo de desarrollo cuando estás... desarrollando. ¿Qué otras heurísticas podríamos usar?

Además, dado que nadie lee la consola en producción, me pregunto si podríamos agregar un tiempo de espera para que se registre si usa soluciones de informes de fallas.

Sin embargo, no está mal que esté en modo de desarrollo cuando estás... desarrollando. ¿Qué otras heurísticas podríamos usar?

Creo que debería ser similar al aviso actual de React DevTools

Un mensaje informativo que le recuerda que está en modo de desarrollo y que el modo de desarrollo debe estar deshabilitado para los sitios de producción. Esto (en teoría) debería hacer que más desarrolladores se den cuenta de que hay una distinción y se deben tomar algunas medidas para prepararse para el uso de producción.

Como dices, casi nadie verá una advertencia de consola en la producción real, y en ese momento es un poco tarde.

Lamento sonar como un registro atascado, pero las advertencias de la consola no parecen funcionar. Por ejemplo , https://code.gov.

Lamento sonar como un registro atascado, pero las advertencias de la consola no parecen funcionar. Por ejemplo , https://code.gov.

Un solo contraejemplo muestra que no es infalible, pero no creo que ningún enfoque lo sea.

Si una advertencia de la consola puede aumentar la conciencia y reducir la cantidad de personas que ejecutan el modo de desarrollo por error cuando no deberían, entonces esto parece un paso en la dirección correcta. Lo perfecto es enemigo de lo bueno.

@jakearchibald

Sí, pero si la herramienta de compilación de code.gov se configuró con ganchos aquí, eso _habría_ evitado el problema que está observando, al menos en el contexto de React que usa ganchos de tiempo de compilación para esto. Están usando webpack después de todo.

No digo que el paquete web deba emitir una advertencia de compilación. Estoy diciendo que la solución correcta es que el paquete web establezca process.NODE_ENV para usted, o que el paquete web simplemente falle en la compilación de forma predeterminada si intenta hacer una compilación de producción sin la configuración de producción adecuada.

Quería responder rápidamente a un punto anterior de @addyosmani sobre las "violaciones" de DevTools. Estamos creando prototipos que muestran indicaciones más sólidas de ciertos errores en Chrome DevTools, pero este trabajo aún es bastante temprano, y tiendo a estar de acuerdo con @jakearchibald en que mostrar una advertencia (incluso si da más miedo que console.warn ) no es una solución suficientemente buena.

¿Qué pasa con la configuración predeterminada de React en el modo de producción y la activación del modo de desarrollo si y solo si NODE_ENV == 'development' o el nombre de host es localhost / 127.0.0.1 ? La mayoría de los desarrolladores obtendrán el comportamiento correcto listo para usar y siempre habrá una manera de forzar manualmente el modo de desarrollo si realmente lo necesita.

Parece menos que ideal seguir golpeando esa rama con lo que podría ser un condicional bastante complicado (ya que no solo necesitaría fallar en Node) todo el tiempo.

Por cierto, -p (modo "producción", que también permite la minificación con la configuración predeterminada) en webpack 2 establece NODE_ENV para usuarios: https://webpack.js.org/guides/production-build /#nodo -variable-de-entorno.

Esto me parece bastante sensato, y debería evitar este problema para casi todos los que usan webpack. ¿Por qué la insistencia en manejar algo de esto en tiempo de ejecución?

Por cierto, -p (modo "producción", que también permite la minificación con la configuración predeterminada) en webpack 2 establece NODE_ENV para los usuarios: https://webpack.js.org/guides/production-build/#node -environment-variable.

Sí. Somos conscientes de esto. @TheLarkInn del núcleo de Webpack podría confirmarlo con seguridad, pero tengo entendido que -p no se usa mucho en el cajero automático de la comunidad de Webpack. El problema subyacente aquí también es que si alguna solución es opcional, similar al status quo actual con las advertencias de console.log, es poco probable que veamos un cambio real para los usuarios de React. Queremos dar a la gente un mejor cambio en el envío de la cosa 'rápida'.

Vale la pena mencionar de pasada que la falta de capacidad para detectar fácilmente los entornos DEV y PROD en Webpack (-p es insuficiente) también nos causó algunos problemas en https://github.com/webpack/webpack/issues/3216.

Estoy diciendo que la solución correcta es que webpack establezca process.NODE_ENV para usted, o que webpack simplemente falle en la compilación de forma predeterminada si intenta hacer una compilación de producción sin la configuración de producción adecuada.

Estoy dispuesto a que persigamos esto, pero sería un cambio radical para Webpack por lo que puedo decir. Personalmente, siento que una solución de tiempo de ejecución que involucre un mensaje de superposición claro _solo_ mostrado usando algunas heurísticas inteligentes (localhost, DevTools abierto, etc.) nos cubriría adecuadamente.

Dicho esto, a medida que seguimos volviendo al elemento webpack process.NODE_ENV, me gustaría saber si @sokra o @TheLarkInn tienen alguna opinión sobre este.

Mi comprensión difiere de la suya allí: creo que -p es la forma de facto en que la mayoría de los usuarios no expertos de webpack configuran compilaciones de producción.

Incluso los paquetes destacados usan -p para generar compilaciones de producción:
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 bastante poco común configurar directamente el complemento Uglify en el paquete web, por lo que sin -p , las personas estarían usando compilaciones no minimizadas, en cuyo caso tienen problemas mayores.

Personalmente, siento que una solución de tiempo de ejecución que involucre un mensaje de superposición claro que solo se muestre usando algunas heurísticas inteligentes (localhost, DevTools open, etc.) nos cubriría adecuadamente.

Siento que esto ha sido derribado varias veces ("Es inaceptable que un marco inyecte cosas en el DOM") sin apreciar realmente el _único_ escenario en el que esto sucedería.

Estoy totalmente de acuerdo con ustedes en que tener que lidiar con un mensaje permanente y cosas inesperadas en el DOM constantemente durante el desarrollo es inaceptable. Sin embargo, lo que sugerimos aquí es un mensaje que se muestra si y _solo_ si DevMode se implementa en producción (¡ingrese heurística!). Se puede incorporar una cantidad arbitraria de comprobaciones y mensajes de consola en herramientas, CI y extensiones de navegador para evitar que eso suceda.

Pero como un último recurso desesperado a prueba de fallas, creo que un banner visible en la pantalla es una solución buena y apropiada.

se muestra si y solo si DevMode se implementa en producción (¡ingrese la heurística!)

Entonces, un desarrollador nunca verá este mensaje, implementará (quizás accidentalmente) el modo de desarrollo en producción y, de repente, verá que este nuevo HTML se muestra en su aplicación para que todos sus usuarios lo vean.

Eso suena más como un castigo para mí. Si aún no comprende el modo de desarrollo e implementa con esta nueva versión teórica de React con el mensaje, obtendrá una sorpresa y sus usuarios en la aplicación web en ese momento también podrán verlo. No veo cómo esto ayuda a nadie, pero sirve para avergonzar al desarrollador o la empresa. Claro, tal vez eso haga que lo arreglen, pero ese costo es demasiado alto en mi opinión y le falta un poco de empatía.

Pero como un último recurso desesperado a prueba de fallas, creo que un banner visible en la pantalla es una solución buena y apropiada.

El problema con esta solución es que es demasiado idealista y cuando está desarrollando un marco debe centrarse en la realidad de que otras empresas pueden no tener las mejores políticas de implementación o incluso el mejor control de calidad (si lo hay).

Sí, si alguien implementa el modo de desarrollo en producción, debería poder verlo y cambiarlo rápidamente. Desafortunadamente, especialmente fuera de la industria de la tecnología, esto simplemente no es posible o no es fácil . ¿La mayoría de las personas que comentan aquí? Es probable que sus empresas tengan procesos de implementación que podrían hacer frente sin problemas a este escenario. Google, Facebook, PlayStation, etc.; todas estas empresas de tecnología pueden manejar esta multa, pero esto no es representativo de la mayoría de los usuarios que usan React, ¿verdad? (en realidad, ¿tenemos alguna estadística sobre el uso de React? ¡Sería útil!)

Sí, sí, estas empresas y el gobierno deberían cambiar sus procesos y políticas de implementación, etc., etc. Pero la realidad es esta: la mayoría de las empresas tienen procesos de implementación deficientes y control de calidad inexistente.

Tomemos dos escenarios en los que he experimentado personalmente.

Primero , mientras trabaja en el gobierno, dependiendo de la rama y el departamento, es probable que tenga una sola implementación cada 3 a 6 meses. Estas implementaciones acumulan la mayor cantidad de cosas posible y, si falla alguna parte de la implementación completa, es posible que todo se revierta. Entonces, estábamos usando este software llamado OWF que, si no está familiarizado, es como iSocial en el sentido de que muestra múltiples aplicaciones web en una sola aplicación web usando iframes (asqueroso, lo sé, pero quédese conmigo aquí). Hubo un paso de configuración manual en la implementación de varias de nuestras aplicaciones que falló, lo que provocó que se mostraran errores 404 y 500 en algunos de los iframes en lugar de la aplicación prevista.

Dado que los desarrolladores generalmente no tienen acceso al sistema que se está implementando, pasaron muchas horas antes de que descubriéramos cualquier problema. En ese momento, tuvimos que hacer que nuestro jefe llamara al jefe de otra persona para que llamara a su jefe y les dijera que no afectaba nada más para que no revirtieran todo el despliegue. Luego tuvimos toneladas de papeleo y documentación que completar antes de que pudiéramos hacer que alguien rehaciera parte de la configuración varios días después. Mientras tanto, la aplicación se sentó, incapaz de funcionar, durante todo ese período de tiempo.

En segundo lugar , cuando trabajé en finanzas, tuvimos una implementación que inadvertidamente incluía el nombre de un desarrollador en lugar del diseño de un elemento real en el sitio web (¿creo que estaba probando algo?). De todos modos, se notó de inmediato, pero para solucionarlo tuvimos que obtener un control de cambios de emergencia que se prolongó hasta mucho más tarde ese día. Entonces, sus clientes tuvieron que ver este estúpido banner durante casi 8 horas completas antes de que se arreglara.

Mi punto es: se debe tener mucho cuidado al inyectar elementos arbitrarios en el DOM que el desarrollador no colocó allí. Especialmente si estamos hablando de mostrarlo solo en algunos escenarios, la primera vez que alguien lo vea, descubrirá cómo deshabilitarlo rápidamente para que no tenga que volver a molestarlo.

@KrisSiegel

Si aún no comprende el modo de desarrollo e implementa con esta nueva versión teórica de React con el mensaje, obtendrá una sorpresa y sus usuarios en la aplicación web en ese momento también podrán verlo.

Tenía curiosidad por saber si sus pensamientos sobre el enfoque eran diferentes si el mensaje solo se mostraba mientras DevTools estaba abierto (es decir, algo que tendría pocas posibilidades de ser visto por usuarios de producción que no son desarrolladores). Efectivamente, una expansión de la estrategia actual de console.log que React ya emplea hoy.

Tenía curiosidad por saber si sus pensamientos sobre el enfoque eran diferentes si el mensaje solo se mostraba mientras DevTools estaba abierto (es decir, algo que tendría pocas posibilidades de ser visto por usuarios de producción que no son desarrolladores). Efectivamente, una expansión de la estrategia actual de console.log que React ya emplea hoy.

Si tiene herramientas de desarrollo abiertas, probablemente esté viendo mensajes de console.log, por lo que los cambios de DOM parecen una complejidad innecesaria para administrar, además de que es redundante. Siempre puede hacer que los mensajes de la consola de React sean más grandes o más elegantes. Tal vez un logotipo ASCII React. Algo para llamar la atención de alguien en caso de que entre allí.

En última instancia, aunque creo que alguien se encontraría con esto, pregunte en Stackoverflow cómo deshabilitar la advertencia, alguien publicará un código que les muestra cómo hacerlo, luego las personas simplemente lo deshabilitarán si se topan con él. Las herramientas de compilación son numerosas y muchas personas con las que he hablado en el pasado las encontraron confusas o difíciles (el lanzamiento de Babel 6 fue un momento "divertido"). Te encontrarás con mucha gente que simplemente nunca los usa correctamente.

Al menos esa es mi experiencia ¯\_(ツ)_/¯

Uf, finalmente alcanzó el final del hilo. Bueno. He estado pensando en esto un poco.

Webpack podría obligar a especificar NODE_ENV que React podría usar para evitar más fácilmente que la gente envíe DEV a PROD, pero eso sería un cambio importante para Webpack. Estoy hablando con Sean ahora sobre cuán factible podría ser algo así para Webpack 3. Mantener la pila de React + Webpack para principiantes y fácil de usar es algo que les importa a ambos campos.

Este se ha sentido como mi favorito hasta ahora, pero aún no estoy 100% vendido.

1. Por lo tanto, podría imponer que se pase un ENV cada vez que alguien ejecute un paquete web. Un mensaje de error útil indica que debe proporcionar una variable env para ejecutar webpack.

Sin embargo, esto proporciona un punto de rebote significativo para los usuarios. No todos escriben para un entorno de producción o desarrollo, ni siquiera saben qué es un entorno. Plantearé un problema sobre webpack/webpack para obtener comentarios al respecto, porque mi intuición es que no todos querrán esto y, ya sea que esté de acuerdo o no, tenemos que considerar el retroceso.

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

2. La solución webpacky sería crear un complemento independiente que pudiera conectarse al ciclo de vida del compilador, verificar si el código se está eliminando o si no se proporciona un ENV, y emitir una advertencia amigable o un error de su elección.

Sin embargo, me imagino que la respuesta es "Pero los usuarios nunca sabrán cómo hacer eso, etc." Por lo tanto CRA, por lo tanto este tema en este momento.

Podríamos crear un nuevo patrón de resolución que verifique el paquete.json de React (o cualquier fw que lo necesite) para algo como lo siguiente:

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

eso se aplicaría automáticamente a la configuración del compilador de un usuario sin que ellos necesiten saberlo o preocuparse.

Una vez más, simplemente una lluvia de ideas.

@TheLarkInn Creo que el comportamiento actual de -p en el paquete web 2 es suficiente, ¿no? El único caso de falla es si alguien configura UglifyJsPlugin y se olvida de hacer DefinePlugin , pero parece un caso mucho menos probable.

@taion Sí/No

-p solo aplica "tratamientos" de producción a su código, sin embargo, no hacemos suposiciones ni tenemos conocimiento de lo que se establece en NODE_ENV . Esto es lo que genera la necesidad de que las personas usen DefinePlugin() .

Pero creo que es el área "_razonable_" más cercana a _adivinar_ o _implicar_ que el usuario está ejecutando su código en un ENV de producción. Esa sería el área en la que nos gustaría asegurarnos de que la comunidad y el equipo estén de acuerdo.

@TheLarkInn Creo que esto cambió en v2: https://webpack.js.org/guides/production-build/#node -environment-variable

Ah, lo siento, es cierto, me equivoqué. Sin embargo, no se usa con frecuencia porque las personas quieren un control más detallado sobre lo que optimizan. (Como mencionó @addyosmani )

¿Es eso realmente tan común? Cuando comencé con el paquete web, -p claramente parecía ser el camino a seguir. Como mencioné anteriormente, incluso las bibliotecas con muchas razones para aplicar ajustes adicionales aún usan -p .

Podríamos crear un nuevo patrón de resolución que verifique el paquete.json de React (o cualquier fw que lo necesite) para algo como lo siguiente:

"paquete web": {
"plugin": "ReactEnviornmentPlugin"
}
eso se aplicaría automáticamente a la configuración del compilador de un usuario sin que ellos necesiten saberlo o preocuparse.

@TheLarkInn si estoy leyendo esto correctamente, para activar el patrón de resolución, el paquete. json de una aplicación necesitaría especificar manualmente el ReactEnvironmentPlugin , ¿verdad? ¿O estoy malinterpretando la propuesta? :)

Podría imaginar alguna magia de resolución en Webpack que detecta que un proyecto está usando React y hace el cambio de entorno correcto para ellos, pero eso suena como un acoplamiento estrecho de optimización específica del marco a un paquete y podría no ser tan deseable.

Menos que detectaría reaccionar, y más que detectaría que los campos de descripción de módulos js incluyen un campo de paquete web con un complemento. Pero tienes razón, está muy estrechamente acoplado y tampoco es mi idea favorita.

No creo que esto realmente le brinde ninguna garantía a menos que el paquete web tenga un concepto de modo de "producción" para descubrir cómo configurar React, y esto parece redundante dado que, como se discutió anteriormente, -p ya hace lo correcto cosa, y es lo que los usuarios generalmente buscarán cuando hagan una compilación de producción minimizada con webpack de todos modos.

Hemos hablado un poco más sobre esto y creo que hay una solución razonable.

Durante mucho tiempo hemos considerado habilitar un "cuadro de advertencia" para las advertencias de React en desarrollo. Puede ver una demostración aquí (PR: https://github.com/facebook/react/pull/7360). Solo aparece cuando tiene advertencias, pero son muy comunes durante el desarrollo (y siempre deben corregirse), por lo que, presumiblemente, cualquier persona que haya pasado más de cinco minutos desarrollando una aplicación verá el cuadro de diálogo y sabrá que existe.

Después de este cambio, será más difícil no estar al tanto del modo de desarrollo. Es probable que busque "cómo eliminar el cuadro de diálogo de advertencia" y aprenda a construir para la producción. Si no lo hace, es probable que reciba algunas advertencias en algún momento y sus usuarios las verán. Creo que, en este caso, la gente no culpará a React per se porque no solo mostramos que la caja es desagradable, solo hacemos lo que se supone que debe hacer el modo de desarrollo.

(Por cierto, hemos estado usando un cuadro de advertencia similar en desarrollo en Facebook durante mucho tiempo, por lo que corresponde a cómo pretendemos usar React).

¡Estoy muy feliz de ver esa propuesta, @gaearon! Es todo lo que soñé que sería ;)

Solo como un complemento: tal vez valga la pena considerar tener un enlace directamente en el cuadro para no requerir que los desarrolladores busquen en Google cómo deshacerse de él.

Sí, buen punto. Añadiremos algo.

@gaearon Encuentro esa solución muy desagradable; Nunca querría que las advertencias invadieran el DOM, incluso durante el desarrollo. Eso no tiene ningún propósito para el desarrollador común y probablemente la mayoría lo deshabilite por completo. Las herramientas de desarrollo muestran advertencias por una razón, no es necesario inventarlas.

También me preocupa que las soluciones DOM sigan apareciendo sin refutaciones a ninguno de mis argumentos anteriores en contra. Si se van a ignorar mis puntos, está bien, este no es mi repositorio, así que es justo, pero es desalentador ver que surge el mismo argumento, la gente publica en contra, la gente parece estar a favor de los puntos, ya que nunca hay un argumento en su contra. , luego simplemente vuelven a subir. Enjuague, repita.

Si bien estoy de acuerdo en que esto es cierto sobre la mayoría de las advertencias, las advertencias de React señalan específicamente los errores en su código. No son solo sugerencias.

El cuadro de diálogo es fácil de descartar y las advertencias individuales son fáciles de posponer (en caso de que no te interesen por un tiempo), pero deben corregirse.

A modo de comparación, así es como se ve el cuadro de diálogo en la base de código de Facebook:

Miles de ingenieros no tienen ningún problema con él y son más productivos gracias a él, por lo que creemos que es un valor predeterminado razonable. Para ser claros, la versión de código abierto será menos gritadora:

Si tiene sugerencias sobre ajustes de estilo, no dude en comentar en https://github.com/facebook/react/pull/7360.

Agregando a lo que dijo Dan, estoy construyendo sobre el #7360 para conectar con nuestro flujo de registro de errores agregado recientemente. Actualmente estoy probando un par de estilos de notificaciones de brindis que son un poco menos intrusivas. Publicaré algunas capturas de pantalla y/o un Plnkr pronto para recibir comentarios.

¿Estas advertencias incluirían la advertencia de "código de desarrollo minimizado"? Eso resolvería muchas cosas bastante bien si es así.

No veo por qué no podría usarse también para ese propósito.

@gaearon

Si bien estoy de acuerdo en que esto es cierto sobre la mayoría de las advertencias, las advertencias de React señalan específicamente los errores en su código. No son solo sugerencias.

Esos deberían ser errores o excepciones en mi opinión. ¿Por qué no lo son? Las excepciones obligan a que se corrijan las cosas, pero una advertencia descartable no.

Miles de ingenieros no tienen ningún problema con él y son más productivos gracias a él, por lo que creemos que es un valor predeterminado razonable.

Mencioné esto en un punto anterior, pero supongo que esos ingenieros probablemente sean mejores que un buen 90% de las personas que usarán la versión de código abierto. Me parece lo contrario de un valor predeterminado razonable. Hay una razón por la cual las herramientas de desarrollo tienen advertencias; reinventarlos no tiene sentido para mí. Se desactivará y nunca se volverá a ver.

Parece que React está tratando de hacer demasiado en mi opinión.

Cuando hice contratos con el gobierno, teníamos una biblioteca común que todos los front-end tenían que usar. Tomaría errores en la consola y los mostraría como una ventana emergente de brindis. No solo se implementó en producción varias veces por varios equipos, sino que muchos desarrolladores lo vieron una vez y luego preguntaron cómo desactivarlo permanentemente. Veo esto como más de lo mismo.

Durante mucho tiempo hemos considerado habilitar un "cuadro de advertencia" para las advertencias de React en desarrollo. Puede ver una demostración aquí (PR: #7360). Solo aparece cuando tiene advertencias, pero son muy comunes durante el desarrollo (y siempre deben corregirse), por lo que, presumiblemente, cualquier persona que haya pasado más de cinco minutos desarrollando una aplicación verá el cuadro de diálogo y sabrá que existe.

Me gusta mucho #7360, @gaearon. Es alentador escuchar apoyo para resaltar la necesidad de cambiar a PROD para implementaciones en el nuevo cuadro de advertencia. Es agradable y visual.

Agregando a lo que dijo Dan, estoy construyendo sobre el #7360 para conectar con nuestro flujo de registro de errores agregado recientemente. Actualmente estoy probando un par de estilos de notificaciones de brindis que son un poco menos intrusivas. Publicaré algunas capturas de pantalla y/o un Plnkr pronto para recibir comentarios.

@bvaughn Espero ver más de sus iteraciones :)

Para las personas que sienten que el enfoque del cuadro de advertencia puede ser demasiado intrusivo, otras bibliotecas (por ejemplo, VueJS) ya muestran superposiciones de DOM durante su flujo de trabajo de desarrollo/iteración para alentar la corrección de errores o caminos lentos:

Mi propia experiencia ha sido que, si bien es un inconveniente menor, estos mensajes son más obvios de lo que podría ver en la consola. Creo que Dan tiene razón en que al menos pondrá más énfasis en que el modo de desarrollo no es algo que deba implementar para producir y, con suerte, conducirá a que más sitios envíen el "modo más rápido" a sus usuarios finales.

Después de este cambio, será más difícil no estar al tanto del modo de desarrollo. Es probable que busque "cómo eliminar el cuadro de diálogo de advertencia" y aprenda a construir para la producción. Si no lo hace, es probable que reciba algunas advertencias en algún momento y sus usuarios las verán. Creo que, en este caso, la gente no culpará a React per se porque no solo mostramos que la caja es desagradable, solo hacemos lo que se supone que debe hacer el modo de desarrollo.

Esos deberían ser errores o excepciones en mi opinión. ¿Por qué no lo son? Las excepciones obligan a que se corrijan las cosas, pero una advertencia descartable no.

Si bien deberían arreglarse, es posible que tenga asuntos más urgentes a mano. Por ejemplo, a menudo hago prototipos/simulacros de interfaces de usuario y, mientras lo hago, escribo un código rápido y, por lo general, deficiente sobre el que React puede advertir. Si bien quiero arreglar esas advertencias, realmente no me importa hasta que sepa que no desecharé todo el código en la próxima hora al menos. Obligar a las personas a repararlos instantáneamente ralentizará drásticamente el desarrollo experimental.

Para las personas que sienten que el enfoque del cuadro de advertencia puede ser demasiado intrusivo, otras bibliotecas (por ejemplo, VueJS) ya muestran superposiciones de DOM durante su flujo de trabajo de desarrollo/iteración para alentar la corrección de errores o caminos lentos:

captura de pantalla 2017-01-24 a las 10 57 11 am

¿Estás seguro de que es de Vue? Se parece mucho a los errores de compilación de paquetes web que se muestran con la superposición de errores de webpack-hot-middleware . Si este es el caso, es sutilmente diferente porque se trata de herramientas de compilación en tiempo de desarrollo que agregan la superposición en lugar de un marco de interfaz de propósito general.

En general, estoy a favor de la superposición de advertencia, pero creo que debería contener un texto explicativo que diga qué es, por qué está allí y que puede y debe desactivarse como parte de desactivar el modo de desarrollo. Detrás de un expando si eso es un poco largo, pero parece un lugar tan bueno como cualquier otro para transmitir el mensaje.

Temo actualizaciones como 15.2.0 con una superposición. un pequeño golpe y de repente tienes literalmente cientos de advertencias sobre accesorios que se pasan a los nodos DOM. errores tal vez, pero no creo que las advertencias de depreciación pertenezcan a un espacio tan intrusivo

errores tal vez, pero no creo que las advertencias de depreciación pertenezcan a un espacio tan intrusivo

No sé si esto se comunicó muy claramente antes, pero la idea con respecto a las advertencias de cuadro amarillo (# 7360) era no mostrar _todas_ las advertencias (desaprobación u otras). Más bien, ciertas advertencias que el equipo consideró _particularmente importantes_ se resaltarían de esta manera. El resto presumiblemente permanecería en la consola.

Al menos esa es mi conclusión de la conversación que Tom y yo tuvimos sobre esta función hace una semana o dos.

La advertencia de accesorios en 15.2 también fue un error en mi opinión y no es indicativo de nuestro MO normal. Nos gustaría tener una forma de controlar los niveles de advertencia por versiones menores para evitar eso.

La razón principal por la que nuestro equipo no usa la compilación de producción es porque no podemos ejecutar pruebas unitarias de JS, ya que las utilidades de prueba no están incluidas.

Primero, otra ronda de agradecimiento al equipo de React ( @sebmarkbage , @gaearon , @tomocchino y otros) por hablar sobre este tema con nosotros y mostrarse tan abiertos a hablarnos sobre rendimiento y dispositivos móviles en BlinkOn y otras sincronizaciones este trimestre.

Comprobación del estado

Según @aweary en https://github.com/facebook/react/pull/7360 , la solución de Yellow Box para este problema en particular se ha suspendido hasta que se complete el trabajo V16 de alta prioridad de React, pero aún debería estar ocurriendo. https://github.com/facebook/fbjs/pull/165 necesita aterrizar e implementarse en Fiber. También se debe diseñar una buena API pública para exponer ganchos. Mantendré mis dedos 🤞

Este problema parece seguir siendo frecuente

Algunas de las aplicaciones de producción que han llegado a mi escritorio todavía están enviando el modo DEV a producción. Podemos ver la cadena de depuración When deploying React apps to production en sus compilaciones aquí:

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)

Todavía soy de la opinión de que un movimiento previo a Yellow Box para registrar la advertencia del modo DEV en la consola para lo anterior podría tener algún impacto. La sugerencia de Sebastian de arrojar un error de consola para que los informes de fallas puedan detectarlos también fue algo que sentí que valía la pena considerar.

¿Qué más podemos hacer para mover la aguja aquí?

¿Mejor abogacía? Estoy feliz de comprometerme a seguir abogando por las personas que no envían el modo DEV a producción, pero quiero ver si podemos obtener la solución oficial después de V16 :)

A corto plazo, parece que create-react-app está en un buen lugar para ayudar a que los nuevos proyectos eviten este problema.

Mejoras en los documentos de instalación

Para todos los demás, ¿habría soporte para https://facebook.github.io/react/docs/installation.html , incluida una llamada clara y visible debajo del encabezado Installing React para recordarles a las personas que tengan en cuenta el modo DEV en ¿producción?

Como usuario, no siento que haya un gran incentivo para leer https://facebook.github.io/react/docs/installation.html#development-and-production-versions a primera vista.

¿Pensamientos?

La razón principal por la que nuestro equipo no usa la compilación de producción es porque no podemos ejecutar pruebas unitarias de JS, ya que las utilidades de prueba no están incluidas.

Estoy confundido acerca de esto. ¿Está ejecutando pruebas en el sitio web de producción? Si no es así, ¿qué le impide usar la compilación de producción en el sitio web de producción y la compilación de desarrollo en desarrollo?

Para todos los demás, ¿habría soporte para https://facebook.github.io/react/docs/installation.html , incluida una llamada clara y visible debajo del encabezado Instalando React para recordar a la gente que tenga en cuenta el modo DEV en producción?

Seguro. ¿Quieres enviar un PR?

Seguro. ¿Quieres enviar un PR?

Más que feliz de hacerlo.

¿Quizás una palabra sobre los puntos de referencia también sería bueno para ayudar a educar a aquellos que comparan perfs con reaccionar en modo de desarrollo?

Me hace pensar que la extensión reaccionar devtools podría aprovecharse para mostrar una notificación o algo obvio al abrir una página usando reaccionar en modo de desarrollo, ¿quizás?

¡Me gusta esta idea! Reuní un conjunto de íconos propuestos para las devtools (ver facebook/react-devtools/pull/652).

Necesitamos decidir cómo detectar dev vs prod. Reaccionar de una manera segura hacia atrás y hacia el futuro, pero lo he agregado a la agenda de la reunión del lunes.

Hemos realizado algunos pasos razonables para abordar este problema:

• React DevTools (con ~700K usuarios) ahora muestra un ícono rojo distintivo para las compilaciones de desarrollo. Esto ayuda a las personas a aprender sobre la diferencia entre las versiones de manera temprana. También crea cierta presión de grupo, ya que los desarrolladores notan esto en los sitios que visitan e informan a las personas que trabajan en ellos. Hemos visto que algunos sitios importantes solucionan el problema a los pocos días de implementarlo.

• El aviso en React DevTools vincula a nuestro sitio web donde publicamos instrucciones para crear la compilación de producción para todos los paquetes principales . También lo hicimos más prominente en la página de instalación .

• Create React App siguió ganando popularidad. Enseña esta distinción temprano con órdenes separadas. También muestra un aviso permanente sobre el modo de desarrollo en la terminal.

• React 16 Beta 1 (y versiones posteriores) se envían con react.development.js y react.production.min.js como nombres de archivo para dejar en claro que la compilación no minificada no debe usarse en producción.

Creo que en el futuro podríamos explorar más formas de resolver este problema, pero por ahora siento que podemos seguir adelante sin medidas más drásticas y ver si ayuda. Gracias a todos por la discusión.