React: Encouragez les utilisateurs à ne pas envoyer le mode DEV en production

Pour référence : https://github.com/facebook/react/pull/8782

Pour le contexte, nous avertissons déjà si nous détectons que vous avez minifié une version DEV de React : https://github.com/facebook/react/blob/8791325db03725ef4801fc58b35a3bb4486a8904/src/renderers/dom/ReactDOM.js#L91 -L98

Dans la mesure où nous pouvons trouver des heuristiques similaires pour informer les utilisateurs, et peut-être encore plus agressivement pour afficher une boîte de dialogue DOM, nous devrions.

Je tiens également à préciser que les avertissements que nous fournissons peuvent améliorer considérablement les performances si les gens y prêtent attention. Ce fil explique pourquoi il est difficile de le déployer après coup si ce n'est pas la valeur par défaut.

J'aimerais également ajouter une suggestion d'un seul console.warn si renderToString est appelé en mode dev. Évidemment, dans la plupart des situations, renderToString est appelé dans le nœud, où nous ne pouvons pas alerter ou afficher une boîte de dialogue DOM.

Malheureusement, j'aimerais vraiment pouvoir détecter non seulement si NODE_ENV est défini sur production , mais aussi si process.env.NODE_ENV a été compilé. Est-ce que quelqu'un connaît un moyen de le faire?

Merci pour le fil @sebmarkbage et je reconnais les difficultés de déploiement après coup. J'apprécie également les avertissements actuels. Il semble que certains développeurs ne vérifient pas la sortie de la console de leurs sites déployés aussi souvent qu'ils le pourraient. C'est un bon premier pas cependant.

Dans la mesure où nous pouvons trouver des heuristiques similaires pour informer les utilisateurs, et peut-être encore plus agressivement pour afficher une boîte de dialogue DOM, nous devrions.

Je serais reconnaissant pour les améliorations apportées à l'heuristique utilisée pour informer les utilisateurs. Une boîte de dialogue DOM plus agressive aiderait beaucoup. Cela garantirait que le site continue de fonctionner pour les utilisateurs finaux, mais fournit un indice actif qu'il existe des développeurs de fruits à faible rendement pouvant être choisis.

L'alternative est que nous trouvions un moyen de résoudre ce problème au niveau de l'outil de construction / ENV, comme mentionné dans le message d'origine. Cela éviterait toute injection de DOM nécessaire.

Injecter n'importe quelle messagerie dans le DOM semble dangereux et un peu trop assumé. Cela ouvre la possibilité aux utilisateurs finaux de recevoir des alertes inattendues et déroutantes, ce qui semble inacceptable à l'OMI.

@thelarkinn proposait que nous essayions de normaliser les configurations ENV requises pour mieux faciliter la détection de messages comme celui-ci

Cela semble être l'espace idéal pour résoudre ce problème. C'est un problème de construction et devrait être, si possible, résolu par les outils de construction.

Anecdotique : les avertissements de la console sont passés inaperçus (ou ignorés) dans le passé. Je n'ai pas de chiffres précis ici, mais je pense que les avertissements basés sur la console ne suffisent pas. Je suis d'accord avec @addyosmani qu'un avertissement basé sur DOM irait loin.

@surma peut-être qu'ils devraient utiliser console.warn ou console.error pour une meilleure visibilité 😉

Je ne vois pas comment il serait acceptable dans n'importe quel scénario d'injecter du contenu dans une application uniquement lorsqu'elle s'exécute en production. Vous faites l'énorme hypothèse que le message serait intercepté avant que l'application ne soit transmise aux utilisateurs réels, où le message pourrait potentiellement nuire UX de manière majeure.

Au fait, nous allons ajouter une prise en charge plus complète de la gestion des erreurs dans Fiber afin que vous puissiez remplacer les composants qui ont des échecs (erreurs générées) par des vues d'erreur personnalisées. Même dans le scénario par défaut, nous allons probablement être très agressifs et supprimer ce composant de l'arborescence en cas d'erreur. Vous voudrez donc vraiment avoir une interface utilisateur d'erreur personnalisée pour vos utilisateurs de toute façon.

Nous pourrions être en mesure de déclencher une telle erreur pour cet avertissement.

Honnêtement, je ne pense pas que console.{error,warn} sur console.log aurait changé quoi que ce soit. Comme je l'ai dit, cette histoire est anecdotique.

Je ne dis pas non plus que montrer une boîte de dialogue DOM est _la_ solution. C'est quelque chose avec lequel je serais personnellement à l'aise, cependant. Si rester en mode de développement a un impact négatif, au moins les utilisateurs sauront que _quelque chose_ ne va pas et commenceront probablement à appuyer sur le bouton "Aide" ou quelque chose du genre.

Conclusion : je pense que les frameworks doivent se mettre en face du développeur à un moment donné. J'aimerais réfléchir à ce sujet pour voir quelles mesures et quels compromis les auteurs du framework sont prêts à prendre pour empêcher les gens de se déployer en mode développement à l'avenir.

Et si React ne fonctionnait pas du tout à moins que vous ne fournissiez un environnement, qu'il s'agisse de développement ou de production ? De cette façon, un choix conscient est fait dans un sens ou dans l'autre.

A propos du message injecté dans le DOM, il pourrait être désactivé en utilisant un global ou quelque chose. Pas grave OMI. Si vous le désactivez, vous reconnaissez en quelque sorte que vous savez ce que vous faites.

Le problème avec un message de console est que parfois les gens enregistrent beaucoup de choses, ou ont d'autres avertissements qu'ils ignorent, et il est facile de ne pas voir ce premier message de console après le défilement...

Avec un env obligatoire, inévitablement les passe-partout, etc. définiront la variable d'env afin que vous puissiez simplement commencer à l'utiliser, j'en ai peur :/

Honnêtement, je ne pense pas que console.{error,warn} sur console.log aurait changé quoi que ce soit.

Pensez-vous que c'est un problème avec les développeurs qui ne vérifient pas la console ou que la console est surchargée d'avertissements ? Cela pourrait-il être (partiellement) résolu avec une approche plus générale concernant la formation des développeurs ?

Je ne dis pas non plus que montrer une boîte de dialogue DOM est la solution. C'est quelque chose avec lequel je serais personnellement à l'aise, cependant. Si rester en mode de développement a un impact négatif, au moins les utilisateurs sauront que quelque chose ne va pas et commenceront probablement à appuyer sur le bouton "Aide" ou quelque chose du genre.

Je comprends cela, mais je dis juste que je ne pense pas que ce soit une solution et encore moins la solution. C'est bien que vous soyez à l'aise avec cela, mais je pense qu'il vaut mieux pécher par excès de prudence et supposer que la plupart des gens ne veulent pas que des erreurs inattendues soient affichées à leurs utilisateurs.

Conclusion : je pense que les frameworks doivent se mettre en face du développeur à un moment donné. J'aimerais réfléchir à ce sujet pour voir quelles mesures et quels compromis les auteurs du framework sont prêts à prendre pour empêcher les gens de se déployer en mode développement à l'avenir.

Je suis 💯 pour me mettre en face du développeur, mais il est important de le faire au bon endroit. Pour moi, c'est l'étape de construction, pas de production.

A propos du message injecté dans le DOM, il pourrait être désactivé en utilisant un global ou quelque chose. Pas grave OMI. Si vous le désactivez, vous reconnaissez en quelque sorte que vous savez ce que vous faites.

L'avoir activé par défaut est tout aussi mauvais que de ne pas le rendre configurable : le comportement par défaut pourrait entraîner un comportement inattendu pour l'utilisateur final. Si quoi que ce soit, il devrait être désactivé par défaut, mais cela va à l'encontre de tout l'objectif puisque les développeurs pourraient simplement résoudre le problème initial une fois qu'ils en sont conscients.

Le problème avec un message de console est que parfois les gens enregistrent beaucoup de choses, ou ont d'autres avertissements qu'ils ignorent, et il est facile de ne pas voir ce premier message de console après le défilement...

Je comprends tout à fait cela, la console peut être encombrée et il est facile de manquer des choses. Mais c'est bondé pour les raisons exactes que je défends : c'est l' endroit où les développeurs fournissent des commentaires ou des erreurs. C'est à l'écart de l'expérience utilisateur, ce qui n'est pas le cas des messages injectés.

C'est logique, je comprends le raisonnement.

Eh bien, peut-être que faire ressortir la chose en utilisant le formatage de la console serait au moins quelque chose.

Le problème est que presque personne ne regarde la console en production. Vous pouvez y utiliser n'importe quelle police et les gens ne le remarqueront pas.

Cependant, si nous lui faisons afficher un message par défaut en production en tant que changement de rupture (en 16 ou 17), il serait difficile de le manquer. Je veux dire, cela se produirait la première fois que vous essaieriez de le déployer (pour les nouveaux utilisateurs), et les utilisateurs existants devraient lire les notes de publication lors de la mise à jour vers une nouvelle majeure. Donc je pense que c'est faisable tant qu'on est super explicite dessus et qu'il est impossible de passer à côté du message.

Le problème est que presque personne ne regarde la console en production. Vous pouvez y utiliser n'importe quelle police et les gens ne le remarqueront pas.

Je ne peux que commenter l'expérience de l'équipe Chrome à ce sujet, mais je suis d'accord. La plupart des gens remarqueront les messages de la console au cours de leur flux de travail d'itération, mais un pourcentage beaucoup plus faible regarde les avertissements sur les sites de production et moins agit en conséquence.

Cependant, si nous lui faisons afficher un message par défaut en production en tant que changement de rupture (en 16 ou 17), il serait difficile de le manquer. Je veux dire, cela se produirait la première fois que vous essaieriez de le déployer (pour les nouveaux utilisateurs), et les utilisateurs existants devraient lire les notes de publication lors de la mise à jour vers une nouvelle majeure. Donc je pense que c'est faisable tant qu'on est super explicite dessus et qu'il est impossible de passer à côté du message.

Merci d'être ouvert à un tel changement @gaearon. Que faudrait-il pour obtenir un accord sur l'essai d'un message par défaut dans une future version ? 😄

Je conviens que les avertissements de la console ne sont pas la solution et qu'un avertissement visible sur la page est bien meilleur.

L'avertissement visible sur la page pourrait :

• Alerter le dev que le site est en mode dev
• Lien vers la documentation sur les avantages et comment expédier sans elle
• Un lien pour désactiver le message pendant… je ne sais pas 2 heures ?

Il est important de désactiver le message, car il peut interférer/couvrir quelque chose sur la page. Étant donné que ce paramètre serait stocké dans le stockage local, l'avertissement apparaîtra toujours sur le serveur en direct car il s'agit d'une origine différente.

Oui, c'est assez horrible si de vrais utilisateurs voient ce message sur des sites en direct, mais il semble que le genre de problème que les développeurs seront encouragés à résoudre, alors que certains semblent être heureux de vivre avec les problèmes de performances du mode de développement.

Si la première fois que je voyais cet avertissement (l'insert dans DOM), c'était en production, je serais assez contrarié. Les avertissements doivent arriver à l'avance.

@rtorr ma suggestion est que cela se produit chaque fois que le site est en mode de développement, donc cela devrait être vu à l'avance à moins que quelque chose ne me manque?

@jakearchibald désolé pour la confusion, ma réponse ne s'adressait pas à la vôtre. Je veux juste signaler au fil de discussion que si nous devions utiliser la solution "insérer dans le dom", nous devrions être très prudents et nous assurer que les utilisateurs le savent avant de pousser quelque chose (certains comment, je n'ai aucune bonne idée ici) .

Je vois juste un développeur oublier un paramètre ou quelque chose et la direction panique. Cette possibilité en vaut-elle la peine compte tenu des conséquences du mode de développement en production ?

Un avertissement basé sur DOM que je dois constamment désactiver n'est pas correct, il doit être possible de le désactiver pour toujours, et peut-être qu'il ne devrait jamais s'afficher du tout pour localhost.

Une chose qui vient de me frapper s'il serait possible d'avoir une sorte de drapeau dans le navigateur que vous devez activer pour activer les devtools (peut-être une grande superposition avec "Êtes-vous un développeur ? [Oui/Non]" ) que la page peut détecter et afficher uniquement l'avertissement pour les développeurs. Formulé correctement, cela pourrait également aider avec les attaques auto-XXS.

Un avertissement basé sur DOM que je dois constamment désactiver n'est pas correct, il doit être possible de le désactiver pour toujours

Le lancement de sites avec le mode de développement activé n'est pas non plus acceptable. Peut-être que le message n'a besoin d'être rejeté qu'une fois par jour ? Mais plus la période est longue, plus il est probable que cela se terminera en direct. S'il peut être désactivé pour toujours, nous sommes de retour là où nous avons commencé.

Je ne pense pas non plus qu'un nœud dom involontaire en production soit acceptable.

Je pense que de toute façon, nous aurons toujours un cas limite. Si ce problème se produit tout le temps, alors peut-être que la livraison du mode de développement est erronée. Bien que ce ne soit pas l'idéal dans un monde parfait, mais si nous trouvons que le mode prod est si important que nous sommes prêts à modifier l'application de quelqu'un, il devrait peut-être être par défaut et le mode de développement devrait être activé.

@rtorr

Je ne pense pas non plus qu'un nœud dom involontaire en production soit acceptable.

Pourquoi? (Je ne dis pas que tu as tort, j'aimerais juste entendre tes raisons)

Peut-être ajouter un paramètre pour définir le domaine prod. Si le domaine prod n'est pas défini, nous recevons toujours l'avertissement concernant le mode DEV (avec une demande de définition de l'URL du domaine), s'il est défini, nous ne recevons un avertissement que lorsque l'URL correspond au domaine prod. Nous pourrions même lier n'importe quel service que nous voulons notifier aux développeurs

Je suis content qu'il y ait une discussion constructive ici. Il y a deux solutions ici que je peux voir résoudre le problème. Webpack pourrait forcer la spécification de NODE_ENV que React pourrait ensuite utiliser pour éviter plus facilement que les gens envoient DEV à PROD, mais ce serait un changement radical pour Webpack. Je parle maintenant à Sean de la faisabilité de quelque chose comme ça pour Webpack 3. Je sais que les deux camps se soucient de garder la pile React + Webpack pour débutants et perf.

La seconde (idée d'injection DOM) est quelque chose que React pourrait faire et comme Jake l'a mentionné, équilibrer l'UX en permettant au message d'être affiché une fois par jour ou d'être rejeté. C'est un changement d'une ligne pour résoudre le problème, puis il vous suffit de redéployer. Je comprends complètement le fait de ne pas vouloir que la direction panique.

Si nous voulons obtenir plus de sites React expédiant l'expérience beaucoup plus rapide sur laquelle FB a travaillé pour produire quelque chose pourrait avoir à donner. Si quelqu'un a de meilleures idées, merci de les suggérer.

@jakearchibald

Pourquoi? (Je ne dis pas que tu as tort, j'aimerais juste entendre tes raisons)

Revenons à mon commentaire ci-dessus, à moins que nous ne soyons en mesure d'informer les développeurs à l'avance (ce qui semble être le véritable problème à résoudre), je trouve un peu extrême de dévaluer le produit de quelqu'un en affichant un avertissement aux développeurs sur leur page de production. Dans de nombreux cas, cela pourrait nuire davantage au produit qu'aux performances du mode de développement.

Peu importe ce que nous faisons, quelqu'un va expédier tout ce qui est par défaut en production, pourquoi ne pas rendre la production par défaut ? Pourquoi ne pas améliorer le mode de développement au point qu'il n'ait pas un si gros impact ?

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

@jakearchibald ouais, je vois que les deux côtés ont des problèmes. Je fais confiance aux personnes de ce fil pour proposer quelque chose de bien, même si c'est ce que vous proposez. Vous êtes tous super FYI. Peut-être extrême est la réponse.

Ne pourriez-vous pas insérer l'avertissement du nœud DOM si l'utilisateur exécute les outils de développement React afin que les utilisateurs normaux ne le ressentent pas ?

@jakearchibald

Le lancement de sites avec le mode de développement activé n'est pas non plus correct. Peut-être que le message n'a besoin d'être rejeté qu'une fois par jour ? Mais plus la période est longue, plus il est probable que cela se terminera en direct. S'il peut être désactivé pour toujours, nous sommes de retour là où nous avons commencé.

Lorsque le site a été lancé, quelqu'un a décidé qu'il était "prêt", donc même si c'est mauvais, ce n'est pas une catastrophe. Cependant, avoir (peut-être, je ne connais pas les chiffres exacts) des centaines de milliers de développeurs devant rejeter un site destructeur (un avertissement DOM doit être traité comme tel car vous n'avez aucune idée de la façon dont il interagit avec le reste du site et si le site est utilisable avec l'avertissement visible) avertir cinq ou même une seule fois par jour est une catastrophe. La plupart des développeurs ont une chaîne de construction correctement configurée (personnalisée, create-react-app ou autre) et n'ont aucune utilité pour cet avertissement, ils doivent pouvoir s'en débarrasser.

@dan-gamble Je pense que les développeurs qui n'utilisent pas React Dev Tools sont la cible la plus urgente pour cet avertissement.

@Pajn Potentiellement, je ne pense pas que ce n'est pas parce que vous téléchargez une extension Chrome que cela vous rend automatiquement conscient du commutateur prod / dev

@dan-gamble Non, bien sûr que non. Mais il y a des gens qui développent une application entière sans cela, ce qui, je pense, indique qu'ils n'utilisent pas beaucoup les outils de développement et sont donc moins susceptibles de voir l'avertissement actuel pour le code minifié.

Je n'ajoute généralement pas à une discussion aussi longue quand j'ai l'impression que le point a déjà été abordé, mais je suis d'accord avec cela et je veux souligner ce point : Réagissez en touchant le DOM et en m'avertissant que j'utilise une version dev être une grosse erreur. Autant que je sache, il n'y a pas de précédent pour cela dans un autre cadre.

Imaginez tous les tutoriels, tous les terrains de jeux, tous les petits projets parallèles qui utilisent le mode dev pour enseigner React. Chaque petit site de test que je lance pour explorer quelque chose d'amusant dans React, ou essayer d'isoler un cas de test. Si Réagissez à travers un avertissement sur chacun de ces sites que je devais désactiver manuellement, je serais incroyablement fou. Cela ressemblerait à un parent autoritaire et vous découragerait activement d'utiliser React, car chaque fois que vous essayez de faire quelque chose de nouveau, cela vous tape sur le poignet.

Même le faire toutes les 2 heures ? Non, merci. Un harcèlement constant comme celui-ci va certainement décourager les utilisateurs de développer dans React et je pense honnêtement que cela pousserait les gens à adopter d'autres frameworks. C'est peut-être ce que veulent les développeurs de Chrome ?

Sans parler du fait que oui, cela va se glisser en production d'une manière ou d'une autre, et il est déjà assez difficile de convaincre certaines équipes d'adopter React et c'est juste plus de munitions pour elles contre cela.

La chose que j'aime le plus à propos de React, c'est qu'il ne fait rien jusqu'à ce que vous appeliez ReactDOM.render(...) et quand vous faites cela, il ne met que des choses dans le DOM où vous lui avez dit. C'est pourquoi c'est une si bonne bibliothèque fonctionnelle isolée.

Avons-nous également besoin de détecter si les personnes expédient un lot non minifié ? Qu'en est-il s'ils ne mettent pas en cache quand ils le devraient ? Qu'en est-il lorsqu'ils n'ont pas configuré nginx de manière optimale ? Ou n'utilisez pas shouldComponentUpdate quand ils le devraient ? Ou restituent-ils tout inutilement alors qu'ils n'en ont pas besoin ?

Il y a plusieurs raisons à de mauvaises performances et le blâmer uniquement sur le mode de développement de React est faux. Lorsque vous déployez un site, il est totalement attendu que vous compreniez comment déployer un site optimisé. Je ne dis pas qu'il n'y a rien que nous puissions faire, mais la principale raison à cela est que les auteurs de référence ne font pas preuve de diligence raisonnable et nous ne devrions pas avoir à payer pour cela. Nous devons trouver un autre moyen de l'appeler.

Je voulais faire un suivi avec ce que je pense être la bonne solution : mettre ce genre de restrictions dans les outils. S'assurer que le pack Web ou tout autre outil que vous utilisez pour créer votre site pour la production est l'endroit où nous devrions forcer ces vérifications et je suis d'accord avec tout type de restrictions que nous voulons imposer dans le processus de construction.

En ce qui concerne le webpack forçant un paramètre NODE_ENV (il y a peut-être déjà un problème pour cela dans leur dépôt), cela ne rendrait-il pas plus difficile l'utilisation de bibliothèques qui ne reposent pas sur les paramètres env ?

Ou est-ce l'idée qu'il détecterait l'utilisation de NODE_ENV et ne le forcerait que si le code l'utilise ?

Ne nous attardons pas trop sur le truc des "2 heures". Cela pourrait être n'importe quelle période de temps tant que cela fonctionne.

De plus, les événements de stockage local signifient qu'il ne devrait être rejeté qu'une seule fois par origine. Si vous avez plusieurs démos sur une même page, en rejeter une entraînerait la suppression des autres.

Si l'avertissement se glisse en direct, il est suffisamment fort pour justifier une solution rapide - une solution qui profite aux utilisateurs. Si nous nous inquiétons de l'apparence de React en public, nous voulons vraiment éviter un ralentissement inutile comme celui-ci.

Bien sûr, cela ne détecterait pas les mauvais en-têtes de mise en cache, etc., il s'agit de détecter uniquement le "mode de développement". De plus, les arguments de "pente glissante" ne sont pas utiles.

Je ne pense pas que déplacer le problème pour construire des outils soit utile, car vous aurez le même problème si les développeurs utilisent un outil de construction différent ou ne parviennent pas à le mettre en mode production. Les frameworks du mode Dev produisent déjà des avertissements de console, et cela ne fonctionne clairement pas.

Il ne s'agit pas seulement de points de repère, il s'agit de vrais sites Web, fonctionnant lentement pour de vrais utilisateurs, car aucun commutateur n'a été activé.

@jakearchibald Merci pour la réponse rationnelle à ma réponse chargée d'émotion. Je pense que c'est un point valable qu'il existe de nombreuses raisons pour lesquelles un site peut être lent avec React. J'aimerais voir un moyen de suggérer des améliorations de performances qui soient meilleures qu'une vérification grossière du mode de développement et un avertissement dans le navigateur. Si nous disposions d'outils pour analyser une application React et fournir des suggestions sérieuses de performances, du mode de développement à trop de rendus, ce serait beaucoup plus utile. Un outil générique comme celui-ci peut être accroché à n'importe quel pipeline, que ce soit webpack, browserify, etc.

C'est la principale chose que je voulais dire cependant : certains jours, j'utiliserai le mode de développement de React dans 5 à 10 endroits différents, comme jsbin, des tutoriels, et même en créant un petit site de test et en l'ouvrant avec le protocole file://. Un avertissement forcé dans le navigateur est hostile à ce type de développement flexible, domaine dans lequel le Web excelle. Je verrais ces avertissements partout parce que j'apprends à réagir sur plusieurs domaines sur le Web.

Si l'avertissement se glisse en direct, il est suffisamment fort pour justifier une solution rapide - une solution qui profite aux utilisateurs. Si nous nous inquiétons de l'apparence de React en public, nous voulons vraiment éviter un ralentissement inutile comme celui-ci.

Même autoriser la possibilité qu'un avertissement spécifique au développeur soit affiché aux utilisateurs finaux me semble inacceptable. Un site lent est une chose, mais un message comme celui-ci pourrait saper la confiance des utilisateurs, en particulier pour les sites axés sur la sécurité (seriez-vous heureux si votre site bancaire affichait tout d'un coup des erreurs cryptées ?) Google serait-il d'accord avec tous leurs les utilisateurs reçoivent-ils soudainement cet avertissement, même si ce n'est que pour un instant ?

De plus, les événements de stockage local signifient qu'il ne devrait être rejeté qu'une seule fois par origine. Si vous avez plusieurs démos sur une même page, en rejeter une entraînerait la suppression des autres.

Vous ne pouvez pas compter sur localStorage pour dédupliquer cela. Il n'y a aucune garantie que localStorage (ou toute autre donnée persistante locale) ne sera pas effacée à n'importe quel intervalle.

edit : De plus, en n'affichant l'erreur qu'une fois tous les {INTERVAL} , vous avez rendu la reproduction et le débogage beaucoup plus difficiles car elle n'est pas reproductible de manière déterministe.

Il y a 2 cas à résoudre :

• Empêchez les tests de performances et les benchmarks erronés : facilement résolus avec un gros message de console.
• Empêcher l'envoi de DEV aux sites de production : les utilisateurs n'ouvrent pas les outils de développement dans la production.

Les arguments contre le fait de toucher au DOM sont convaincants.

S'il y a un avertissement de console important, flashy et évident, il y a de fortes chances qu'avant l'expédition en production, les gens utilisent la version de développement et voient ce message de console vraiment évident. Ou peut-être que du code a déjà été envoyé en production, mais pour un autre projet, ils utiliseront la prochaine version de réaction avec ce message de console impossible à manquer. Peut-être qu'ils se souviendront de ce site qu'ils ont expédié en production et vérifieront si DEV y est activé.

Le message de la console serait éducatif, comme, quiconque fait du développement React sait qu'il y a quelque chose de vraiment important à propos de DEV, et ils le voient à chaque fois qu'ils utilisent React pour le développement.

J'hésitais à propos de https://github.com/facebook/react/pull/8782 parce que les gens n'aiment généralement pas les avertissements dont ils ne peuvent pas se débarrasser (voir https://github.com/facebook/react/issues/ 3877), mais compte tenu des alternatives, cela pourrait être une solution acceptable.

Curieuse. L'utilisation de localStorage invoquerait-elle la loi européenne sur les cookies sur un site qui n'est pas autrement couvert par celle-ci ?

Si les avertissements informatifs pendant le développement sont une bonne idée, alors pourquoi les autres bibliothèques ne le font-elles pas ? Eh bien, une des raisons est pour des problèmes comme celui-ci. Si d'autres personnes voulaient le faire, devraient-elles également afficher des interfaces utilisateur similaires ? Faut-il tous les fermer ?

Il me semble qu'il serait idéal d'avoir quelque chose de plus central pour gérer cela.

Peut-être que Chrome pourrait avoir un mode développement ? Les bibliothèques pourraient indiquer à l'hôte qu'elles sont en mode développement, puis Chrome pourrait ajouter un badge ou une fenêtre contextuelle pour l'indiquer.

Me fait penser que l'extension React devtools pourrait être exploitée pour afficher une notification ou quelque chose d'évident lors de l'ouverture d'une page en utilisant React en mode dev peut-être ?

@sebmarkbage

Si les avertissements informatifs pendant le développement sont une bonne idée, alors pourquoi les autres bibliothèques ne le font-elles pas ?

Je suppose que quelqu'un doit être le premier. Angular a un problème similaire, avec des trucs comme http://code.gov lancé en mode dev. Si React commence à attraper ce genre de choses là où d'autres frameworks ne le font pas, je ferai pression pour qu'ils apportent des modifications similaires.

Je vais faire pression pour qu'ils fassent des changements similaires.

@jakearchibald suggérez -vous que chaque framework devrait fournir son propre avertissement ? Je ne pense pas que définir la norme pour les frameworks/bibliothèques fournissant leurs propres avertissements de développement en production soit une bonne idée. Ne devrions-nous pas essayer de standardiser sur la plate-forme ? Comme mentionné par @sebmarkbage

Peut-être que Chrome pourrait avoir un mode développement ? Les bibliothèques pourraient indiquer à l'hôte qu'elles sont en mode développement, puis Chrome pourrait ajouter un badge ou une fenêtre contextuelle pour l'indiquer.

Je pense que c'est une excellente idée. Précédent : Safari a un mode distinct que vous devez activer pour accéder à DevTools. Si Chrome faisait de même, il pourrait également ajouter en toute sécurité un indicateur pour le mode DEV et une API pour le déclencher. Cet indicateur ne serait visible que pour les développeurs afin de ne pas perturber l'expérience utilisateur.

Attendre que les éditeurs de navigateurs implémentent une telle chose ne va-t-il pas prendre du temps ?

@jide oui, mais il est plus important de résoudre ce problème correctement que rapidement. De plus, il peut être implémenté dans un seul navigateur avant d'envisager des efforts de normalisation (si nécessaire).

@aweary

suggérez-vous que chaque cadre devrait fournir son propre avertissement ?

Étant donné que chaque framework fournit son propre mode de développement (et que ce mode peut être très différent d'un framework à l'autre), il semble tout à fait juste que le framework implémente l'avertissement d'une manière tout aussi unique.

Les navigateurs ont fait des efforts pour éviter d'exposer les outils de développement à la page. Si nous faisons des devtools la barrière à l'entrée ici, nous allons manquer beaucoup d'utilisateurs qu'un avertissement DOM ne manquerait pas. Un avertissement DOM semble non seulement plus simple, il a moins de dépendances de plate-forme et atteindra plus de développeurs. Plus simple et plus efficace sonne comme une victoire.

@gaearon Du côté de Chrome DevTools, nous avons réfléchi à une "API de violation" en direct que les auteurs de plates-formes et de frameworks Web pourraient utiliser pour signaler des avertissements importants. Ceux-ci seraient présentés quelque part comme le prochain rafraîchissement du panneau Audits. Cela ressemble à votre demande et pourrait être utilisé pour déclencher un avertissement sur la détection du mode DEV.

Pour ce problème particulier, vous recherchez peut-être quelque chose d'un peu plus bruyant que ce que nous avions prévu à l'origine. Un panneau de violations, similaire aux messages du journal de la console, vous oblige à savoir qu'un panneau va fournir des informations. Peut-être y a-t-il un espace UX supplémentaire pour quelque chose qui affiche une superposition de page très visible plus bas sur la page pour laquelle les frameworks pourraient normaliser la messagerie. Boucle dans @paulirish et @s3ththompson pour leurs réflexions après le week-end de vacances.

Fwiw, je suppose que cette API ne sera pas prête avant quelques mois. Lorsqu'il le sera, il ne sera initialement disponible qu'aux Canaries, puis 6 à 7 semaines plus tard, il pourrait devenir stable.

Un avertissement DOM semble non seulement plus simple, mais plus efficace.

Je suis d'accord avec Jake sur celui-ci. Continuons à discuter de la solution DevTools, mais j'aimerais également comprendre ce que React pourrait être prêt à faire comme solution de rechange au cas où l'API ne répondrait pas à vos besoins ou serait plus éloignée de la chronologie.

Étant donné que chaque framework fournit son propre mode de développement (et que ce mode peut être très différent d'un framework à l'autre), il semble tout à fait juste que le framework implémente l'avertissement d'une manière tout aussi unique.

@jakearchibald , vous vous rendez compte que la définition de cette norme signifie que les pages utilisant plusieurs frameworks (ou bibliothèques qui ont suivi dans la suite) pourraient entraîner l'affichage d'une quantité arbitraire d'avertissements cryptés rendus de manière non déterministe aux utilisateurs finaux ?

Les navigateurs ont fait des efforts pour éviter d'exposer les outils de développement à la page.

Et je suis sûr que la raison en est au moins en partie parce que les messages spécifiques aux développeurs ne doivent pas être exposés aux utilisateurs finaux.

Un avertissement DOM semble non seulement plus simple, mais plus efficace.

Personne ne conteste la simplicité ou l'efficacité de la solution. Cela fonctionnerait , mais au détriment de l'expérience utilisateur. La vitesse n'est pas la seule chose qui peut affecter négativement les utilisateurs.

Fwiw, je suppose que cette API ne sera pas prête avant quelques mois. Lorsqu'il le sera, il ne sera initialement disponible qu'aux Canaries, puis 6 à 7 semaines plus tard, il pourrait devenir stable.

@addyosmani si c'est une meilleure solution, je ne vois pas en quoi ce serait un problème. Toute modification apportée à React serait dans une version majeure, ce qui, je pense, est à déterminer en ce qui concerne le calendrier de sortie de toute façon.

La solution retenue affectera potentiellement tous les développements futurs. Une question de semaines ou de mois dans ce contexte est acceptable à l'OMI.

Je comprends que certains développeurs se sentent envahis si un framework injecte dans leur DOM quelque chose qu'ils n'y ont pas mis eux-mêmes. Mais j'ai l'impression qu'une bannière en bas de la page qui dit "Ce site est en DevMode" serait une excellente solution à cela qui n'a pas un grand impact sur l'expérience de l'utilisateur. J'aimerais comprendre pourquoi beaucoup de gens pensent le contraire.

@aweary : Si jamais un site "axé sur la sécurité" se lance en DevMode, il ne faut pas lui faire confiance tant qu'il n'a pas résolu le problème. « DevMode » peut inclure toutes sortes de raccourcis liés à la sécurité, tels que les vérifications CORS désactivées ou le code source du modèle exposé, etc. Si un site est axé sur la sécurité, cela ne doit pas se produire.

(Je me rends compte que "DevMode" a une signification très spécifique dans React, mais j'essaie ici d'assumer le point de vue d'un non-développeur)

@aweary

vous vous rendez compte que la définition de cette norme signifie que les pages utilisant plusieurs frameworks pourraient entraîner l'affichage d'une quantité arbitraire d'avertissements cryptés rendus de manière non déterministe aux utilisateurs finaux ?

Je m'en rends parfaitement compte. Une page avec plusieurs frameworks en mode développement endommagera gravement l'expérience utilisateur sans raison valable. Il semble que vous préfériez qu'il passe inaperçu et non corrigé. Je préférerais que ce soit si mauvais pour les non-développeurs (messages visibles destinés aux développeurs) que le développeur le corrige rapidement, créant ainsi une bien meilleure expérience utilisateur.

La vitesse n'est pas la seule chose qui peut affecter négativement les utilisateurs.

Je ne vois personne prétendre le contraire ? Je suis assez triste de ce genre de réaction 😞

Il semble que tu préfères que ça passe inaperçu et non corrigé

@jakearchibald c'est une sorte de conclusion étrange, je ne pense pas que je passerais mon temps libre ici à parler avec vous si je ne voulais pas que cela soit réparé? Ce n'est pas parce que je ne suis pas d'accord avec votre solution que je me résigne à ne pas la résoudre. C'est vraiment injuste.

Je préférerais que ce soit si mauvais pour les non-développeurs (messages visibles destinés aux développeurs) que le développeur le corrige rapidement, créant ainsi une bien meilleure expérience utilisateur.

C'est ce que je trouve fondamentalement inacceptable : vous punissez explicitement les utilisateurs en premier.

Si un site "axé sur la sécurité" se lance un jour en DevMode, il ne faut pas lui faire confiance tant qu'il n'a pas résolu le problème.

Le mode dev @surma n'est pas intrinsèquement dangereux, mais quoi qu'il en soit, il dépasse les bornes pour supposer que vous pouvez le communiquer aux utilisateurs.

Je ne pense pas qu'une solution nécessitant l'ouverture ou l'activation d'outils de développement soit suffisante. Pour que cela soit remarqué, il doit être visible pour l'assurance qualité, la direction et éventuellement les utilisateurs finaux. Les développeurs seront trop habitués à voir cela. Semblable à la façon dont les configurations SSL problématiques sont mises en évidence. Il n'a pas besoin d'être beaucoup mais assez pour être perceptible que quelqu'un posera des questions à ce sujet et le fera ensuite réparer.

L'injection dans le DOM est problématique pour de nombreuses raisons. C'est un peu plus faisable pour React puisque nous sommes une bibliothèque DOM et avons des points d'entrée DOM. C'est plus difficile pour les bibliothèques qui ne sont pas spécifiques à DOM et qui peuvent s'exécuter dans un worker.

Une chose que nous pourrions faire est de changer le favicon tant que nous fournissons un moyen de le remplacer explicitement. De nombreux sites ont déjà des favicons distincts pour le mode de développement.

Nous devons trouver une expérience par défaut pour gérer les erreurs dans React qui peut ne pas être en mesure de maintenir le DOM en place. L'implémentation par défaut actuelle dans master supprime le contenu React de l'arborescence si une erreur est générée. C'est aussi envahissant.

Si nous avions un moyen de détecter que vous n'êtes pas en mode développement, nous pourrions déclencher ce mode d'erreur. Nous avons vraiment besoin d'un moyen solide pour opter définitivement pour un mode de développement.

Semblable à la façon dont les configurations SSL problématiques sont mises en évidence.

C'est exactement le genre de chose que je pense serait parfait. Les utilisateurs sont déjà habitués aux navigateurs fournissant des informations de sécurité sur les sites qu'ils visitent, les informations sur les performances ne sont pas un grand saut à partir de là. De plus, il serait cohérent pour tous les frameworks/bibliothèques qui signalent des problèmes de performances potentiels et n'interférerait pas directement avec le flux de travail de l'utilisateur. 👍

J'aime l'idée du favicon : Remarquable, fonctionne sans devtools ni extension, perceptible par tout le monde, ne nuit pas aux utilisateurs, peut être animé pour attirer l'attention, assez ennuyeux pour donner envie aux devs de disparaître.

Qu'en est-il de l'activation du mode DEV ?
Nous nous trompons du côté "bon UX", car le mauvais DX est plus facile à remarquer (et à mon humble avis, pour des problèmes comme celui-ci, les utilisateurs devraient "gagner" car ils ne peuvent pas choisir, alors que les développeurs le peuvent).
Je suis sûr que certains frameworks le font déjà (comme Relay si je me souviens bien).

Propositions pour sa mise en œuvre :

• activer le mode de développement uniquement si NODE_ENV est explicitement défini sur development
• activer le mode de développement si le __DEV__ global est === true
• exporter un module d'outils de débogage à activer dans userland

Le premier semble le meilleur car les deux autres peuvent être codés en dur sans garde (comme une instruction if(NODE_ENV === 'development') ) et donc être envoyés en production de toute façon.

@mattecapu Voir mon deuxième commentaire concernant. https://twitter.com/sebmarkbage/status/820047144677584896

S'il existe une manière similaire d'imposer que les développeurs commencent par s'exécuter en mode DEV, peu importe la valeur par défaut. Mais c'est vraiment mauvais si vous prenez du retard.

Il y a beaucoup à commenter ici, et j'ai des idées, mais j'aimerais peser spécifiquement sur la question de savoir comment désactiver un avertissement de développement.

Je ne suis pas un grand fan d'un bouton qui désactive un avertissement DOM pendant une durée définie dans un navigateur particulier. Comme le souligne @jlongster , c'est pénible pour les développeurs si cela se produit fréquemment. Mais plus important encore pour moi, cela introduit une variabilité de comportement spécifique au navigateur, ce qui pourrait facilement conduire à l'irréproductibilité "mais cela fonctionne bien sur ma machine" des bogues.

Je préférerais un paramètre envoyé au rendu qui répertorie les domaines considérés comme des boîtes de développement, avec une valeur par défaut de ["localhost", "127.0.0.1"] . Cela ressemblerait à ceci :

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

Si le domaine actuel est dans la liste, l'avertissement dev ne s'affiche jamais. Sinon, c'est le cas. Sous ce régime :

• Utilisation de dev build sur votre machine locale en utilisant localhost ou 127.0.0.1 : Aucun avertissement de développeur jamais, et aucune action de développeur nécessaire.
• Utiliser dev build sur une machine de développement en utilisant un autre nom d'hôte : vous obtenez l'avertissement DOM jusqu'à ce que vous ajoutiez le nom de domaine à la liste transmise à render . Par la suite, vous ne recevez jamais l'avertissement DOM.
• Utilisation de la version de développement sur une machine prod : vous obtenez l'avertissement DOM jusqu'à ce que vous passiez React à la version prod.

La seule chose qui m'inquiète à propos de cette solution est qu'elle pourrait amener les développeurs à laisser une liste de tous leurs domaines de serveur de développement dans le code, et ce code pourrait arriver en production. Pour les entreprises qui considèrent leurs domaines de serveur de développement comme un secret, ce serait un problème. Les pensées?

@aickin , le problème avec cette approche est qu'elle oblige les utilisateurs à connaître la configuration et, par conséquent, le problème qu'elle résout. Le problème est que les gens ne sont pas conscients de la distinction dev/prod en premier lieu.

Edit : tant pis, je vois, il y a encore un avertissement DOM en développement.

Les environnements côté serveur résolvent ce problème en affichant une page d'erreur "spéciale" qui inclut les détails de débogage et vous indique également de ne pas la diffuser en production.

Étant donné que nous prévoyons de faire en sorte que React "échoue rapidement" et démonte les vues à moins que vous ne fournissiez une limite d'erreur personnalisée, nous pourrions tout aussi bien ajouter une limite d'erreur "boîte rouge" par défaut dans le développement qui agit comme une page éducative.

Ensuite, la première fois que l'utilisateur a un bogue en production, il verra un message d'erreur détaillé spécial. Cela pourrait être l'occasion d'éduquer sur la version DEV.

Mais j'ai l'impression qu'une bannière en bas de la page qui dit "Ce site est en DevMode" serait une excellente solution à cela qui n'a pas un grand impact sur l'expérience de l'utilisateur. J'aimerais comprendre pourquoi beaucoup de gens pensent le contraire.

La plupart des utilisateurs n'aiment pas les applications Web s'ils savent qu'il s'agit d'une application Web, pourquoi ? Parce qu'une mentalité auparavant courante du Web était que lorsqu'il apparaît à l'écran, c'est fait, peu importe à quel point il s'est mal comporté et les utilisateurs ont appris que le Web est mauvais. Cependant, il est parfaitement possible de créer une excellente UX sur le Web, mais pour ce faire, je dois posséder le DOM. Si quelqu'un injecte des bannières aléatoires à des endroits arbitraires, le mauvais élément peut commencer à défiler, ou cela peut entraîner le repeint de tout l'écran lors du défilement ou cela peut interférer avec, par exemple, les gestes de glissement ou autre chose. Le fait est que tant que cette bannière est en place, je ne peux pas développer parce que je ne peux pas savoir que l'expérience est la même lorsque cette bannière est partie.

En tant que solution de framework, j'aime beaucoup l'idée de favicon, elle n'entrave pas le développement, elle n'a pas l'air étrange pour les utilisateurs, elle ne détruit peut-être pas l'UX mais elle se fera remarquer. Cependant, cela ne fonctionne vraiment que pour une seule bibliothèque ou un seul cadre à la fois et cela ne fonctionne pas du tout pour les bibliothèques qui s'exécutent dans les travailleurs. La vraie solution est un bon moyen de le faire via le navigateur qui peut prendre en charge plusieurs frameworks et bibliothèques et est accessible depuis tous les contextes.

Une autre solution qui prend en charge plusieurs frameworks et bibliothèques et qui est plus claire, mais nécessite une demande d'autorisation, consiste à afficher une notification du navigateur.

Voici une idée : mettez à jour les documents de démarrage sur la page d'accueil de React pour pousser plus fortement la création de l'application React. Et insistez sur l'importance de npm build dans ces documents. Nous n'avons pas besoin d'un avertissement DOM, nous avons besoin de sensibilisation.

Je pense que @ropilz en a parlé plus tôt dans le fil avec son commentaire "_..nous pourrions même lier n'importe quel service que nous voulons notifier aux développeurs.._", mais cela peut être passé inaperçu (ou non reconnu).

Si je comprends bien, le problème fondamental résolu ici est

• pour alerter d'une manière ou d'une autre les _développeurs_ lorsque les _utilisateurs finaux_ de la production découvrent un site fonctionnant en mode développement
• nous ne pouvons pas compter sur les développeurs pour voir les messages console.log (ou même les avertissements DOM d'ailleurs) en production, _à moins que_ ces développeurs utilisent activement le site de production eux-mêmes (ou nous comptons sur les utilisateurs finaux, QA/ équipes d'assistance, etc. pour signaler ces avertissements au développeur)
• il existe des arguments UX (valides) _against_ montrant aux utilisateurs finaux un avertissement visible DOM destiné au public des développeurs.

Et s'il y avait quelque chose d'analogue au report-uri de CSP, pour que les frameworks envoient des avertissements en mode développement, plutôt que d'afficher un avertissement in situ sur le site où ils seraient visibles pour les utilisateurs finaux ?

Évidemment, il y a un certain nombre de choses à considérer, telles que :

1. De tels rapports seraient idéalement activés par défaut, mais quelle serait la valeur par défaut report-uri ? (nous attendrions-nous à ce que chaque framework héberge son propre service gratuit, similaire à https://report-uri.io ? (ceci est _peut-être_ possible pour les grands frameworks sponsorisés par l'entreprise comme React & Angular ; mais certainement pas pratique pour les petits frameworks open source comme Preact, Vue etc.)
2. Une fois qu'un avertissement a été signalé, comment le propriétaire/développeur du site est-il informé ? (peut-être un bon moyen pour les non-développeurs de s'impliquer dans un projet, en se portant volontaire pour surveiller ces rapports et aider à retrouver/notifier le mainteneur ?)

J'admets pleinement que cette suggestion n'est qu'une bulle de pensée, et je n'ai pas envisagé à quel point cela serait pratique ou comment cela fonctionnerait réellement; mais je voulais le soulever car il me semble que le défi du "rapport sur les problèmes de production" a déjà été partiellement résolu pour les rapports CSP/HPKP, et peut-être pourrions-nous explorer quelque chose de similaire ici ?

Il est important de prendre du recul et de réaliser que React est un framework. Vous ne devez pas :

• Modifiez le DOM pour présenter quelque chose visuellement juste comme un rappel pour les développeurs . Il n'y a aucun moyen que cela fonctionne bien hors de la boîte à moins que vous ne compreniez et ne développiez quelque chose qui peut fonctionner dans tous les environnements sans gêner les développeurs et perdre la confiance de leurs utilisateurs si cela devait arriver en production (si mon expérience est une indication que cela arrivera assez fréquemment et beaucoup ne seront pas en mesure de déployer une solution rapide pour le désactiver).

• Modifiez le favicon. Le favicon est mis en cache de manière agaçante, utilisé pour les signets, les icônes d'applications Web enregistrées sur les appareils mobiles si d'autres ne sont pas spécifiés, etc.

• Notifications du navigateur. Lorsque vous êtes regardé, vous êtes probablement regardé par un utilisateur. L'affichage d'une notification va demander des autorisations de navigateur et afficher des choses étranges que les utilisateurs ne comprendront pas. L'hypothèse selon laquelle ceux-ci seraient principalement vus par les développeurs, d'après mon expérience, est exactement inverse et pourrait ruiner la confiance des utilisateurs.

Ce n'est pas le travail de React de garder les développeurs. Je propose soit :

1. Activez le mode de développement. Lorsque les développeurs réalisent qu'ils ne peuvent pas déboguer quelque chose, ils recherchent comment l'activer (ce qui doit être documenté partout ). Non, ce n'est pas le travail de React de leur dire de le désactiver. Leur problème.

2. Laissez-le à un simple message console.log (et cela doit être désactivé). Laissez les développeurs le trouver et le gérer. S'ils ne le font pas, tant pis. Vous ne pouvez pas toucher toutes les organisations et leur faire faire les choses correctement. Ce n'est tout simplement pas évolutif.

Je ne suis pas d'accord avec le fait de toucher le DOM pour afficher un avertissement. Cela semble facile et simple pour React car c'est une bibliothèque DOM, mais imaginez si toutes les bibliothèques doivent afficher leur propre avertissement dans le DOM. Ce sera un gâchis total.

Il y a tellement de bibliothèques que les développeurs utilisent qui ont probablement leur propre mode de développement. Je pense que définir process.env.NODE_ENV sur production a déjà été une norme courante dans le regroupement de modules pour navigateur. C'est ce dont nous devons améliorer la prise de conscience.

Je conviens que les documents React ne montrent pas clairement qu'il existe une différence entre le développement et la production. Lorsque vous ouvrez la documentation, vous devez parcourir les guides avancés pour lire la différence entre le développement et la production. Le titre est Optimizing Performance , quelque chose que les débutants ne regarderont certainement pas car ils utilisent React parce qu'ils ont entendu dire que c'était rapide. Je pense que la documentation pourrait être améliorée pour avoir une autre documentation intitulée "Utilisation de React en production" ou similaire dans la section Démarrage rapide .

Les débutants ne lisent généralement pas les guides avancés, mais ils ouvriront certains liens dans le démarrage rapide si le titre est suffisamment clair et semble important. Je sais que je l'ai fait parce que c'est ce que je fais quand je commence à apprendre React. Je n'ai pas lu le guide de démarrage, mais j'ai lu certaines pages de la section Démarrage rapide.

Une autre approche que nous pourrions adopter consiste à afficher un avertissement dans la console lorsque React est utilisé en mode de développement avec un lien pour corriger ce point vers la documentation. L'ouverture de la console en production pour les développeurs est inhabituelle, mais dans l'environnement local lors du développement, ils ouvriront certainement la console. De cette façon, lors du développement local, ils seront conscients qu'ils doivent faire quelque chose avant de publier en production.

http://code.gov lancé malgré les avertissements de la console. C'est exactement le genre de choses que nous devrions viser à prévenir. (Ce site est angulaire, mais il en va de même pour React)

Voici le problème pour code.gov si quelqu'un veut les contacter (ou envoyer 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.

Je n'ai jamais utilisé Angular 2 auparavant (ce qui fait de moi un débutant dans ce cas). Ma première réaction après avoir vu l'avertissement est que j'essaie simplement d'appeler enableProdMode() . Cela ne fonctionne pas. Je pense que le message de la console pour le cas angulaire pourrait être amélioré. Au lieu de compter sur la magie, ils devraient pointer vers les docs.

En ouvrant la documentation angulaire, je ne vois rien sur la construction de production. Je pense que c'est un problème pour Angular et React. Ils utilisent tous les deux le mode de développement, mais ils ne disent pas aux gens à l'avance dans la documentation comment le désactiver. C'est pourquoi l'amélioration de la documentation pourrait contribuer grandement à l'éducation des développeurs

Je ne suis pas contre l'avertissement des utilisateurs lorsque les développeurs font des "erreurs", mais injecter un élément DOM aléatoire est tout simplement intrusif. J'aime la façon dont les navigateurs gèrent le problème HTTPS où le navigateur a une interface utilisateur dédiée pour montrer que le site n'est pas sécurisé. Nous n'en avons pas pour le statut lié aux performances. Compte tenu des préoccupations croissantes concernant les performances Web en général, je ne vois pas pourquoi le fournisseur de navigateur ne propose pas de moyens de dire à l'utilisateur que le site qu'il visite est nul.

Cela devrait être résolu au niveau de l'outillage, donc éventuellement webpack et Babel peuvent informer les développeurs des avantages de la définition d'un NODE_ENV.

@pveyes D'accord, j'ai fait la même remarque à l'équipe Angular.

@matthewp il y a un problème beaucoup plus ancien à ce sujet https://github.com/presidential-innovation-fellows/code-gov-web/issues/129 et l'équipe angulaire a contacté directement et leur a donné le correctif - il semble y avoir petite envie de l'appliquer. La question est, un avertissement DOM aurait-il rendu ce correctif plus urgent ou l'aurait-il empêché de se lancer en mode de développement pour commencer?

La question est, un avertissement DOM aurait-il rendu ce correctif plus urgent ou l'aurait-il empêché de se lancer en mode de développement pour commencer?

Plus que probablement, ils verraient l'avertissement en cours de développement, Google comment le désactiver et le désactiver. Puis déployé en mode dev sans s'en rendre compte dans le futur car ils oublient. Pendant le développement, vous voulez qu'il ressemble à la production afin que vous ne puissiez pas insérer un morceau aléatoire de DOM. Vous ne pouvez pas non plus avoir un système d'assurance qualité ou de mise en scène qui voit cela, car cela ne serait pas indicatif de la production.

Donc, vous vous retrouvez avec un tas de code indésirable désactivant cette chose qui se fout de l'UX du site. Ce n'est pas comme si l'ingénieur d'origine qui l'avait désactivé pendant le développement s'en souviendrait nécessairement non plus ; ils ont peut-être même évolué avant qu'il ne soit mis en production.

Je ne sais pas comment le processus de déploiement fonctionne sur code.gov, mais si cela ressemble à ce que j'ai vécu en tant qu'entrepreneur gouvernemental, un déploiement accidentel en mode de développement en production serait :

1. Forcez un retour en arrière complet de l'ensemble du déploiement (dont certains prennent 6 mois pour obtenir l'approbation et regrouper tout, des modifications de l'interface utilisateur aux mises à jour du logiciel du serveur), probablement le lendemain, puis vous obtenez des réunions et des documents de suivi concernant ce qui s'est passé et planifier une nouvelle fenêtre de déploiement (on vous demandera, encore et encore, si les scripts ou services de base de données ou quoi que ce soit étaient tous en mode dev en raison d'un seul avertissement dans l'interface utilisateur). J'ai vu cela se produire pour des choses très mineures. Parfois, vous pouvez obtenir des exceptions, mais YMMV.

2. Cela serait remarqué par les utilisateurs, il serait corrigé, mais comme cela n'affecterait probablement pas la fonction, il ne serait pas mis à jour avant la prochaine fenêtre de déploiement. Ainsi, tous les utilisateurs peuvent le voir pendant des semaines ou des mois.

Du moins, ce fut mon expérience. Le fait est que même si une intrusion DOM est remarquée immédiatement après le déploiement, vous ne savez pas à quoi ressemble leur infrastructure / processus et ce n'est peut-être pas quelque chose qu'ils peuvent réparer immédiatement (même s'ils devraient pouvoir le faire).

Les messages d'avertissement seront plus visibles lorsque #7360 (boîte jaune) sera fusionné. Nous pourrions également ajouter un message à la case jaune (appelez-le "Réagir aux avertissements du mode de développement" ?).

En ouvrant la documentation angulaire, je ne vois rien sur la construction de production. Je pense que c'est un problème pour Angular et React. Ils utilisent tous les deux le mode de développement, mais ils ne disent pas aux gens à l'avance dans la documentation comment le désactiver. C'est pourquoi l'amélioration de la documentation pourrait contribuer grandement à l'éducation des développeurs

C'est juste sur la page d'installation :

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

Et sur l'optimisation des performances :

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

Je ne pense pas qu'il soit juste de dire que les docs ne sont pas francs à ce sujet.

Lorsque vous ouvrez la documentation, vous devez parcourir les guides avancés pour lire la différence entre le développement et la production. Le titre est Optimiser les performances, quelque chose que les débutants ne regarderont certainement pas car ils utilisent React parce qu'ils ont entendu dire que c'était rapide. Je pense que la documentation pourrait être améliorée pour avoir une autre documentation intitulée "Utilisation de React en production" ou similaire dans la section Démarrage rapide.

C'est juste là, sur la toute première page (Installation):

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

Vous avez raison. Désolé mon mauvais. J'ai supposé que la version de production se trouve dans une section différente, donc je n'ai pas regardé là-bas et j'ai plutôt recherché le titre pertinent dans la barre latérale (et j'ai trouvé la page Optimisation des performances). J'aurais dû savoir mieux.

Je ne suis pas vraiment un débutant pour React, c'est pourquoi lorsque j'ouvre les docs pour vérifier mon hypothèse - que les docs React ne sont pas franches sur la prod vs dev - je n'ai pas ouvert les docs d'installation 🙇

Pas de soucis. Si ce n'est pas assez visible, je suis ouvert aux suggestions pour un meilleur placement. Par exemple, nous pourrions créer une page dédiée pour cela ( Deploying to Production ).

N'oublions pas que ce problème est un problème important à résoudre mais pas le problème le plus important à mettre en évidence. Je ne suis pas non plus convaincu que ce sera suffisant même s'il est mis en évidence en première page, car les gens le verront et le parcourront, l'oublieront et penseront "Je sais ce que je fais". Donc, je ne ferais pas trop pivoter sur la chose docs.

La seule véritable façon d'y remédier est de détecter et de notifier.

@KrisSiegel Le favicon mis en cache est un bon point. Je me demande si nous devrions simplement le changer après une seconde ou deux, puis le retourner brièvement toutes les quelques secondes. De cette façon, le problème de mise en cache et de mise en signet est très peu susceptible de le chronométrer au moment de l'icône remplacée.

Je pensais que les manipulations JS vers favicon n'étaient pas mises en cache, mais peut-être que je me trompe.

Je dirais que le bon endroit pour avoir des crochets pour cela n'est pas Chrome ou Firefox, mais plutôt webpack, Browserify ou Rollup.

Construire ce qui est destiné à être un bundle de production pour React mais sans activer le mode de production n'est que cela - une erreur de construction. Je pense que la raison pour laquelle il n'y a pas d'accord sur la façon de présenter cela au moment de l'exécution reflète le fait que ce n'est pas un problème qui devrait être traité au moment de l'exécution.

@taion Je suis d'accord. Je pense que cela appartient définitivement à l'outil de construction, pas au DOM.

Je pense que ce devrait être l'emplacement des outils de construction pour faire l'hypothèse que node env doit être défini sur production pour le code de production. Ce n'est peut-être pas nécessaire pour tous les projets, mais je pense que c'est une bonne hypothèse.

Si npm run build est exécuté dans le terminal et que l'environnement n'est pas défini sur production, vous devriez recevoir un avertissement rouge dans le terminal avec la sortie par défaut : env is not set to production, some scripts may be in development mode

Actuellement, je ne reçois aucun avertissement de ce type de Webpack.

Edit : ajout de précisions

Ou définissez simplement NODE_ENV pour vous, vraiment.

Si les avertissements de la console ne fonctionnent pas, je ne suis pas sûr que les avertissements de construction le feront.

La construction doit soit configurer les choses pour vous, soit échouer si elle est mal configurée pour la production. Au moins pour React, ceci _est_ un indicateur de temps de construction.

@jakearchibald Je suis sûr qu'il sera toujours ignoré par certains, mais au moins l'avertissement leur serait montré lors de sa construction, au lieu de ne pas être vu car l'avertissement est caché dans la console du navigateur qu'ils ne peuvent jamais ouvrir en production . Plus important encore, cela donne à ceux qui ont moins d'expérience une idée de ce qu'ils doivent faire pour préparer la production de code.

Alors que de nombreux développeurs mettront à jour les bibliothèques, il est courant de ne pas mettre à jour Webpack et plus généralement les outils, car beaucoup de gens supposent que cela fonctionne, et il peut être pénible de mettre à jour Webpack et co.

Construire ce qui est destiné à être un bundle de production pour React mais sans activer le mode de production n'est que cela - une erreur de construction.

L'utilisation d'une version préemballée de React à partir d'un CDN est également une configuration prise en charge , mais il n'y a aucune étape de construction dans ce flux de travail. Par conséquent, une solution à ce problème qui se concentre uniquement sur la construction ignorerait le cas d'utilisation du CDN.

Honnêtement, je ne suis pas sûr de ce que je ressens à ce sujet ; Je peux voir des arguments à la fois pour et contre les avertissements de développement pour l'utilisation de React CDN.

@taion En tant que personne qui prend en charge une solution de construction uniquement, pensez-vous qu'il s'agit d'un cas d'utilisation important à couvrir ?

Qu'en pensent les autres ?

Je pense que la documentation est assez claire sur le fait que vous devez utiliser les bundles .min.js pour la production. Peut-être qu'il pourrait utiliser un gras, une taille de police plus grande, quelque chose comme ça. Mais si quelqu'un utilise le bundle React non minifié en production pour son site Web, il a de toute façon d'autres problèmes.

Je pense que la documentation est assez claire sur le fait que vous devez utiliser les bundles .min.js pour la production.

D'accord, mais la page est également assez claire sur la façon de configurer votre outil de construction pour la production si vous incluez React en tant que package npm. Je pense que le but de ce problème était d'essayer de créer un puits de succès pour les gens qui ne lisent pas attentivement cette page de documentation.

Cependant, il semble que vous ne soyez pas d'accord et que vous pensiez que l'utilisation de la version de développement à partir du CDN n'est pas un cas important à prévenir avec un avertissement de développement plus agressif. Est-ce un bon résumé de votre position, ou ai-je raté certaines nuances?

Je pense que la configuration CDN + dev est plus manifestement erronée, en ce sens qu'elle oblige l'utilisateur à utiliser une version non minifiée de React. Il est plus difficile d'échouer de cette manière car la charge de connaissances requise pour _utiliser simplement la construction minifiée_ est plus faible.

La configuration où vous _pensez_ que les choses sont prêtes pour la production parce que vous avez exécuté la minification dans webpack ou Browserify mais en fait vous ne l'êtes pas parce que vous n'avez pas défini NODE_ENV - vous ne pouvez pas l'obtenir via les bundles CDN.

Je pense que l'onglet React sur Chrome Developer Tools est suffisant pour indiquer si nous sommes dans DEV Mode .

Je pense qu'il convient de noter qu'il existe un précédent pour un framework injectant un élément DOM dans la page en mode dev :

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

Bien que pour autant que je sache, je ne pense pas que ce soit activé par défaut.

Suite à la discussion ci-dessus, il semble y avoir un objectif général pour parvenir à une solution parfaite qui satisfait toutes les contraintes mais empêche de manière fiable tout le monde de fonctionner en mode de développement alors qu'il ne devrait pas l'être. L'OP a déclaré qu'il devrait y avoir un compromis entre les expériences potentielles pour les développeurs et les utilisateurs, et je pense que c'est tout à fait le cas.

Pour tenter de reformuler un peu le problème :

• Un nombre non nul de sites React passe en production sans mode de développement désactivé
• Nous aimerions réduire ce nombre
• Nous ne voulons pas ennuyer les développeurs de React
• Nous ne voulons pas décourager les nouveaux arrivants de React
• Nous ne voulons pas que les utilisateurs finaux des sites construits dans React voient les avertissements cyptiques des développeurs
• Nous ne voulons pas casser les sites en raison de la présence d'éléments DOM étrangers

Compte tenu de cela, je pense qu'une première étape décente serait que React en mode dev annonce qu'il est en mode dev via un console.warn ou console.info avec des instructions pour s'assurer que cela est désactivé pour la production déploiement.

Bien sûr, cela n'attrapera pas tout le monde, mais _c'est un bon début_ qui devrait réduire le nombre de personnes qui expédient par inadvertance à la production et ne ferme aucune porte à de futures améliorations.

Compte tenu de ceux-ci, je pense qu'une première étape décente serait que React en mode dev annonce qu'il est en mode dev via un console.warn ou console.info avec des instructions pour s'assurer que cela est désactivé pour le déploiement de production.

Ce n'est pas mal qu'il soit en mode développement quand vous... développez. Quelles autres heuristiques pourrions-nous utiliser ?

De plus, étant donné que personne ne lit la console en production, je me demande si nous pourrions ajouter un délai d'attente afin qu'il soit enregistré si vous utilisez des solutions de rapport d'incident.

Ce n'est pas mal qu'il soit en mode développement quand vous... développez. Quelles autres heuristiques pourrions-nous utiliser ?

Je pense que cela devrait être similaire à l'avis actuel de React DevTools

Un message d'information qui vous rappelle que vous êtes en mode dev et que le mode dev doit être désactivé pour les sites de production. Cela (en théorie) devrait faire prendre conscience à davantage de développeurs qu'il existe une distinction et que certaines mesures doivent être prises pour se préparer à une utilisation en production.

Comme vous le dites, presque personne ne verra un avertissement de console dans la production réelle - et à ce stade, il est un peu tard.

Désolé de sonner comme un enregistrement bloqué, mais les avertissements de la console ne semblent pas fonctionner. Par exemple https://code.gov.

Désolé de sonner comme un enregistrement bloqué, mais les avertissements de la console ne semblent pas fonctionner. Par exemple https://code.gov.

Une seule contre-instance montre que ce n'est pas infaillible - mais je ne pense pas que n'importe quelle approche le sera.

Si un avertissement de la console est capable d'augmenter la sensibilisation et de réduire le nombre de personnes qui exécutent par erreur le mode de développement alors qu'elles ne le devraient pas, cela semble être un pas dans la bonne direction. Le parfait est l'ennemi du bien.

@jakearchibald

Oui, mais si l'outil de construction de code.gov était configuré avec des crochets ici, cela _aurait_ empêché le problème que vous observez, du moins dans le contexte de React qui utilise des crochets au moment de la construction pour cela. Ils utilisent Webpack après tout.

Je ne dis pas que webpack devrait émettre un avertissement de construction. Je dis que la bonne solution est que soit Webpack définit process.NODE_ENV pour vous, soit que Webpack échoue simplement la construction par défaut si vous essayez de créer une version de production sans configuration de production appropriée.

Je voulais répondre rapidement à un point précédent de @addyosmani à propos des "violations" de DevTools. Nous prototypons en montrant des indications plus fortes de certaines erreurs dans Chrome DevTools, mais ce travail est encore assez tôt, et j'ai tendance à être d'accord avec @jakearchibald que montrer un avertissement (même s'il est plus effrayant que console.warn ) n'est pas une assez bonne solution.

Qu'en est-il de l'activation par défaut de React en mode production et de l'activation du mode développement si et seulement si NODE_ENV == 'development' ou le nom d'hôte est localhost / 127.0.0.1 ? La plupart des développeurs obtiendront un comportement correct prêt à l'emploi et il y aura toujours un moyen de forcer manuellement le mode de développement si vous en avez vraiment besoin.

Il semble moins qu'idéal de continuer à frapper cette branche avec ce qui pourrait être une condition assez compliquée (puisque vous n'auriez pas besoin de simplement échouer sur Node) tout le temps.

BTW, -p (mode "production", qui permet également la minification avec les paramètres par défaut) dans les ensembles webpack 2 NODE_ENV pour les utilisateurs : https://webpack.js.org/guides/production-build /#node -variable-d'environnement.

Cela me semble tout à fait sensé et devrait simplement éviter ce problème pour presque tout le monde utilisant webpack. Pourquoi l'insistance sur la gestion de tout cela au moment de l'exécution?

BTW, -p (mode "production", qui permet également la minification avec les paramètres par défaut) dans le webpack 2 définit NODE_ENV pour les utilisateurs : https://webpack.js.org/guides/production-build/#node -environment-variable.

Ouais. Nous en sommes conscients. @TheLarkInn de Webpack core pourrait confirmer avec certitude, mais je crois comprendre que -p n'est pas largement utilisé dans la communauté Webpack atm. Le problème sous-jacent ici est également que si une solution est opt-in, similaire au statu quo actuel avec les avertissements console.log, il est peu probable que nous voyions un réel changement pour les utilisateurs de React. Nous voulons donner aux gens un meilleur changement pour expédier la chose «rapide».

Il convient de mentionner au passage que le fait de ne pas pouvoir détecter facilement les environnements DEV et PROD dans Webpack (-p étant insuffisant) nous a également causé quelques soucis dans https://github.com/webpack/webpack/issues/3216.

Je dis que la bonne solution est que soit webpack définit process.NODE_ENV pour vous, soit que webpack échoue simplement la construction par défaut si vous essayez de créer une version de production sans configuration de production appropriée.

Je suis partant pour que nous poursuivions cela, mais ce serait un changement radical pour Webpack d'après ce que je peux dire. Personnellement, j'ai l'impression qu'une solution d'exécution qui implique un message de superposition clair _uniquement_ affiché à l'aide de quelques heuristiques intelligentes (localhost, DevTools ouvert, etc.) nous couvrirait de manière adéquate.

Cela dit, alors que nous revenons sans cesse à l'élément Webpack process.NODE_ENV, je serais curieux de savoir si @sokra ou @TheLarkInn avaient des opinions sur celui-ci.

Ma compréhension diffère de la vôtre - je pense que -p est la manière de facto par laquelle la plupart des utilisateurs non experts de webpack configurent des versions de production.

Même les packages les plus importants utilisent -p pour générer des versions de production :
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

Il est assez rare de configurer directement le plugin Uglify dans webpack, donc sans -p , les gens utiliseraient des versions non minifiées, auquel cas ils auraient de plus gros problèmes.

Personnellement, j'ai l'impression qu'une solution d'exécution qui implique un message de superposition clair affiché uniquement à l'aide de quelques heuristiques intelligentes (localhost, DevTools open, etc.) nous couvrirait de manière adéquate.

J'ai l'impression que cela a été abattu plusieurs fois ("Il est inacceptable qu'un framework injecte des choses dans le DOM") sans réellement apprécier le _seul_ scénario dans lequel cela se produirait.

Je suis totalement d'accord avec vous pour dire que devoir constamment faire face à un message permanent et à des choses inattendues dans le DOM pendant le développement est inacceptable. Ce que nous suggérons ici, cependant, est un message qui s'affiche si et _uniquement_ si DevMode est déployé en production (entrez dans l'heuristique !). Un nombre arbitraire de vérifications et de messages de console peut être intégré dans les outils, les CI et les extensions de navigateur pour empêcher que cela ne se produise.

Mais en tant que solution de secours désespérée et de dernier recours, je pense qu'une bannière visible à l'écran est une bonne solution appropriée.

affiché si et seulement si DevMode est déployé en production (entrez dans l'heuristique !)

Ainsi, un développeur ne verra jamais ce message, déploiera (peut-être accidentellement) le mode de développement en production et verra soudainement ce nouveau code HTML affiché sur son application pour que tous ses utilisateurs le voient ?

Cela ressemble plus à une punition pour moi. Si vous ne comprenez pas déjà le mode de développement et que vous déployez en utilisant cette nouvelle version théorique de React avec le message, vous allez avoir une surprise et vos utilisateurs sur l'application Web à ce moment-là pourront également le voir. Je ne vois pas comment cela aide quiconque mais sert à embarrasser le développeur ou l'entreprise. Bien sûr, cela les incitera peut-être à le réparer, mais ce coût est trop élevé à mon avis et manque un peu d'empathie.

Mais en tant que solution de secours désespérée et de dernier recours, je pense qu'une bannière visible à l'écran est une bonne solution appropriée.

Le problème avec cette solution est qu'elle est beaucoup trop idéaliste et lorsque vous développez un framework, vous devez vous concentrer sur le fait que d'autres entreprises peuvent ne pas avoir les meilleures politiques de déploiement ou même la meilleure QA (le cas échéant).

Oui, si quelqu'un déploie en mode développement en production, il devrait pouvoir le voir et le modifier rapidement. Malheureusement, surtout en dehors de l'industrie technologique, ce n'est tout simplement pas possible ou pas facile . La majorité des gens qui commentent ici? Leurs entreprises ont probablement des processus de déploiement qui pourraient très bien faire face à ce scénario. Google, Facebook, PlayStation, etc. toutes ces entreprises technologiques peuvent gérer cette amende, mais ce n'est pas représentatif de la majorité des utilisateurs qui utilisent React, n'est-ce pas ? (en fait, avons-nous des statistiques concernant l'utilisation de React ? Ce serait pratique !)

Oui, oui, ces entreprises et le gouvernement devraient modifier leurs processus et politiques de déploiement, etc. Mais la réalité est la suivante : la plupart des entreprises ont des processus de déploiement merdiques et une assurance qualité inexistante.

Prenons deux scénarios dans lesquels j'ai personnellement vécu.

Tout d'abord, lorsque vous travaillez au sein du gouvernement, selon la direction générale et le département, vous avez probablement un seul déploiement tous les 3 à 6 mois. Ces déploiements rassemblent autant de choses que possible et si une partie de l'ensemble du déploiement échoue, tout peut être annulé. Nous utilisions donc ce logiciel appelé OWF qui, si vous n'êtes pas familier, est comme iSocial en ce sens qu'il affiche plusieurs applications Web dans une seule application Web en utilisant des iframes (grossier, je sais, mais restez avec moi ici). Il y a eu une étape de configuration manuelle dans le déploiement de plusieurs de nos applications qui a échoué, ce qui a provoqué l'affichage d'erreurs 404 et 500 dans certaines des iframes au lieu de l'application prévue.

Étant donné que les développeurs n'ont généralement pas accès au système en cours de déploiement, il a fallu de nombreuses heures avant que nous découvrions des problèmes. À ce moment-là, nous avons dû demander à notre patron d'appeler le patron de quelqu'un d'autre pour appeler son patron pour lui dire que cela n'affectait rien d'autre afin qu'il n'annule pas tout le déploiement. Ensuite, nous avons eu des tonnes de paperasse et de documentation à remplir avant de pouvoir demander à quiconque de refaire une partie de la configuration plusieurs jours plus tard. Pendant ce temps, l'application est restée immobile, incapable de fonctionner, pendant toute cette période.

Deuxièmement , lorsque je travaillais dans la finance, nous avons eu un déploiement qui incluait par inadvertance le nom d'un développeur à la place de la mise en page d'un élément réel sur le site Web (je crois qu'il testait quelque chose ?). Quoi qu'il en soit, cela a été remarqué tout de suite, mais pour le réparer, nous avons dû obtenir un contrôle de changement d'urgence qui a duré beaucoup plus tard dans la journée. Ainsi, leurs clients ont dû voir cette stupide bannière pendant près de 8 heures complètes avant qu'elle ne soit réparée.

Mon point étant: il faut faire très attention lors de l'injection d'éléments arbitraires dans le DOM que le développeur n'y a pas mis. Surtout si nous parlons de ne l'afficher que dans certains scénarios, la première fois que quelqu'un le verra, il trouvera comment le désactiver rapidement afin qu'il n'ait plus besoin d'être dérangé par cela.

@KrisSiegel

Si vous ne comprenez pas déjà le mode de développement et que vous déployez en utilisant cette nouvelle version théorique de React avec le message, vous allez avoir une surprise et vos utilisateurs sur l'application Web à ce moment-là pourront également le voir.

J'étais curieux de savoir si vos réflexions sur l'approche étaient différentes si le message n'était affiché que lorsque DevTools était ouvert (c'est-à-dire quelque chose qui aurait peu de chances d'être vu par des utilisateurs de production qui ne sont pas des développeurs). En fait, une extension de la stratégie console.log actuelle que React utilise déjà aujourd'hui.

J'étais curieux de savoir si vos réflexions sur l'approche étaient différentes si le message n'était affiché que lorsque DevTools était ouvert (c'est-à-dire quelque chose qui aurait peu de chances d'être vu par des utilisateurs de production qui ne sont pas des développeurs). En fait, une extension de la stratégie console.log actuelle que React utilise déjà aujourd'hui.

Si vous avez des outils de développement ouverts, vous voyez probablement des messages console.log, de sorte que les modifications du DOM semblent être une complexité inutile à gérer et qu'elles sont redondantes. Vous pouvez toujours rendre les messages de la console React plus grands / plus sophistiqués. Peut-être un logo ASCII React. Quelque chose pour attirer l'attention de quelqu'un s'il devait y entrer.

En fin de compte, bien que je pense que quelqu'un se heurterait à cela, demandez sur Stackoverflow comment désactiver l'avertissement, quelqu'un publiera un code leur montrant comment le faire, puis les gens le désactiveront simplement s'ils le rencontrent. Les outils de construction sont nombreux et de nombreuses personnes à qui j'ai parlé dans le passé les ont trouvés déroutants ou difficiles (la sortie de Babel 6 était une période "amusante"). Vous allez rencontrer beaucoup de gens qui ne les utilisent tout simplement jamais correctement.

C'est du moins mon expérience ¯\_(ツ)_/¯

Ouf, enfin rattrapé au fond du fil. D'accord. J'ai un peu réfléchi à cela.

Webpack pourrait forcer la spécification de NODE_ENV que React pourrait ensuite utiliser pour éviter plus facilement que les gens envoient DEV à PROD, mais ce serait un changement radical pour Webpack. Je parle maintenant à Sean de la faisabilité de quelque chose comme ça pour Webpack 3. Je sais que les deux camps se soucient de garder la pile React + Webpack pour débutants et perf.

Cela a semblé être mon préféré jusqu'à présent, mais je ne suis pas encore vendu à 100%.

1. Cela pourrait donc imposer qu'un ENV soit transmis chaque fois que quelqu'un exécute webpack. Un message d'erreur utile indique que vous devez fournir une variable env pour exécuter webpack.

Cependant, cela fournit un point de rebond important pour les utilisateurs. Tout le monde n'écrit pas pour un env prod ou dev ou ne sait même pas ce qu'est un env. Je vais soulever un problème sur webpack/webpack pour obtenir des commentaires à ce sujet, car mon instinct est que tout le monde ne le voudra pas et que je sois d'accord ou non, nous devons envisager le refoulement.

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

2. La solution webpacky serait de créer un plugin autonome qui pourrait se connecter au cycle de vie du compilateur, vérifier si le code est supprimé ou si une ENV n'est pas fournie, et émettre un avertissement convivial ou une erreur de votre choix.

Cependant, je peux imaginer que la réponse est "Mais les utilisateurs ne sauront jamais comment faire cela, etc." Ainsi l'ARC, donc cette question en ce moment.

Nous pourrions créer un nouveau modèle de résolveur qui vérifiera le package.json de React (ou tout fw qui en a besoin) pour quelque chose comme ci-dessous :

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

cela s'appliquerait automatiquement à la configuration du compilateur d'un utilisateur sans qu'il ait besoin de le savoir ou de s'en soucier.

Encore une fois, vraiment un remue-méninges.

@TheLarkInn Je pense que le comportement actuel de -p dans le webpack 2 est suffisant, non ? Le seul cas d'échec est si quelqu'un configure lui-même UglifyJsPlugin et oublie de faire DefinePlugin , mais cela semble être un cas beaucoup moins probable.

@taion Oui/Non

-p n'applique que des "traitements" de production à votre code, mais nous ne faisons aucune hypothèse et/ou n'avons aucune connaissance de ce à quoi NODE_ENV est défini. C'est ce qui amène les gens à utiliser DefinePlugin() .

Mais je pense que c'est la zone "_raisonnable_" la plus proche de _deviner_ ou _impliquer_ que l'utilisateur exécute son code dans une ENV de production. Ce serait le seul domaine dans lequel nous voudrions nous assurer que la communauté et l'équipe sont d'accord.

@TheLarkInn Je crois que cela a changé dans la v2 : https://webpack.js.org/guides/production-build/#node -environment-variable

Ah désolé c'est vrai je me trompe. Cependant, il n'est pas utilisé fréquemment parce que les gens veulent un contrôle plus précis sur ce qu'ils optimisent. (Comme @addyosmani mentionné)

Est-ce vraiment si courant ? Lorsque j'ai commencé avec Webpack, -p semblait clairement être la voie à suivre. Comme je l'ai mentionné ci-dessus, même les bibliothèques ayant de nombreuses raisons d'appliquer d'autres modifications utilisent toujours -p .

Nous pourrions créer un nouveau modèle de résolveur qui vérifiera le package.json de React (ou tout fw qui en a besoin) pour quelque chose comme ci-dessous :

"webpack": {
"plugin": "ReactEnviornmentPlugin"
}
cela s'appliquerait automatiquement à la configuration du compilateur d'un utilisateur sans qu'il ait besoin de le savoir ou de s'en soucier.

@TheLarkInn si je lis ceci correctement, pour déclencher le modèle de résolveur, le package.json d'une application devrait spécifier manuellement le ReactEnvironmentPlugin , n'est-ce pas? Ou ai-je mal compris la proposition? :)

Je pourrais imaginer une magie de résolution dans Webpack qui détecte qu'un projet utilise React et fait le bon changement d'environnement pour eux, mais cela ressemble à un couplage étroit de l'optimisation spécifique au framework à un bundler et pourrait ne pas être aussi souhaitable.

Moins qu'il détecterait réagir, et plus qu'il détecterait un champ de description de modules js incluant un champ webpack avec un plugin. Mais vous avez raison, c'est très étroitement couplé et ce n'est pas vraiment mon idée préférée non plus.

Je ne pense pas que cela vous donne vraiment des garanties à moins que Webpack n'ait un concept de mode "production" pour comprendre comment configurer React - et cela semble redondant étant donné que, comme indiqué ci-dessus, -p fait déjà le bon chose, et c'est ce que les utilisateurs rechercheront généralement lors de la création d'une version de production minifiée avec webpack de toute façon.

Nous en avons parlé un peu plus et je pense qu'il existe une solution raisonnable.

Nous envisageons depuis longtemps d'activer une "boîte d'avertissement" pour les avertissements React en cours de développement. Vous pouvez voir une démo ici (PR : https://github.com/facebook/react/pull/7360). Il n'apparaît que lorsque vous avez des avertissements, mais ils sont très courants pendant le développement (et doivent toujours être corrigés), donc toute personne ayant passé plus de cinq minutes à développer une application verra la boîte de dialogue et saura qu'elle existe.

Après ce changement, il sera plus difficile d'ignorer le mode de développement. Vous chercherez probablement "comment supprimer la boîte de dialogue d'avertissement" et découvrirez comment créer pour la production. Si vous ne le faites pas, vous obtiendrez probablement des avertissements déployés à un moment donné, et vos utilisateurs les verront. Je pense que dans ce cas, les gens ne blâmeront pas React en soi parce que nous ne montrons pas simplement que la boîte est désagréable - nous faisons simplement ce que le mode de développement est censé faire.

(Au fait, nous utilisons depuis longtemps une boîte d'avertissement similaire en développement chez Facebook, donc cela correspond à la façon dont nous avons l'intention d'utiliser React.)

Je suis vraiment heureux de voir cette proposition, @gaearon ! C'est tout ce dont je rêvais ;)

Juste comme un côté : Peut-être vaut-il la peine d'envisager d'avoir un lien directement dans la boîte pour ne pas obliger les développeurs à chercher sur Google comment s'en débarrasser.

Ouais, bon point. Nous ajouterons quelque chose.

@gaearon Je trouve cette solution très désagréable ; Je ne voudrais jamais que des avertissements envahissent le DOM même pendant le développement. Cela ne sert à rien pour le développeur commun et serait probablement entièrement désactivé par la plupart. Les outils de développement affichent des avertissements pour une raison, ils n'ont pas besoin d'être inventés.

Je trouve également troublant que les solutions DOM continuent d'apparaître sans aucune réfutation à l'un de mes arguments antérieurs contre elle. Si mes points doivent être ignorés, alors très bien, ce n'est pas mon référentiel, donc c'est assez juste, mais c'est décourageant de voir le même argument apparaître, les gens postent contre, les gens semblent pour les points car il n'y a jamais d'argument contre eux , puis ils reviennent tout de suite. Rincer, répéter.

Bien que je sois d'accord sur le fait que cela soit vrai pour la plupart des avertissements, les avertissements React signalent spécifiquement les bogues dans votre code. Ce ne sont pas que des suggestions.

La boîte de dialogue est facile à fermer et les avertissements individuels sont faciles à répéter (au cas où vous ne vous en soucieriez pas pendant un certain temps), mais ils doivent être corrigés.

À titre de comparaison, voici à quoi ressemble la boîte de dialogue dans la base de code Facebook :

Des milliers d'ingénieurs n'ont pas de problème avec cela et sont plus productifs grâce à cela, nous pensons donc que c'est une valeur par défaut raisonnable. Pour être clair, la version open source sera moins criante :

Si vous avez des suggestions sur les modifications de style, n'hésitez pas à commenter sur https://github.com/facebook/react/pull/7360.

Pour ajouter à ce que Dan a dit, je m'appuie sur le # 7360 pour me connecter à notre flux d'enregistrement d'erreurs récemment ajouté. J'essaie actuellement quelques styles de notifications de toast qui sont un peu moins intrusifs. Je publierai bientôt des captures d'écran et/ou un Plnkr pour obtenir des commentaires.

Ces avertissements incluraient-ils l'avertissement "code de développement minifié" ? Cela résoudrait beaucoup de choses assez proprement si c'est le cas.

Je ne vois pas pourquoi il ne pourrait pas également être utilisé à cette fin.

@gaearon

Bien que je sois d'accord sur le fait que cela soit vrai pour la plupart des avertissements, les avertissements React signalent spécifiquement les bogues dans votre code. Ce ne sont pas que des suggestions.

Ceux-ci devraient être des erreurs ou des exceptions IMO. Pourquoi ne le sont-ils pas ? Les exceptions forcent les choses à être corrigées, mais pas un avertissement rejetable.

Des milliers d'ingénieurs n'ont pas de problème avec cela et sont plus productifs grâce à cela, nous pensons donc que c'est une valeur par défaut raisonnable.

Je l'ai mentionné dans un point précédent, mais je suppose que ces ingénieurs sont probablement meilleurs qu'un bon 90% des personnes qui utiliseront la version open source. Je trouve que c'est le contraire d'un défaut raisonnable. Il y a une raison pour laquelle les outils de développement ont des avertissements ; les réinventer n'a pas de sens pour moi. Il sera désactivé et ne sera plus jamais revu.

Cela ressemble à React essaie de faire trop d'IMO.

Lorsque j'ai passé des contrats avec le gouvernement, nous avions une bibliothèque commune que tous les frontaux devaient utiliser. Cela prendrait des erreurs dans la console et les afficherait sous forme de toast. Non seulement il a été déployé plusieurs fois en production par plusieurs équipes, mais de nombreux développeurs l'ont vu une fois puis ont demandé comment le désactiver définitivement. Je vois cela comme plus de la même chose.

Nous envisageons depuis longtemps d'activer une "boîte d'avertissement" pour les avertissements React en cours de développement. Vous pouvez voir une démo ici (PR: #7360). Il n'apparaît que lorsque vous avez des avertissements, mais ils sont très courants pendant le développement (et doivent toujours être corrigés), donc toute personne ayant passé plus de cinq minutes à développer une application verra la boîte de dialogue et saura qu'elle existe.

J'aime beaucoup #7360, @gaearon. Il est réconfortant d'entendre un soutien pour souligner la nécessité de passer à PROD pour les déploiements dans la nouvelle boîte d'avertissement. C'est joli et visuel.

Pour ajouter à ce que Dan a dit, je m'appuie sur le # 7360 pour me connecter à notre flux d'enregistrement d'erreurs récemment ajouté. J'essaie actuellement quelques styles de notifications de toast qui sont un peu moins intrusifs. Je publierai bientôt des captures d'écran et/ou un Plnkr pour obtenir des commentaires.

@bvaughn Au plaisir de voir plus de vos itérations :)

Pour les personnes qui pensent que l'approche de la boîte d'avertissement peut être trop intrusive, d'autres bibliothèques (par exemple VueJS) affichent déjà des superpositions DOM pendant votre flux de travail de développement/itération pour encourager la correction de bogues ou les chemins lents :

Ma propre expérience a été que même s'il s'agit d'un inconvénient mineur, ces messages sont plus évidents que ce que vous pourriez voir dans la console. Je pense que Dan a raison de dire que cela mettra au moins davantage l'accent sur le fait que le mode de développement n'est pas quelque chose que vous devriez déployer pour produire et, espérons-le, conduira à plus de sites proposant un "mode plus rapide" à leurs utilisateurs finaux.

Après ce changement, il sera plus difficile d'ignorer le mode de développement. Vous chercherez probablement "comment supprimer la boîte de dialogue d'avertissement" et découvrirez comment créer pour la production. Si vous ne le faites pas, vous obtiendrez probablement des avertissements déployés à un moment donné, et vos utilisateurs les verront. Je pense que dans ce cas, les gens ne blâmeront pas React en soi parce que nous ne montrons pas simplement que la boîte est désagréable - nous faisons simplement ce que le mode de développement est censé faire.

Ceux-ci devraient être des erreurs ou des exceptions IMO. Pourquoi ne le sont-ils pas ? Les exceptions forcent les choses à être corrigées, mais pas un avertissement rejetable.

Bien qu'ils devraient être corrigés, je pourrais avoir des problèmes plus urgents à régler. Par exemple, je prototype/maquette souvent des interfaces utilisateur et, ce faisant, j'écris un code rapide et généralement inférieur à la normale dont React peut avertir. Bien que je veuille corriger ces avertissements, je m'en fiche jusqu'à ce que je sache que je ne jetterai pas tout le code dans la prochaine heure au moins. Forcer les gens à les réparer instantanément ralentira considérablement le développement expérimental.

Pour les personnes qui pensent que l'approche de la boîte d'avertissement peut être trop intrusive, d'autres bibliothèques (par exemple VueJS) affichent déjà des superpositions DOM pendant votre flux de travail de développement/itération pour encourager la correction de bogues ou les chemins lents :

capture d'écran 2017-01-24 à 10 57 11 h

Êtes-vous sûr que cela vient de Vue lui-même ? Cela ressemble beaucoup aux erreurs de construction de webpack affichées avec la superposition d'erreurs de webpack-hot-middleware . Si tel est le cas, c'est subtilement différent car il s'agit d'un outil de construction au moment du développement ajoutant la superposition plutôt qu'un framework frontal à usage général.

En général, je suis en faveur de la superposition d'avertissement, mais je pense qu'elle devrait contenir un texte explicatif indiquant ce que c'est, pourquoi elle est là et qu'elle peut et doit être désactivée dans le cadre de la désactivation du mode de développement. Derrière un expando si c'est un peu long - mais cela semble être un aussi bon endroit que n'importe quel autre pour faire passer le message.

Je redoute les mises à jour comme 15.2.0 avec une superposition. bosse mineure et soudainement vous avez littéralement des centaines d'avertissements sur les accessoires transmis aux nœuds DOM. des erreurs peut-être, mais je ne pense pas que les avertissements de dépréciation appartiennent à un espace aussi intrusif

des erreurs peut-être, mais je ne pense pas que les avertissements de dépréciation appartiennent à un espace aussi intrusif

Je ne sais pas si cela a été très clairement communiqué auparavant, mais l'idée concernant les avertissements de la boîte jaune (# 7360) n'était pas de montrer _tous_ les avertissements (obsolescence ou autre). Au contraire, certains avertissements que l'équipe jugeait _particulièrement importants_ seraient mis en évidence de cette façon. Le reste resterait vraisemblablement dans la console.

C'est du moins ce que j'ai retenu de la conversation que Tom et moi avons eue à propos de cette fonctionnalité il y a une semaine ou deux.

L'avertissement de prop dans 15.2 était également une erreur IMO et n'est pas indicatif de notre MO normal. Nous aimerions avoir un moyen de contrôler les niveaux d'avertissement par versions mineures pour éviter cela.

La principale raison pour laquelle notre équipe n'utilise pas la version de production est que nous ne pouvons pas exécuter de tests unitaires JS, car les utilitaires de test ne sont pas inclus.

Tout d'abord, une autre série de remerciements à l'équipe React ( @sebmarkbage , @gaearon , @tomocchino et autres) pour avoir discuté de ce problème avec nous et avoir été si ouvert à nous parler de performances et de mobile chez BlinkOn et d'autres synchronisations ce trimestre.

Vérification de l'état

Selon @aweary sur https://github.com/facebook/react/pull/7360 , la solution Yellow Box à ce problème particulier a été suspendue jusqu'à ce que le travail V16 à haute priorité de React soit terminé, mais devrait toujours se produire. https://github.com/facebook/fbjs/pull/165 doit atterrir et être implémenté dans Fiber. Une bonne API publique pour exposer les crochets doit également être conçue. Je garderai mes doigts 🤞

Ce problème semble toujours présent

Un bon nombre des applications de production qui sont tombées sur mon bureau envoient toujours le mode DEV à la production. Nous pouvons voir la chaîne de débogage When deploying React apps to production dans leurs versions ici :

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)

Je suis toujours d'avis qu'un mouvement pré-Yellow Box vers la journalisation de l'avertissement du mode DEV sur la console pour ce qui précède pourrait avoir un certain impact. La suggestion de Sebastian de lancer une erreur de console afin que les rapports de plantage puissent les détecter était également quelque chose qui, à mon avis, valait la peine d'être pris en compte.

Que pouvons-nous faire d'autre pour déplacer l'aiguille ici ?

Un meilleur plaidoyer ? Je suis heureux de m'engager à continuer à défendre les personnes qui n'envoient pas le mode DEV à la production, mais je veux voir si nous pouvons atterrir la solution officielle après la V16 :)

À court terme, il semble que create-react-app soit bien placé pour aider les nouveaux projets à éviter ce problème.

Améliorations des documents d'installation

Pour tous les autres, y aurait-il un support pour https://facebook.github.io/react/docs/installation.html , y compris une légende claire et visible sous l'en-tête Installing React rappelant aux gens de faire attention au mode DEV dans production?

En tant qu'utilisateur, je ne pense pas qu'il y ait une grande incitation pour moi à lire https://facebook.github.io/react/docs/installation.html#development -and-production-versions à première vue autrement.

Les pensées?

La principale raison pour laquelle notre équipe n'utilise pas la version de production est que nous ne pouvons pas exécuter de tests unitaires JS, car les utilitaires de test ne sont pas inclus.

Je suis confus à ce sujet. Exécutez-vous des tests sur le site Web de production ? Si ce n'est pas le cas, qu'est-ce qui vous empêche d'utiliser la version de production sur le site Web de production et la version de développement dans le développement ?

Pour tous les autres, y aurait-il un support pour https://facebook.github.io/react/docs/installation.html , y compris une légende claire et visible sous l'en-tête Installation de React rappelant aux gens de faire attention au mode DEV en production ?

Sûr. Vous voulez envoyer un PR ?

Sûr. Vous voulez envoyer un PR ?

Plus qu'heureux de.

Peut-être qu'un mot sur les benchmarks serait bien aussi pour aider à éduquer ceux qui comparent les perfs avec la réaction en mode dev ?

Me fait penser que l'extension React devtools pourrait être exploitée pour afficher une notification ou quelque chose d'évident lors de l'ouverture d'une page en utilisant React en mode dev peut-être ?

J'aime cette idée! J'ai rassemblé un ensemble d'icônes proposées pour les devtools (voir facebook/react-devtools/pull/652).

Nous devons décider comment détecter dev vs prod React d'une manière qui soit sûre en arrière et à l'avenir, mais je l'ai ajouté à l'ordre du jour de la réunion du lundi.

Nous avons pris quelques mesures raisonnables pour résoudre ce problème :

• React DevTools (avec environ 700 000 utilisateurs) affiche désormais une icône rouge distinctive pour les versions de développement. Cela aide les gens à découvrir la différence entre les versions plus tôt. Cela crée également une certaine pression des pairs, car les développeurs le remarquent sur les sites qu'ils visitent et en informent les personnes qui y travaillent. Nous avons vu quelques sites majeurs résoudre le problème quelques jours après son déploiement.

• L'avis dans React DevTools renvoie à notre site Web où nous avons publié des instructions pour créer la version de production pour tous les principaux bundlers . Nous l'avons également rendu plus visible sur la page d' installation .

• Create React App a continué de gagner en popularité. Il enseigne cette distinction tôt avec des commandes séparées. Il affiche également un avis permanent sur le mode de développement dans le terminal.

• React 16 Beta 1 (et les versions ultérieures) sont livrées avec react.development.js et react.production.min.js comme noms de fichiers pour indiquer clairement que la version non minifiée ne doit pas être utilisée en production.

Je pense qu'à l'avenir, nous pourrions explorer d'autres moyens de résoudre ce problème, mais pour l'instant, je pense que nous pouvons aller de l'avant sans mesures plus drastiques et voir si cela aide. Merci à tous pour la discussion.