React: Explore incentivar os usuários a não enviar o modo DEV para produção

Para referência: https://github.com/facebook/react/pull/8782

Para contextualizar já avisamos se detectarmos que você minificou uma versão DEV do React: https://github.com/facebook/react/blob/8791325db03725ef4801fc58b35a3bb4486a8904/src/renderers/dom/ReactDOM.js#L91 -L98

Na medida em que podemos encontrar heurísticas semelhantes para notificar os usuários, e talvez ainda mais agressivamente abrir uma caixa de diálogo DOM, devemos.

Também quero deixar claro que os avisos que fornecemos podem melhorar significativamente o desempenho se as pessoas prestarem atenção neles. Este tópico explica algumas razões pelas quais é difícil implantar isso após o fato, se não for o padrão.

Eu também gostaria de sugerir um único console.warn se renderToString for chamado no modo dev. Obviamente, na maioria das situações renderToString é chamado no nó, onde não podemos alertar ou abrir uma caixa de diálogo DOM.

Infelizmente, eu realmente gostaria de ser capaz de detectar não apenas se NODE_ENV está definido como production , mas também se process.env.NODE_ENV foi compilado. Alguém sabe de uma maneira de fazer isso?

Obrigado pelo tópico @sebmarkbage e reconheço as dificuldades de implantação após o fato. Também estou agradecido pelos avisos atuais. Parece que alguns desenvolvedores podem não verificar a saída do console de seus sites implantados com a maior frequência possível. É um bom primeiro passo no entanto.

Na medida em que podemos encontrar heurísticas semelhantes para notificar os usuários, e talvez ainda mais agressivamente abrir uma caixa de diálogo DOM, devemos.

Eu ficaria grato por melhorias nas heurísticas usadas para notificar os usuários. Um diálogo DOM mais agressivo ajudaria muito. Isso garantiria que o site continuasse funcionando para os usuários finais, mas fornece uma dica ativa de que os desenvolvedores de frutas com desempenho baixo podem escolher.

A alternativa é encontrarmos uma maneira de corrigir isso em um nível de ferramenta de construção / ENV, conforme mencionado no post original. Isso evitaria que qualquer injeção de DOM fosse necessária.

Injetar qualquer mensagem no DOM parece perigoso e um pouco pretensioso. Isso abre a possibilidade de usuários finais receberem alertas inesperados e confusos, o que parece inaceitável IMO.

@thelarkinn estava propondo que tentássemos padronizar as configurações de ENV sendo necessárias para facilitar a detecção de mensagens como esta

Este parece ser o espaço ideal para resolver isso. É um problema de compilação e deve ser, se possível, resolvido pelas ferramentas de compilação.

Anedótico: Os avisos no console não foram vistos (ou ignorados) no passado. Não tenho números concretos aqui, mas acho que os avisos baseados em console não são suficientes. Concordo com @addyosmani que um aviso baseado em DOM ajudaria muito.

@surma talvez eles devam usar console.warn ou console.error para melhor visibilidade 😉

Não vejo como seria aceitável em qualquer cenário injetar conteúdo em um aplicativo apenas quando ele estiver sendo executado em produção. Você está fazendo uma grande suposição de que a mensagem seria capturada antes que o aplicativo fosse enviado para usuários reais, onde a mensagem poderia prejudicar o UX de maneira significativa.

Aliás, vamos adicionar um suporte mais abrangente de tratamento de erros no Fiber para que você possa substituir componentes que tenham falhas (erros lançados) por visualizações de erro personalizadas. Mesmo no cenário padrão, provavelmente seremos muito agressivos e apenas removeremos esse componente da árvore se houver erros, para que você realmente queira ter uma interface de usuário de erro personalizada para seus usuários de qualquer maneira.

Podemos ser capazes de acionar tal erro para este aviso.

Eu honestamente não acho que console.{error,warn} acima console.log teria mudado alguma coisa. Como eu disse, essa história é anedótica.

Também não estou dizendo que mostrar uma caixa de diálogo DOM é a solução. É algo com o qual eu pessoalmente me sentiria confortável, no entanto. Se ficar no modo dev tem um impacto negativo, pelo menos os usuários saberiam que _algo_ está errado e provavelmente começariam a apertar o botão “Ajuda” ou algo assim.

Conclusão: acho que os frameworks precisam chegar na cara do desenvolvedor em algum momento. Eu adoraria fazer um brainstorming sobre isso para ver quais etapas e compromissos os autores da estrutura estão dispostos a tomar para impedir que as pessoas implementem no modo de desenvolvimento no futuro.

E se o React simplesmente não funcionar a menos que você forneça um ambiente, independentemente de ser desenvolvimento ou produção? Dessa forma, há uma escolha consciente sendo feita de uma forma ou de outra.

Sobre a mensagem injetada no DOM, ela pode ser desabilitada usando um global ou algo assim. Nada demais IMO. Se você desativá-lo, você meio que reconhece que sabe o que está fazendo.

O problema com uma mensagem do console é que às vezes as pessoas registram muitas coisas ou têm outros avisos que ignoram, e é fácil não ver a primeira mensagem do console depois do pergaminho ...

Com um env obrigatório, inevitavelmente os clichês etc. definirão o env var para que você possa começar a usá-lo, temo :/

Sinceramente, não acho que console.{error,warn} sobre console.log teria mudado alguma coisa.

Você acha que é um problema com os desenvolvedores simplesmente não verificando o console, ou o console sendo sobrecarregado com avisos? Isso poderia ser (parcialmente) abordado com uma abordagem mais geral em relação à educação do desenvolvedor?

Também não estou dizendo que mostrar uma caixa de diálogo DOM é a solução. É algo com o qual eu pessoalmente me sentiria confortável, no entanto. Se permanecer no modo dev tem um impacto negativo, pelo menos os usuários saberiam que algo está errado e provavelmente começariam a apertar o botão “Ajuda” ou algo assim.

Eu entendo isso, mas estou apenas dizendo que não acho que seja uma solução e muito menos a solução. É bom que você esteja confortável com isso, mas acho que é melhor errar do lado da cautela e assumir que a maioria das pessoas não quer que erros inesperados sejam exibidos para seus usuários.

Conclusão: acho que os frameworks precisam chegar na cara do desenvolvedor em algum momento. Eu adoraria fazer um brainstorming sobre isso para ver quais etapas e compromissos os autores da estrutura estão dispostos a tomar para impedir que as pessoas implementem no modo de desenvolvimento no futuro.

Eu sou 💯 por entrar na cara do desenvolvedor, mas é importante fazer isso no lugar certo. Para mim, essa é a etapa de construção, não a produção.

Sobre a mensagem injetada no DOM, ela pode ser desabilitada usando um global ou algo assim. Nada demais IMO. Se você desativá-lo, você meio que reconhece que sabe o que está fazendo.

Habilitá-lo por padrão é tão ruim quanto não torná-lo configurável: o comportamento padrão pode resultar em um comportamento inesperado para o usuário final. De qualquer forma, ele deve ser desabilitado por padrão, mas isso anula todo o propósito, pois os desenvolvedores podem corrigir o problema inicial assim que estiverem cientes disso.

O problema com uma mensagem do console é que às vezes as pessoas registram muitas coisas ou têm outros avisos que ignoram, e é fácil não ver a primeira mensagem do console depois do pergaminho ...

Eu entendo totalmente isso, o console pode ficar lotado e é fácil perder coisas. Mas está lotado pelos motivos exatos que estou argumentando: é o lugar onde os desenvolvedores fornecem feedback ou erros. Está fora do caminho da experiência do usuário, o que não acontece com as mensagens injetadas.

Faz sentido, eu entendo o raciocínio.

Bem, talvez fazer a coisa aparecer usando a formatação do console seria algo pelo menos.

O problema é que quase ninguém olha para o console em produção. Você pode usar qualquer fonte e as pessoas não vão notar.

No entanto, se fizermos com que mostre uma mensagem por padrão na produção como uma alteração de ruptura (em 16 ou 17), seria difícil perder. Quero dizer, isso aconteceria na primeira vez que você tentasse implantá-lo (para novos usuários), e os usuários existentes deveriam ler as notas de lançamento ao atualizar para um novo major. Então eu acho que é factível desde que sejamos super explícitos sobre isso e é impossível perder a mensagem.

O problema é que quase ninguém olha para o console em produção. Você pode usar qualquer fonte e as pessoas não vão notar.

Só posso comentar sobre a experiência da equipe do Chrome com isso, mas concordo. A maioria das pessoas notará as mensagens do console durante o fluxo de trabalho de iteração, mas uma porcentagem muito menor analisa os avisos nos sites de produção e menos atua sobre eles.

No entanto, se fizermos com que mostre uma mensagem por padrão na produção como uma alteração de ruptura (em 16 ou 17), seria difícil perder. Quero dizer, isso aconteceria na primeira vez que você tentasse implantá-lo (para novos usuários), e os usuários existentes deveriam ler as notas de lançamento ao atualizar para um novo major. Então eu acho que é factível desde que sejamos super explícitos sobre isso e é impossível perder a mensagem.

Obrigado por estar aberto a uma mudança como essa @gaearon. O que seria necessário para obter um acordo sobre a tentativa de uma mensagem por padrão em uma versão futura? 😄

Concordo que os avisos do console não são a solução e um aviso visível na página é muito melhor.

O aviso visível na página pode:

• Alerte o dev que o site está no modo dev
• Link para os documentos sobre os benefícios e como enviar sem ele
• Um link para desabilitar a mensagem por… sei lá 2 horas?

Desabilitar a mensagem é importante, pois pode estar interferindo/cobrindo algo na página. Como essa configuração seria armazenada no localstorage, o aviso ainda aparecerá no servidor ativo porque é uma origem diferente.

Sim, é muito horrível se usuários reais virem esta mensagem em sites ao vivo, mas parece que o tipo de problema que os desenvolvedores serão encorajados a corrigir, enquanto alguns parecem estar felizes em conviver com os problemas de desempenho do modo dev.

Se a primeira vez que vi esse aviso (o insert no DOM), estivesse em produção, eu ficaria bastante chateado. Os avisos precisam acontecer com antecedência.

@rtorr minha sugestão é que isso aconteça sempre que o site estiver no modo dev, portanto, deve ser visto com antecedência, a menos que esteja faltando alguma coisa?

@jakearchibald desculpe a confusão, minha resposta não foi direcionada à sua. Eu só quero apontar para o tópico que, se usássemos a solução 'inserir no dom', deveríamos ter muito cuidado e garantir que os usuários saibam antes de enviar uma coisa (de alguma forma, não tenho uma boa ideia aqui) .

Eu só vejo algum desenvolvedor esquecendo uma configuração ou algo assim e a gerência enlouquece. Essa possibilidade vale a pena pelas consequências de ter o modo dev em produção?

Um aviso baseado em DOM que eu tenho que desabilitar constantemente não está certo, deve ser possível desabilitá-lo para sempre e talvez nunca deva ser exibido para localhost.

Uma coisa que me atingiu se seria possível ter algum tipo de sinalizador no navegador que você precisa ativar para ativar as ferramentas de desenvolvimento (talvez uma grande sobreposição neles com "Você é um desenvolvedor? [Sim / Não]" ) que a página pode detectar e mostrar apenas o aviso para desenvolvedores. Formulado corretamente, pode ajudar com ataques self-XXS também.

Um aviso baseado em DOM que eu tenho que desabilitar constantemente não está bem, deve ser possível desativá-lo para sempre

Sites iniciados com o modo dev ativado também não são bons. Talvez a mensagem só precise ser descartada uma vez por dia? Mas quanto maior o período, mais provável é que acabe ao vivo. Se puder ser desativado para sempre, estamos de volta ao ponto de partida.

Eu também não acho que um nó dom não intencional em produção seja bom.

Eu acho que de qualquer forma, sempre teremos um caso de ponta. Se esse problema acontecer o tempo todo, talvez a entrega do modo dev esteja errada. Embora não seja ideal em um mundo perfeito, mas se acharmos o modo prod tão importante que estamos dispostos a modificar o aplicativo de alguém, talvez ele deva ser padrão e o modo dev deva ser ativado.

@rtorr

Eu também não acho que um nó dom não intencional em produção seja bom.

Por quê? (Não estou dizendo que você está errado, apenas gostaria de ouvir suas razões)

Talvez adicionando uma configuração para definir prod Domain. Se o domínio prod não estiver definido, sempre receberemos o aviso sobre o modo DEV (com uma solicitação para definir o URL do domínio), se estiver definido, só receberemos um aviso quando o URL corresponder ao domínio prod. Poderíamos até vincular qualquer serviço que queiramos notificar os desenvolvedores

Fico feliz que haja uma discussão construtiva aqui. Existem duas soluções aqui que eu posso ver resolvendo o problema. O Webpack poderia forçar a especificação de NODE_ENV que o React poderia usar para evitar mais facilmente que as pessoas enviassem DEV para PROD, mas isso seria uma alteração importante para o Webpack. Estou conversando com Sean agora sobre o quão viável algo assim poderia ser para o Webpack 3. Manter a pilha React + Webpack para iniciantes e perf amigável é algo que eu sei que ambos os campos se preocupam.

A segunda (idéia de injeção de DOM) é algo que o React poderia fazer e, como Jake mencionou, equilibrar o UX permitindo que a mensagem seja mostrada uma vez por dia ou seja descartada. É uma mudança de uma linha para corrigir o problema, então você só precisa reimplantar. Tenho total empatia por não querer que a gerência surte.

Se quisermos que mais sites React enviem a experiência muito mais rápida que o FB trabalhou para produzir algo que possa ter que dar. Se alguém tiver ideias melhores, por favor, sugira.

@jakearchibald

Por quê? (Não estou dizendo que você está errado, apenas gostaria de ouvir suas razões)

De volta ao meu comentário acima, a menos que possamos informar os desenvolvedores com antecedência (o que parece ser o problema real a ser resolvido), acho meio extremo desvalorizar o produto de alguém exibindo um aviso aos desenvolvedores em sua página de produção. Em muitos casos, isso pode prejudicar mais o produto do que o desempenho do modo de desenvolvimento.

Não importa o que façamos, alguém vai enviar o que for padrão para a produção, por que não tornar a produção padrão? Por que não melhorar o modo de desenvolvimento a ponto de não ter um impacto tão grande?

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

@jakearchibald sim, vejo que ambos os lados têm problemas. Tenho fé das pessoas neste tópico para chegar a algo bom, mesmo que seja o que você está propondo. Vocês são ótimos FYI. Talvez extremo seja a resposta.

Você não pode inserir o aviso do nó DOM se o usuário estiver executando as ferramentas de desenvolvimento do React para que os usuários normais não o experimentem?

@jakearchibald

Sites iniciados com o modo dev ativado também não são bons. Talvez a mensagem só precise ser descartada uma vez por dia? Mas quanto maior o período, mais provável é que acabe ao vivo. Se puder ser desativado para sempre, estamos de volta ao ponto de partida.

Quando o site foi lançado, alguém decidiu que estava "pronto", então, embora seja ruim, não é uma catástrofe. No entanto, tendo (possivelmente, eu não sei os números exatos) centenas de milhares de desenvolvedores tendo que descartar um site destruidor (um aviso DOM deve ser tratado como isso, pois você não tem ideia de como ele interage com o resto do site e se o site for utilizável com o aviso visível) aviso cinco ou mesmo apenas uma vez por dia é uma catástrofe. A maioria dos desenvolvedores tem um build-chain configurado corretamente (custom, create-react-app ou outro) e não tem nenhum uso para esse aviso, eles precisam se livrar dele.

@dan-gamble Acredito que os desenvolvedores que não usam React Dev Tools são o alvo mais urgente para este aviso.

@Pajn Potencialmente, não acho que apenas porque você baixa uma extensão do Chrome, isso automaticamente o torna consciente da opção prod / dev

@dan-gamble Não, claro que não. Mas há pessoas que desenvolvem um aplicativo inteiro sem ele, o que eu acho que indica que eles não usam muito as ferramentas de desenvolvimento e, portanto, são menos propensos a ver o aviso atual para código minificado.

Não costumo acrescentar a uma discussão tão longa quando sinto que o ponto já foi trazido, mas tenho que concordar com isso e quero enfatizar este ponto: Reagir tocando no DOM e me avisando que estou usando uma versão dev ser um grande erro. Até onde eu sei, não há precedente para isso em qualquer outra estrutura.

Imagine todos os tutoriais, todos os playgrounds, todos os pequenos projetos paralelos que usam o modo dev para ensinar React. Cada pequeno site de teste que eu crio para explorar algo divertido no React, ou tentar isolar um caso de teste. Se Reagir através de um aviso em cada um desses sites que eu tive que desabilitar manualmente, eu ficaria incrivelmente louco. Pareceria um pai autoritário e ativamente desencoraja você a usar o React porque sempre que você tenta fazer algo novo, ele te dá um tapa no pulso.

Mesmo fazendo isso a cada 2 horas ? Não, obrigado. Uma reclamação constante como essa certamente vai desencorajar os usuários de desenvolver em React e eu honestamente acho que isso afastaria as pessoas a adotarem outros frameworks. Talvez seja isso que os desenvolvedores do Chrome querem?

Sem mencionar o fato de que sim, isso entrará em produção de alguma forma, e já é difícil o suficiente convencer certas equipes a adotar o React e isso é apenas mais munição para eles contra ele.

A coisa que eu mais amo no React é que ele não faz nada até você chamar ReactDOM.render(...) e quando você faz isso, ele só coloca coisas no DOM onde você disse. É por isso que é uma biblioteca tão boa, isolada e funcional.

Também precisamos detectar se as pessoas estão enviando um pacote não minificado? E se eles não estiverem armazenando em cache quando deveriam? E quando eles não configuraram o nginx de maneira ideal? Ou não use shouldComponentUpdate quando deveria? Ou estão renderizando tudo desnecessariamente quando não precisam?

Existem várias razões para o mau desempenho e culpar apenas o modo dev do React é errado. Quando você implanta um site, é totalmente esperado que você entenda como implantar um site otimizado. Não estou dizendo que não há coisas que possamos fazer, mas a principal razão para isso é que os autores de referência não estão fazendo a devida diligência e não devemos pagar por isso. Precisamos encontrar outra maneira de chamar isso de fora.

Eu pretendia seguir com o que eu acho que é a solução certa: colocar esses tipos de restrições nas ferramentas. Certificando-se de que o webpack ou qualquer ferramenta que você usa para construir seu site para produção é onde devemos forçar essas verificações e estou sem qualquer tipo de restrição que queiramos colocar no processo de construção.

Com relação ao webpack forçar uma configuração NODE_ENV (talvez já exista um problema para isso em seu repositório), isso não dificultaria o uso de bibliotecas que não dependem de configurações de env?

Ou é a ideia de que ele detectaria o uso do NODE_ENV e o forçaria apenas se o código o usasse?

Não vamos ficar muito presos à coisa de "2 horas". Pode ser qualquer período de tempo, desde que funcione.

Além disso, os eventos de armazenamento local significam que ele só precisaria ser dispensado uma vez por origem. Se você tiver várias demonstrações em uma página, descartar uma delas descartará as outras.

Se o aviso entrar ao vivo, é alto o suficiente para garantir uma solução rápida - uma que beneficie os usuários. Se estamos preocupados com a aparência do React em público, realmente queremos evitar lentidão desnecessária como essa.

Claro, isso não detectaria cabeçalhos de cache ruins etc., trata-se de detectar apenas o "modo de desenvolvimento". Também os argumentos "slippery slope" não são úteis.

Não acho que mover o problema para ferramentas de compilação seja útil, pois você terá o mesmo problema se os desenvolvedores usarem uma ferramenta de compilação diferente ou não conseguirem colocá-la no modo de produção. As estruturas do modo de desenvolvimento já produzem avisos de console, e isso claramente não está funcionando.

Não se trata apenas de benchmarks, trata-se de sites reais, lentos para usuários reais, porque um switch não foi trocado.

@jakearchibald Obrigado pela resposta racional ao meu emocionalmente carregado. Eu acho que é um ponto válido que existem muitas razões pelas quais um site pode ficar lento com o React. Gostaria de ver uma maneira de sugerir melhorias de desempenho que sejam melhores do que uma verificação grosseira do modo dev e um aviso no navegador. Se tivéssemos ferramentas para analisar um aplicativo React e fornecer sugestões sérias de desempenho, desde o modo dev até muitas rerenderizações, isso seria muito mais útil. Uma ferramenta genérica como essa pode ser conectada a qualquer pipeline, seja webpack, browserify, etc.

Esta é a principal coisa que eu queria dizer: alguns dias eu usarei o modo React dev em 5-10 lugares diferentes, como jsbin, tutoriais e até mesmo montando um pequeno site de teste e abrindo-o com o protocolo file://. Um aviso forçado no navegador é hostil a esse tipo de desenvolvimento flexível, que é o que a web tanto se destaca. Eu veria esses avisos em todos os lugares porque estou aprendendo React em domínios na web.

Se o aviso entrar ao vivo, é alto o suficiente para garantir uma solução rápida - uma que beneficie os usuários. Se estamos preocupados com a aparência do React em público, realmente queremos evitar lentidão desnecessária como essa.

Mesmo permitir a possibilidade de um aviso específico do desenvolvedor ser exibido para usuários finais parece inaceitável para mim. Um site lento é uma coisa, mas uma mensagem como essa pode minar a confiança do usuário, especialmente para sites com foco em segurança (você ficaria feliz se seu site bancário exibisse erros enigmáticos de repente?) usuários de repente recebendo este aviso, mesmo que apenas por um momento?

Além disso, os eventos de armazenamento local significam que ele só precisaria ser dispensado uma vez por origem. Se você tiver várias demonstrações em uma página, descartar uma delas descartará as outras.

Você não pode confiar em localStorage para desduplicar isso. Não há garantia de que localStorage (ou qualquer outro dado local persistente) não seja apagado em qualquer intervalo.

edit : Além disso, exibindo o erro apenas uma vez a cada {INTERVAL} , você tornou muito mais difícil reproduzir e depurar, pois não é reprodutível deterministicamente.

Existem 2 casos que precisam ser resolvidos:

• Evite benchmarks falsos, testes de desempenho: Resolvido facilmente com uma grande mensagem de console.
• Impedir o envio de DEV para locais de produção: as pessoas não abrem devtools em prod.

Os argumentos contra tocar no DOM são convincentes.

Se houver um aviso de console grande, chamativo e óbvio, é provável que, antes de enviar para a produção, as pessoas usem a versão dev e vejam essa mensagem de console realmente óbvia. Ou talvez algum código já tenha sido enviado para produção, mas para outro projeto eles usarão a próxima versão do react com esta mensagem de console impossível de perder. Talvez eles se lembrem do site que enviaram para produção e verifiquem se o DEV está ativado lá.

A mensagem do console seria educativa, tipo, qualquer um que desenvolve React sabe que há algo realmente importante sobre DEV, e eles veem isso toda vez que usam React para desenvolvimento.

Eu estava hesitante sobre https://github.com/facebook/react/pull/8782 porque as pessoas geralmente não gostam de avisos dos quais não podem se livrar (consulte https://github.com/facebook/react/issues/ 3877), mas considerando as alternativas pode ser uma solução aceitável.

Curioso. O uso do localStorage invocaria a lei de cookies da UE em um site que não é coberto por ela?

Se avisos informativos durante o desenvolvimento são uma boa ideia, então por que outras bibliotecas não estão fazendo isso? Bem, uma razão é para problemas como este. Se outros quiserem fazer isso, eles também devem exibir UIs semelhantes? Tem que fechar todos?

Parece-me que o ideal seria ter algo mais central para lidar com isso.

Talvez o Chrome possa ter um modo de desenvolvimento? As bibliotecas podem informar ao host que estão no modo de desenvolvimento e, em seguida, o Chrome pode adicionar um emblema ou pop-up para indicar isso.

Faz-me pensar que a extensão react devtools pode ser aproveitada para exibir uma notificação ou algo óbvio ao abrir uma página usando reagir no modo dev talvez?

@sebmarkbage

Se avisos informativos durante o desenvolvimento são uma boa ideia, então por que outras bibliotecas não estão fazendo isso?

Acho que alguém precisa ser o primeiro. Angular tem um problema semelhante, com coisas como http://code.gov iniciando no modo dev. Se o React começar a pegar essas coisas onde outros frameworks não, eu estarei pressionando para que eles façam mudanças semelhantes.

Eu estarei pressionando para que eles façam mudanças semelhantes.

@jakearchibald você está sugerindo que cada estrutura deve fornecer seu próprio aviso? Não acho que definir o padrão para frameworks/bibliotecas que forneçam seus próprios avisos de desenvolvimento em produção seja uma ótima ideia. Não deveríamos estar tentando padronizar na plataforma? Como mencionado por @sebmarkbage

Talvez o Chrome possa ter um modo de desenvolvimento? As bibliotecas podem informar ao host que estão no modo de desenvolvimento e, em seguida, o Chrome pode adicionar um emblema ou pop-up para indicar isso.

Eu acho que esta é uma ótima ideia. Precedente: o Safari tem um modo separado que você deve habilitar para acessar o DevTools. Se o Chrome fizesse o mesmo, também poderia adicionar com segurança um indicador para o modo DEV e uma API para acioná-lo. Este indicador só seria visível para os desenvolvedores para não atrapalhar a experiência do usuário.

Esperar que os fornecedores de navegadores implementem tal coisa não vai levar tempo?

@jide sim, mas é mais importante resolver esse problema corretamente do que rapidamente. Além disso, ele pode ser implementado em um único navegador antes de considerar os esforços de padronização (se necessário).

@aweary

você está sugerindo que cada estrutura deve fornecer seu próprio aviso?

Dado que cada estrutura fornece seu próprio modo de desenvolvimento (e esse modo pode ser muito diferente entre as estruturas), parece totalmente justo que a estrutura implemente o aviso de uma maneira igualmente única.

Os navegadores se esforçaram para evitar a exposição de devtools à página. Se estamos fazendo do devtools a barreira de entrada aqui, vamos perder muitos usuários que um aviso do DOM não perderia. Um aviso do DOM parece não apenas mais simples, mas tem menos dependências de plataforma e alcançará mais desenvolvedores. Mais simples e mais eficaz soa como uma vitória.

@gaearon No lado do Chrome DevTools, estamos fazendo um brainstorming de uma "API de violações" ao vivo que os autores da plataforma e da estrutura da Web podem usar para sinalizar avisos importantes. Eles seriam apresentados em algum lugar como a próxima atualização do painel de auditorias. Parece semelhante ao seu pedido e pode ser usado para acionar um aviso na detecção do modo DEV.

Para este problema específico, você pode estar atrás de algo um pouco mais alto do que o que estávamos planejando originalmente. Um painel de violações, semelhante às mensagens de log do console, exige que você saiba que um painel fornecerá informações. Talvez haja espaço adicional de UX para algo que exiba uma sobreposição de página muito visível na parte inferior da página para a qual as estruturas possam padronizar as mensagens. Loop em @paulirish e @s3ththompson para seus pensamentos após o fim de semana de férias.

Fwiw, meu palpite é que esta API não estará pronta por mais alguns meses. Quando estiver, ele estará disponível apenas nas Canárias inicialmente e, 6 a 7 semanas depois, poderá se tornar estável.

Um aviso DOM parece não apenas mais simples, mas mais eficaz.

Estou de acordo com Jake sobre isso. Vamos continuar conversando sobre a solução DevTools, mas eu também gostaria de descobrir o que o React pode estar aberto a fazer como um fallback caso a API não acabe se adequando às suas necessidades ou esteja mais longe em termos de cronograma.

Dado que cada estrutura fornece seu próprio modo de desenvolvimento (e esse modo pode ser muito diferente entre as estruturas), parece totalmente justo que a estrutura implemente o aviso de uma maneira igualmente única.

@jakearchibald você percebe que definir esse padrão significa que as páginas que utilizam várias estruturas (ou bibliotecas que se seguiram no conjunto) podem resultar em uma quantidade arbitrária de avisos enigmáticos renderizados não determinísticos sendo exibidos aos usuários finais?

Os navegadores se esforçaram para evitar a exposição de devtools à página.

E tenho certeza de que o motivo é pelo menos parcialmente porque as mensagens específicas do desenvolvedor não devem ser expostas aos usuários finais.

Um aviso DOM parece não apenas mais simples, mas mais eficaz.

Ninguém está argumentando contra a simplicidade ou eficácia da solução. Funcionaria , mas à custa de comprometer a experiência do usuário. A velocidade não é a única coisa que pode afetar negativamente os usuários.

Fwiw, meu palpite é que esta API não estará pronta por mais alguns meses. Quando estiver, ele estará disponível apenas nas Canárias inicialmente e, 6 a 7 semanas depois, poderá se tornar estável.

@addyosmani se for uma solução melhor, não vejo como isso seria um problema. Quaisquer mudanças no React estariam em uma versão principal, o que eu acho que é TBD no que diz respeito ao tempo de lançamento de qualquer maneira.

A solução escolhida afetará potencialmente todo o desenvolvimento futuro. Uma questão de semanas vs meses nesse contexto é aceitável IMO.

Eu entendo que alguns desenvolvedores se sintam invadidos se um framework injetar algo em seu DOM que eles mesmos não colocaram lá. Mas eu sinto que um banner na parte inferior da página que diz “Este site está em DevMode” seria uma ótima solução para isso que não tem um grande impacto na experiência do usuário. Eu gostaria de entender por que muitas pessoas pensam o contrário.

@aweary : Se um site “focado em segurança” for lançado no DevMode, ele não deve ser confiável até que resolva o problema. “DevMode” pode incluir todos os tipos de atalhos relacionados à segurança, como verificações de CORS desabilitadas ou código-fonte de modelo exposto, etc. Se um site for focado em segurança, isso não deve acontecer.

(Percebo que “DevMode” tem um significado muito específico no React, mas estou tentando assumir a perspectiva de um não desenvolvedor aqui)

@aweary

você percebe que definir esse padrão significa que as páginas que utilizam vários frameworks podem resultar em uma quantidade arbitrária de avisos enigmáticos renderizados de forma não determinística sendo exibidos aos usuários finais?

Eu absolutamente percebo isso. Uma página com vários frameworks no modo dev prejudicará gravemente a experiência do usuário sem um bom motivo. Parece que você prefere que passe despercebido e não corrigido. Prefiro que seja tão ruim para não desenvolvedores (mensagens visíveis direcionadas a desenvolvedores) que o desenvolvedor o corrija prontamente, criando uma experiência de usuário muito melhor.

A velocidade não é a única coisa que pode afetar negativamente os usuários.

Não vejo ninguém afirmando o contrário? Estou bem triste com esse tipo de reação 😞

Parece que você prefere que passe despercebido e não corrigido

@jakearchibald essa é uma conclusão meio estranha, não acho que estaria gastando meu tempo livre aqui conversando com você se não quisesse que isso fosse consertado? Só porque eu não concordo com sua solução não significa que estou resignado a deixá-la sem solução. Isso é realmente injusto.

Prefiro que seja tão ruim para não desenvolvedores (mensagens visíveis direcionadas a desenvolvedores) que o desenvolvedor o corrija prontamente, criando uma experiência de usuário muito melhor.

Isso é o que eu acho fundamentalmente inaceitável: você está punindo explicitamente os usuários primeiro.

Se um site “focado em segurança” for lançado no DevMode, ele não deve ser confiável até que resolva o problema.

O modo dev @surma não é inerentemente inseguro, mas, independentemente, está ultrapassando a linha para assumir que não há problema em comunicar isso aos usuários.

Não acho que uma solução que exija abrir ou habilitar ferramentas de desenvolvimento seja suficiente. Para que isso seja notado, ele precisa estar visível para o controle de qualidade, gerenciamento e possivelmente usuários finais. Os desenvolvedores estarão muito acostumados a ver isso. Semelhante a como as configurações SSL problemáticas são destacadas. Não precisa ser muito, mas o suficiente para ser notado que alguém vai perguntar sobre isso e depois consertá-lo.

A injeção no DOM é problemática por vários motivos. É um pouco mais viável para React já que somos uma biblioteca DOM e temos pontos de entrada DOM. É mais difícil para bibliotecas que não são específicas do DOM e podem ser executadas em um trabalhador.

Uma coisa que podemos fazer é alterar o favicon, desde que forneçamos uma maneira de substituí-lo explicitamente. Muitos sites já possuem favicons separados para o modo de desenvolvimento.

Precisamos descobrir uma experiência padrão para lidar com erros no React que podem não ser capazes de manter o DOM no lugar. A implementação padrão atual no master exclui o conteúdo React da árvore se um erro for gerado. Isso também é invasivo.

Se tivéssemos uma maneira de detectar que você não está no modo de desenvolvimento, poderíamos acionar esse modo de erro. Nós realmente precisamos de uma maneira sólida de optar por um modo de desenvolvimento permanentemente.

Semelhante a como as configurações SSL problemáticas são destacadas.

Este é exatamente o tipo de coisa que eu acho que seria perfeito. Os usuários já estão acostumados a navegadores que fornecem informações de segurança sobre os sites que visitam, as informações de desempenho não são um grande salto a partir daí. Além disso, seria consistente para todas as estruturas/bibliotecas que relatam possíveis problemas de desempenho e não interferiria diretamente no fluxo de trabalho do usuário. 👍

Eu gosto da ideia do favicon : Perceptível, funciona sem devtools ou extensão, perceptível por todos, não prejudica os usuários, pode ser animado para chamar a atenção, irritante o suficiente para fazer os devs quererem desaparecer.

Que tal ativar o modo DEV?
Erramos no lado "bom UX", porque DX ruim é mais fácil de perceber (e IMHO para problemas como esse os usuários devem "ganhar" porque não podem escolher, enquanto os desenvolvedores podem).
Tenho certeza de que alguns frameworks já fazem isso (como Relay, se bem me lembro).

Propostas de como implementá-lo:

• habilitar o modo de desenvolvimento somente se NODE_ENV estiver explicitamente definido como development
• habilite o modo de desenvolvimento se o __DEV__ global for === true
• exportar um módulo de ferramentas de depuração para ser habilitado na área do usuário

O primeiro parece o melhor porque os outros dois podem ser codificados sem uma proteção (como uma instrução if(NODE_ENV === 'development') ) e, portanto, serem enviados para produção de qualquer maneira.

@mattecapu Veja meu segundo comentário sobre. https://twitter.com/sebmarkbage/status/820047144677584896

Se houver uma maneira semelhante de impor que os desenvolvedores comecem executando no modo DEV, não importa qual seja o padrão. Mas é muito ruim se você ficar para trás.

Há muito o que comentar aqui, e tenho pensamentos, mas gostaria de ponderar especificamente apenas a questão de como desativar um aviso de desenvolvimento.

Eu não sou um grande fã de um botão que desabilita um aviso do DOM por um determinado período de tempo em um navegador específico. Como @jlongster aponta, é uma dor para os desenvolvedores se isso acontecer com frequência. Mas o mais importante para mim, ele introduz variabilidade específica do navegador no comportamento, o que pode facilmente levar à irreprodutibilidade de bugs "mas funciona bem na minha máquina".

Eu preferiria um parâmetro enviado para render que lista domínios que são considerados caixas de desenvolvimento, com um valor padrão de ["localhost", "127.0.0.1"] . Ficaria algo assim:

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

Se o domínio atual estiver na lista, o aviso dev nunca aparecerá. Caso contrário, ele faz. Sob este regime:

• Usando dev build em sua máquina local usando localhost ou 127.0.0.1 : Nenhum aviso do desenvolvedor nunca e nenhuma ação do desenvolvedor necessária.
• Usando dev build em uma máquina dev usando outro nome de host : você recebe o aviso DOM até adicionar o nome de domínio à lista passada para render . Depois disso, você nunca recebe o aviso do DOM.
• Usando a compilação dev em uma máquina de produção : você recebe o aviso do DOM até mudar o React para a versão do prod.

A única coisa que me preocupa nessa solução é que ela pode levar os desenvolvedores a deixar uma lista de todos os domínios do servidor dev no código, e esse código pode chegar à produção. Para empresas que consideram seus domínios de servidor de desenvolvimento secretos, isso seria um problema. Pensamentos?

@aickin o problema com essa abordagem é que ela exige que os usuários estejam cientes da configuração e, por sua vez, do problema que está resolvendo. A questão é que as pessoas não estão cientes da distinção dev/prod em primeiro lugar.

Edit : não importa, eu vejo, ainda há um aviso do DOM em desenvolvimento.

Os ambientes do lado do servidor corrigem isso mostrando uma página de erro "especial" que inclui detalhes de depuração e também informa para não exibi-la em produção.

Como planejamos fazer o React "falhar rápido" e desmontar visualizações, a menos que você forneça um limite de erro personalizado, podemos adicionar um limite de erro padrão "caixa vermelha" no desenvolvimento que atua como uma página educacional.

Então, na primeira vez que o usuário tiver um bug em produção, ele verá uma mensagem de erro detalhada especial. Esta pode ser uma oportunidade para educar sobre a construção do DEV.

Mas eu sinto que um banner na parte inferior da página que diz “Este site está em DevMode” seria uma ótima solução para isso que não tem um grande impacto na experiência do usuário. Eu gostaria de entender por que muitas pessoas pensam o contrário.

A maioria dos usuários não gosta de aplicativos da web se eles sabem que é um aplicativo da web, por quê? Porque uma mentalidade anteriormente comum da web era que quando ela aparece na tela está pronto, não importa o quão ruim ela se comporte e os usuários tenham aprendido que a web é ruim. No entanto, é perfeitamente possível criar um ótimo UX na web, mas para isso eu devo possuir o DOM. Se alguém injetar banners aleatórios em lugares arbitrários, o elemento errado pode começar a rolar, ou pode fazer com que a tela inteira seja repintada na rolagem ou pode interferir, por exemplo, em gestos de arrastar ou outra coisa. A questão é que, enquanto esse banner estiver no ar, não posso desenvolver porque não posso saber se a experiência é a mesma quando esse banner se for.

Como solução de framework, gosto muito da ideia do favicon, não atrapalha o desenvolvimento, não parece estranho para os usuários, possivelmente não destrói o UX, mas será notado. No entanto, ele realmente só funciona para uma única biblioteca ou estrutura no momento e não funciona para bibliotecas executadas em workers. A solução real é uma boa maneira de fazer isso através do navegador que pode suportar vários frameworks e bibliotecas e pode ser acessado de todos os contextos.

Outra solução que suporta vários frameworks e libs e é mais clara, mas requer uma solicitação de permissão, é mostrar uma notificação do navegador.

Aqui está uma ideia: atualize os documentos de introdução na página inicial do react para enviar o app create react com mais intensidade. E enfatize a importância do npm build nesses documentos. Não precisamos de um aviso do DOM, precisamos de conscientização.

Acho que @ropilz abordou isso no início do tópico com seu comentário "_..nós poderíamos até vincular qualquer serviço que queremos notificar devs.._", mas pode ter passado despercebido (ou não reconhecido).

Pelo que entendi, o problema fundamental a ser resolvido aqui é

• para alertar de alguma forma _developers_ quando _end-users_ de produção experimentam um site em execução no modo dev
• não podemos contar com desenvolvedores vendo mensagens console.log (ou mesmo avisos DOM para esse assunto) em produção, _a menos_ que esses desenvolvedores estejam usando ativamente o site de produção (ou estamos contando com usuários finais, QA/ equipes de suporte etc. para relatar esses avisos de volta ao desenvolvedor)
• há argumentos de UX (válidos) _contra_ mostrando aos usuários finais um aviso visível do DOM destinado ao público de desenvolvedores.

E se houvesse algo análogo ao report-uri do CSP, para os frameworks enviarem avisos de modo de desenvolvimento, em vez de mostrar um aviso in-situ no site onde eles seriam visíveis para os usuários finais?

Obviamente, há uma série de coisas a serem consideradas, como:

1. Esse relatório seria idealmente ATIVADO por padrão, mas qual seria o padrão report-uri ? (esperamos que cada estrutura hospedasse seu próprio serviço gratuito, semelhante a https://report-uri.io? (isso pode ser possível para estruturas grandes patrocinadas por empresas como React & Angular; mas certamente impraticável para estruturas menores de código aberto como Preact, Vue etc.)
2. Depois que um aviso é relatado, como o proprietário/desenvolvedor do site é notificado? (talvez uma boa maneira para não desenvolvedores se envolverem em um projeto, se voluntariando para monitorar esses relatórios e ajudar a rastrear/notificar o mantenedor?)

Admito plenamente que essa sugestão é apenas uma bolha de pensamento, e não considerei o quão prático isso seria ou como realmente funcionaria; mas eu queria levantar isso porque me parece que o desafio de 'reportar problemas de produção' já foi parcialmente resolvido para relatórios CSP/HPKP, e talvez possamos explorar algo semelhante aqui?

É importante dar um passo atrás e perceber que o React é um framework. Você não deve :

• Modifique o DOM para apresentar algo visualmente apenas como um lembrete para os desenvolvedores . Não há como isso funcionar bem fora da caixa a menos que você entenda e desenvolva algo que possa funcionar em todos os ambientes sem atrapalhar os desenvolvedores e perder a confiança do usuário caso isso apareça na produção (se minha experiência for alguma indicação, isso acontecerá com bastante frequência e muitos não poderão implantar uma correção rápida para desativá-lo).

• Modifique o favicon. O favicon é irritantemente armazenado em cache, usado para favoritos, ícones de aplicativos da web salvos em dispositivos móveis se outros não forem especificados, etc. Isso corre o risco de uma implantação de produção acidental (ou proposital) no modo de desenvolvimento, apagando o logotipo de uma marca.

• Notificações do navegador. Quando você está sendo observado, você provavelmente está sendo observado por um usuário. O pop-up de uma notificação solicitará permissões do navegador e exibirá coisas estranhas que os usuários não entenderão. A suposição de que isso seria visto principalmente pelos desenvolvedores, na minha experiência, é exatamente o inverso e possivelmente arruinará a confiança dos usuários.

Não é trabalho do React cuidar de desenvolvedores. Proponho também:

1. Ative o modo de desenvolvimento. Quando os desenvolvedores perceberem que não podem depurar algo, eles procurarão como ativá-lo (o que precisa ser documentado em todos os lugares ). Não, não é trabalho do React dizer a eles para desativá-lo novamente. Problema deles.

2. Deixe para uma mensagem console.log simples (e isso deve ser desabilitado). Deixe os desenvolvedores encontrarem e lidarem com isso. Se não o fizerem, tudo bem. Você não pode entrar em todas as organizações e fazê-las fazer as coisas corretamente. Só não é escalável.

Eu tenho que discordar de tocar no DOM para exibir um aviso. Parece fácil e simples para o React porque é uma biblioteca DOM, mas imagine se todas as bibliotecas tivessem que exibir seus próprios avisos no DOM. Vai ser uma bagunça total.

Existem tantas bibliotecas que os desenvolvedores usam que provavelmente têm seu próprio modo de desenvolvimento. Eu acho que definir process.env.NODE_ENV para production já foi um padrão comum no agrupamento de módulos para navegador. É disso que precisamos melhorar a conscientização.

Eu concordo que os documentos do React não mostram com destaque que há diferença entre desenvolvimento e produção. Ao abrir os documentos, você precisa passar pelos Guias Avançados para ler a diferença entre desenvolvimento e produção. O título é Optimizing Performance , algo que os iniciantes definitivamente não vão dar uma olhada porque usam React porque ouviram que é rápido. Eu acho que os documentos poderiam ser melhorados para ter outros documentos intitulados "Usando React in Production" ou similar na seção Quick Start .

Os iniciantes geralmente não lêem os Guias Avançados, mas abrirão alguns links no Início Rápido se o título for claro o suficiente e parecer importante. Eu sei que sim porque é isso que eu faço quando começo a aprender React. Eu não li o guia de introdução, mas li algumas páginas na seção Quick Start.

Outra abordagem que podemos adotar é mostrar um aviso no console quando o React é usado no modo dev com um link para corrigir esse ponto nos documentos. Abrir console em produção para desenvolvedores é incomum, mas em ambiente local ao desenvolver eles certamente abrirão o console. Dessa forma, ao desenvolver localmente, eles saberão que precisam fazer algo antes de publicar para produção.

http://code.gov lançado apesar dos avisos do console. Este é exatamente o tipo de coisa que devemos tentar evitar. (Esse site é Angular, mas o mesmo se aplica ao React)

Aqui está o problema para code.gov se alguém quiser entrar em contato com eles (ou enviar um 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.

Eu nunca usei Angular 2 antes (o que me torna iniciante neste caso). Minha reação inicial depois de ver o aviso é que tento ligar enableProdMode() . Não funciona. Acho que a mensagem do console para o caso Angular poderia ser melhorada. Em vez de confiar na magia, eles deveriam apontar para os documentos.

Abrindo os documentos do Angular, não vejo nada sobre a compilação de produção. Eu acho que isso é um problema para Angular e React. Ambos usam o modo dev, mas não informam as pessoas nos documentos sobre como desativá-lo. É por isso que melhorar os documentos pode ajudar muito na educação dos desenvolvedores

Não sou contra mostrar o aviso do usuário quando os desenvolvedores cometem "erros", mas injetar algum elemento DOM aleatório é apenas intrusivo. Adoro como os navegadores lidam com o problema HTTPS, onde o navegador tem uma interface do usuário dedicada para mostrar que o site é inseguro. Não temos um para status relacionado ao desempenho. Dadas as crescentes preocupações sobre o desempenho da Web em geral, não vejo por que o fornecedor do navegador não apresenta maneiras de dizer ao usuário que o site que está visitando é ruim.

Isso deve ser abordado no nível de ferramentas, para que possivelmente o webpack e o Babel possam notificar os desenvolvedores sobre os benefícios de definir um NODE_ENV.

@pveyes Concordo, fiz o mesmo ponto para a equipe Angular.

@matthewp há um problema muito mais antigo sobre isso https://github.com/presidential-innovation-fellows/code-gov-web/issues/129 e a equipe Angular entrou em contato diretamente e deu a eles a correção - parece haver pouca vontade de aplicá-lo. A pergunta é: um aviso do DOM tornaria essa correção mais urgente ou impediria o lançamento no modo de desenvolvimento para começar?

A pergunta é: um aviso do DOM tornaria essa correção mais urgente ou impediria o lançamento no modo de desenvolvimento para começar?

Mais do que provavelmente eles veriam o aviso em desenvolvimento, o Google como desativá-lo e desativá-lo. Em seguida, implantou-o no modo dev sem perceber no futuro porque eles esquecem. Durante o desenvolvimento você quer que pareça produção para que você não possa ter algum pedaço aleatório de DOM sendo inserido. Você não pode ter um sistema de controle de qualidade ou de teste vendo isso, pois não seria indicativo de produção.

Então você acaba com um monte de códigos inúteis desabilitando essa coisa que estraga o UX do site. Não é como se o engenheiro original que o desativou durante o desenvolvimento necessariamente se lembrasse também; eles podem até ter seguido em frente antes de ir para a produção.

Não tenho certeza de como o processo de implantação funciona no code.gov, mas se for algo parecido com o que experimentei como contratado do governo, uma implantação acidental do modo de desenvolvimento na produção seria:

1. Force uma reversão completa de toda a implantação (algumas das quais levam 6 meses para obter aprovação e incluir tudo, desde alterações na interface do usuário até atualizações de software do servidor), provavelmente no dia seguinte, e então você recebe reuniões e documentação de acompanhamento sobre o que aconteceu e agendar uma nova janela de implantação (você será perguntado, repetidamente, se os scripts ou serviços de banco de dados ou o que quer que esteja no modo dev devido a um único aviso na interface do usuário). Já vi isso acontecer por coisas muito pequenas. Às vezes você pode obter exceções, mas YMMV.

2. Seria notado pelos usuários, seria corrigido, mas como provavelmente não afeta a função, não seria atualizado até a próxima janela de implantação. Assim, todos os usuários podem vê-lo por semanas ou meses.

Pelo menos essa foi a minha experiência. A questão é que, mesmo que uma intrusão do DOM seja notada imediatamente após a implantação, você não sabe como é a infraestrutura / processo e pode não ser algo que eles possam corrigir imediatamente (mesmo que devam ser capazes).

As mensagens de aviso serão mais visíveis quando o #7360 (caixa amarela) for mesclado. Também poderíamos adicionar uma mensagem à caixa amarela (chamar de "React Development Mode Warnings"?).

Abrindo os documentos do Angular, não vejo nada sobre a compilação de produção. Eu acho que isso é um problema para Angular e React. Ambos usam o modo dev, mas não informam as pessoas nos documentos sobre como desativá-lo. É por isso que melhorar os documentos pode ajudar muito na educação dos desenvolvedores

Está bem na página de instalação:

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

E na otimização do desempenho:

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

Eu não acho justo dizer que os documentos não são sinceros sobre isso.

Ao abrir os documentos, você precisa passar pelos Guias Avançados para ler a diferença entre desenvolvimento e produção. O título é Optimizing Performance, algo que os iniciantes definitivamente não vão dar uma olhada porque usam React porque ouviram que é rápido. Eu acho que os documentos poderiam ser melhorados para ter outros documentos intitulados "Usando React in Production" ou similar na seção Quick Start.

Está bem ali, na primeira página (Instalação):

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

Você tem razão. Desculpe, minha culpa. Eu assumi que a compilação de produção está em uma seção diferente, então não procurei lá e procurei por um título relevante na barra lateral (e encontrei a página Otimizando o desempenho). Eu deveria saber melhor.

Eu não sou realmente um iniciante em React, é por isso que quando abro os documentos para verificar minha suposição - que os documentos do React não são iniciais sobre prod vs dev - não abri os documentos de instalação 🙇

Sem problemas. Se não estiver visível o suficiente, estou aberto a sugestões para um melhor posicionamento. Por exemplo, poderíamos fazer uma página dedicada para ele ( Deploying to Production ).

Não esqueçamos que esta questão é uma questão importante a ser resolvida, mas não a questão mais importante a ser destacada. Também não estou convencido de que será suficiente, mesmo que destacado na primeira página, porque as pessoas verão e navegarão, esquecerão e pensarão "eu sei o que estou fazendo". Então eu não iria girar demais na coisa dos documentos.

A única maneira real de lidar com isso é detectando e notificando.

@KrisSiegel O favicon sendo armazenado em cache é um bom ponto. Eu me pergunto se devemos apenas trocá-lo depois de um segundo ou dois e, em seguida, virá-lo de volta brevemente a cada poucos segundos. Dessa forma, é muito improvável que o problema de armazenamento em cache e de favoritos seja cronometrado no momento do ícone substituído.

Eu pensei que as manipulações de JS para favicon não fossem armazenadas em cache, mas talvez eu esteja errado.

Eu diria que o lugar certo para ter ganchos para isso não é o Chrome ou o Firefox, mas sim o webpack, o Browserify ou o Rollup.

Construir o que deveria ser um pacote de produção para o React, mas sem ativar o modo de produção, é apenas isso – um erro de compilação. Acho que a razão pela qual não há acordo sobre como apresentar isso em tempo de execução é reflexo de que isso não é um problema que deve ser tratado em tempo de execução.

@taion concordo. Acho que isso definitivamente pertence à ferramenta de compilação, não ao DOM.

Eu acho que deve ser o local das ferramentas de compilação para assumir que o env do nó deve ser definido para produção para o código de produção. Pode não ser necessário para todos os projetos, mas acho que é uma boa suposição.

Se npm run build for executado no terminal e o env não estiver definido para produção, você deverá receber um aviso vermelho no terminal junto com a saída padrão: env is not set to production, some scripts may be in development mode

Atualmente, não recebo esse aviso do webpack.

Editar: esclarecimento adicional

Ou apenas defina NODE_ENV para você, na verdade.

Se os avisos do console não estiverem funcionando, não tenho certeza se os avisos de compilação funcionarão.

A compilação deve configurar as coisas para você ou falhar se for configurada incorretamente para produção. Pelo menos para React, isso _é_ um sinalizador de tempo de compilação.

@jakearchibald Tenho certeza de que ainda será ignorado por alguns, mas pelo menos o aviso seria mostrado a eles quando eles o construíssem, em vez de não ser visto porque o aviso está oculto no console do navegador, que eles podem nunca abrir em produção . Mais importante ainda, dá àqueles com menos experiência uma pista sobre o que devem fazer para preparar a produção do código.

Embora muitos desenvolvedores atualizem bibliotecas, é comum não atualizar o webpack e, de maneira mais geral, as ferramentas, porque muitas pessoas assumem que ele simplesmente funciona, e pode ser difícil atualizar o webpack e companhia.

Construir o que deveria ser um pacote de produção para o React, mas sem ativar o modo de produção, é apenas isso – um erro de compilação.

Usar uma versão pré-empacotada do React de um CDN também é uma configuração com suporte , mas não há nenhuma etapa de compilação nesse fluxo de trabalho. Portanto, uma solução para esse problema que se concentre apenas na compilação ignoraria o caso de uso da CDN.

Sinceramente, não tenho certeza de como me sinto sobre isso; Eu posso ver argumentos a favor e contra ter avisos dev para o uso do React CDN.

@taion Como alguém que oferece suporte a uma solução somente de compilação, você acha que esse é um caso de uso importante a ser abordado?

O que as outras pessoas pensam?

Eu acho que a documentação lá é bem clara que você deve usar os pacotes .min.js para produção. Talvez pudesse usar um negrito, um tamanho de fonte maior, algo assim. Mas se alguém estiver usando o pacote React unminified em produção para seu site, eles terão outros problemas de qualquer maneira.

Eu acho que a documentação lá é bem clara que você deve usar os pacotes .min.js para produção.

Concordo, mas a página também é bem clara sobre como configurar sua ferramenta de compilação para produção se você incluir o React como um pacote npm. Acho que o ponto principal desta edição era tentar criar um poço de sucesso para pessoas que não leem cuidadosamente essa página de documentação.

Parece que você pode discordar, no entanto, e que acha que usar a compilação dev da CDN não é um caso importante a ser evitado com um aviso de dev mais agressivo. Isso é um resumo justo de sua posição, ou estou perdendo algumas nuances?

Eu acho que a configuração CDN+dev está obviamente errada, pois requer que o usuário use uma compilação unminified do React. É mais difícil falhar dessa maneira porque a carga de conhecimento necessária para _apenas usar a compilação minificada_ é menor.

A configuração onde você _pensa_ as coisas estão prontas para produção porque você executou a minificação no webpack ou Browserify, mas na verdade você não está porque você não definiu NODE_ENV – você não pode obter isso através dos pacotes CDN.

Acho que a guia React em Chrome Developer Tools é suficiente para dizer se estamos em DEV Mode .

Acho que vale a pena notar que há algum precedente para um framework injetar um elemento DOM na página no modo dev:

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

Embora, tanto quanto eu possa dizer, eu não acho que isso esteja ativado por padrão.

Seguindo a discussão acima, parece haver um objetivo geral de alcançar uma solução perfeita que satisfaça todas as restrições, mas impeça de maneira confiável que todos executem no modo dev quando não deveriam. O OP afirmou que seria necessário haver uma troca entre as experiências potenciais para desenvolvedores e usuários, e acho que esse é o caso.

Para tentar reafirmar o problema um pouco:

• Um número diferente de zero de sites React chega à produção sem o modo de desenvolvimento desabilitado
• Queremos reduzir este número
• Não queremos incomodar os desenvolvedores do React
• Não queremos adiar os recém-chegados ao React
• Não queremos que os usuários finais de sites construídos em React vejam avisos céticos do desenvolvedor
• Não queremos quebrar sites devido à presença de elementos DOM estrangeiros

Dado isso, acho que um primeiro passo decente seria o React no modo dev anunciar que está no modo dev por meio de um console.warn ou console.info com instruções para garantir que isso esteja desabilitado para a produção desdobramento, desenvolvimento.

Claro, isso não vai pegar todo mundo, mas _é um começo decente_ que deve reduzir o número de pessoas que enviam inadvertidamente para a produção e não fecha nenhuma porta para melhorias futuras.

Dado isso, acho que um primeiro passo decente seria o React no modo dev anunciar que está no modo dev por meio de um console.warn ou console.info com instruções para garantir que isso esteja desabilitado para a implantação de produção.

Não é errado estar no modo de desenvolvimento quando você está... desenvolvendo. Que outras heurísticas poderíamos usar?

Além disso, dado que ninguém lê o console na produção, eu me pergunto se poderíamos colocar um tempo limite para que ele seja registrado se você usar soluções de relatórios de falhas.

Não é errado estar no modo de desenvolvimento quando você está... desenvolvendo. Que outras heurísticas poderíamos usar?

Eu acho que deve ser semelhante ao aviso atual do React DevTools

Uma mensagem informativa que lembra que você está no modo dev e que o modo dev deve ser desabilitado para sites de produção. Isso (em teoria) deve conscientizar mais desenvolvedores de que há uma distinção e que algumas ações precisam ser tomadas para se preparar para uso em produção.

Como você disse, quase ninguém verá um aviso de console na produção real - e nesse ponto já é um pouco tarde.

Desculpe soar como um registro travado, mas os avisos do console não parecem funcionar. Por exemplo, https://code.gov.

Desculpe soar como um registro travado, mas os avisos do console não parecem funcionar. Por exemplo, https://code.gov.

Uma única contra-instância mostra que não é infalível - mas não acho que qualquer abordagem seja.

Se um aviso do console for capaz de aumentar a conscientização e reduzir o número de pessoas que executam erroneamente o modo dev quando não deveriam, isso parece um passo na direção certa. O perfeito é inimigo do bom.

@jakearchibald

Sim, mas se a ferramenta de compilação do code.gov fosse configurada com ganchos aqui, então isso _teria_ evitado o problema que você está observando, pelo menos no contexto do React que usa ganchos de tempo de compilação para isso. Afinal, eles estão usando o webpack.

Não estou dizendo que o webpack deve emitir um aviso de compilação. Estou dizendo que a correção certa é que o webpack define process.NODE_ENV para você ou esse webpack apenas falha na compilação por padrão se você tentar fazer uma compilação de produção sem a configuração de produção apropriada.

Queria responder rapidamente a um ponto anterior de @addyosmani sobre "violações" do DevTools. Estamos prototipando mostrando indicações mais fortes de certos erros no Chrome DevTools, mas esse trabalho ainda é muito cedo, e costumo concordar com @jakearchibald que mostrar um aviso (mesmo que seja mais assustador que console.warn ) não é uma solução suficientemente boa.

Que tal padronizar o React para o modo de produção e ativar o modo de desenvolvimento se e somente se NODE_ENV == 'development' ou o nome do host for localhost / 127.0.0.1 ? A maioria dos desenvolvedores obterá o comportamento correto pronto para uso e sempre haverá uma maneira de forçar manualmente o modo de desenvolvimento se você realmente precisar.

Parece menos do que ideal ainda estar atingindo esse branch com o que pode ser uma condicional bastante complicada (já que você precisaria não apenas falhar no Node) o tempo todo.

BTW, -p (modo "produção", que também permite minificação com configurações padrão) no webpack 2 define NODE_ENV para usuários: https://webpack.js.org/guides/production-build /#node -variável de ambiente.

Isso me parece bastante sensato e deve evitar esse problema para quase todos que usam o webpack. Por que a insistência em lidar com isso em tempo de execução?

BTW, -p (modo "produção", que também permite minificação com configurações padrão) no webpack 2 define NODE_ENV para usuários: https://webpack.js.org/guides/production-build/#node -environment-variable.

Sim. Estamos cientes disso. @TheLarkInn do núcleo do Webpack pode confirmar com certeza, mas meu entendimento é que -p não é amplamente usado na comunidade do Webpack atm. O problema subjacente aqui também é que, se qualquer solução for opt-in, semelhante ao status quo atual com os avisos do console.log, é improvável que vejamos uma mudança real para os usuários do React. Queremos dar às pessoas uma mudança melhor no envio da coisa 'rápida'.

Vale a pena mencionar de passagem que a falta de poder detectar facilmente ambientes DEV e PROD no Webpack (-p sendo insuficiente) também nos causou algum problema em https://github.com/webpack/webpack/issues/3216.

Estou dizendo que a correção certa é que o webpack define o processo.NODE_ENV para você, ou o webpack apenas falha na compilação por padrão se você tentar fazer uma compilação de produção sem a configuração de produção apropriada.

Estou disposto a buscar isso, mas seria uma mudança inovadora para o Webpack, pelo que posso dizer. Pessoalmente, sinto que uma solução de tempo de execução que envolve uma mensagem de sobreposição clara _somente_ exibida usando algumas heurísticas inteligentes (localhost, DevTools aberto etc) nos cobriria adequadamente.

Dito isso, enquanto continuamos voltando ao item do Webpack process.NODE_ENV, eu ficaria curioso se @sokra ou @TheLarkInn tivessem alguma opinião sobre isso.

Meu entendimento difere do seu – acredito que -p é a maneira de fato que a maioria dos usuários não especialistas de webpack configuram compilações de produção.

Mesmo pacotes proeminentes usam -p para gerar compilações de produção:
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

É bastante incomum configurar diretamente o plugin Uglify no webpack, portanto, sem -p , as pessoas estariam usando compilações não minificadas, e nesse caso elas teriam problemas maiores.

Pessoalmente, sinto que uma solução de tempo de execução que envolve uma mensagem de sobreposição clara exibida apenas usando algumas heurísticas inteligentes (localhost, DevTools aberto etc.) nos cobriria adequadamente.

Eu sinto que isso foi derrubado várias vezes (“É inaceitável que um framework injete coisas no DOM”) sem realmente apreciar o _somente_ cenário em que isso aconteceria.

Estou totalmente com vocês que ter que lidar com uma mensagem permanente e coisas inesperadas no DOM constantemente durante o desenvolvimento é inaceitável. O que estamos sugerindo aqui, porém, é uma mensagem que é exibida se e _somente_ se o DevMode for implantado na produção (insira heurística!). Um número arbitrário de verificações e mensagens do console pode ser incorporado em ferramentas, CI e extensões de navegador para evitar que isso aconteça.

Mas, como um último recurso à prova de falhas, acho que um banner visível na tela é uma solução boa e apropriada.

exibido se e somente se o DevMode for implantado na produção (insira a heurística!)

Então, um desenvolvedor nunca verá essa mensagem, implantará (talvez acidentalmente) o modo dev em produção e, de repente, verá esse novo HTML sendo exibido em seu aplicativo para todos os usuários verem?

Isso soa mais como um castigo para mim. Se você ainda não entende o modo dev e implanta usando esta nova versão teórica do React com a mensagem, você terá uma surpresa e seus usuários no aplicativo da Web no momento também poderão vê-lo. Não consigo ver como isso ajuda alguém, mas serve para constranger o desenvolvedor ou a empresa. Claro, talvez isso faça com que eles consertem, mas esse custo é muito alto na minha opinião e falta um pouco de empatia.

Mas, como um último recurso à prova de falhas, acho que um banner visível na tela é uma solução boa e apropriada.

O problema com esta solução é que ela é muito idealista e quando você está desenvolvendo uma estrutura você deve focar na realidade de que outras empresas podem não ter as melhores políticas de implantação ou mesmo o melhor QA (se houver).

Sim, se alguém implantar no modo de desenvolvimento em produção, ele poderá vê-lo e alterá-lo rapidamente. Infelizmente, especialmente fora do setor de tecnologia, isso simplesmente não é possível ou não é fácil . A maioria das pessoas comentando aqui? Provavelmente, suas empresas têm processos de implantação que podem lidar bem com esse cenário. Google, Facebook, PlayStation, etc; todas essas empresas de tecnologia podem lidar com isso, mas isso não é representativo da maioria dos usuários que usam React, certo? (na verdade, temos alguma estatística sobre o uso do React? Seria útil!)

Sim, sim, essas empresas e o governo deveriam mudar seus processos e políticas de implantação etc etc. Mas a realidade é esta: a maioria das empresas tem processos de implantação de merda e lixo para QA inexistente.

Tomemos dois cenários em que experimentei pessoalmente.

Primeiro , enquanto estiver trabalhando no governo, dependendo da filial e do departamento, você provavelmente terá uma única implantação a cada 3-6 meses. Essas implantações acumulam o máximo de coisas possível e, se qualquer parte da implantação inteira falhar, tudo poderá ser revertido. Então, estávamos usando esse software chamado OWF que, se você não conhece, é como o iSocial, pois exibe vários aplicativos da Web em um único aplicativo da Web usando iframes (nojento, eu sei, mas fique comigo aqui). Houve uma etapa de configuração manual na implantação de vários de nossos aplicativos que falharam, o que causou a exibição de erros 404 e 500 em alguns dos iframes em vez do aplicativo pretendido.

Como os desenvolvedores normalmente não têm acesso ao sistema que está sendo implantado, levou muitas horas antes de descobrirmos qualquer problema. Nesse ponto, tivemos que fazer com que nosso chefe ligasse para o chefe de outra pessoa para ligar para o chefe deles e dizer que não afetava mais nada, para que não revertesse toda a implantação. Em seguida, tivemos toneladas de papelada e documentação para preencher antes que pudéssemos fazer alguém refazer parte da configuração vários dias depois. Enquanto isso, o aplicativo ficou parado, incapaz de funcionar, durante todo esse período de tempo.

Em segundo lugar , quando trabalhei em finanças, tivemos uma implantação que inadvertidamente incluía o nome de um desenvolvedor no lugar do layout de um item real no site (acredito que ele estava testando algo?). De qualquer forma, foi notado imediatamente, mas para consertá-lo tivemos que obter um controle de mudança de emergência através do qual demorou até muito mais tarde naquele dia. Então, seus clientes tiveram que ver esse banner estúpido por quase 8 horas antes de ser consertado.

Meu ponto é: é preciso ter muito cuidado ao injetar elementos arbitrários no DOM que o desenvolvedor não colocou lá. Especialmente se estivermos falando sobre exibi-lo apenas em alguns cenários, na primeira vez que alguém o vir, descobrirá como desativá-lo rapidamente para que não precise ser incomodado novamente.

@KrisSiegel

Se você ainda não entende o modo dev e implanta usando esta nova versão teórica do React com a mensagem, você terá uma surpresa e seus usuários no aplicativo da Web no momento também poderão vê-lo.

Eu estava curioso se seus pensamentos sobre a abordagem fossem diferentes se a mensagem fosse exibida apenas enquanto o DevTools estava aberto (ou seja, algo que teria uma baixa chance de ser visto por usuários de produção que não são desenvolvedores). Efetivamente uma expansão da atual estratégia console.log que o React já emprega hoje.

Eu estava curioso se seus pensamentos sobre a abordagem fossem diferentes se a mensagem fosse exibida apenas enquanto o DevTools estava aberto (ou seja, algo que teria uma baixa chance de ser visto por usuários de produção que não são desenvolvedores). Efetivamente uma expansão da atual estratégia console.log que o React já emprega hoje.

Se você tiver ferramentas de desenvolvimento abertas, provavelmente verá mensagens console.log, então as alterações do DOM parecem uma complexidade desnecessária para gerenciar, além de serem redundantes. Você sempre pode tornar as mensagens do console React maiores / mais sofisticadas. Talvez um logotipo ASCII React. Algo para chamar a atenção de alguém caso eles entrem lá.

Em última análise, embora eu ache que alguém se depararia com isso, pergunte no Stackoverflow como desabilitar o aviso, alguém postará código mostrando como fazê-lo, então as pessoas simplesmente o desabilitarão se o encontrarem. As ferramentas de construção são numerosas e muitas pessoas com quem conversei no passado as acharam confusas ou difíceis (o lançamento do Babel 6 foi uma época "divertida"). Você vai encontrar muitas pessoas que simplesmente nunca as usam corretamente.

Pelo menos essa é a minha experiência ¯\_(ツ)_/¯

Ufa, finalmente peguei o fundo da linha. OK. Eu tenho pensado nisso um pouco.

O Webpack poderia forçar a especificação de NODE_ENV que o React poderia usar para evitar mais facilmente que as pessoas enviassem DEV para PROD, mas isso seria uma alteração importante para o Webpack. Estou conversando com Sean agora sobre o quão viável algo assim poderia ser para o Webpack 3. Manter a pilha React + Webpack para iniciantes e perf amigável é algo que eu sei que ambos os campos se preocupam.

Este parece ser o meu favorito até agora, mas ainda não estou 100% vendido.

1. Assim, poderia impor que um ENV seja passado sempre que alguém executar o webpack. Uma mensagem de erro útil informa que você deve fornecer uma variável env para executar o webpack.

No entanto, isso fornece um ponto de rejeição significativo para os usuários. Nem todo mundo está escrevendo para um prod ou dev env ou mesmo sabe o que é um env. Vou levantar um problema no webpack/webpack para obter feedback sobre isso, porque meu pressentimento é que nem todo mundo vai querer isso e, concordando ou não, temos que considerar a reação.

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

2. A solução webpacky seria criar um plug-in autônomo que pudesse se conectar ao ciclo de vida do compilador, verificar se o código está sendo removido ou se um ENV não é fornecido e emitir um aviso amigável ou erro de sua escolha.

No entanto, posso imaginar que a resposta seja "Mas os usuários nunca saberão como fazer isso etc." Assim CRA, assim esta questão agora.

Poderíamos criar um novo padrão de resolução que verificará o package.json do React (ou qualquer fw que precise dele) para algo como abaixo:

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

que se aplicaria automaticamente a uma configuração de compilador de usuários sem que eles precisassem saber ou se importar.

Novamente apenas realmente brainstorming.

@TheLarkInn Acho que o comportamento atual de -p no webpack 2 é suficiente, não? O único caso de falha é se alguém configurar UglifyJsPlugin e esquecer de fazer DefinePlugin , mas esse parece ser um caso muito menos provável.

@taion Sim/Não

-p aplica apenas "tratamentos" de produção ao seu código, no entanto, não fazemos nenhuma suposição e/nem temos conhecimento do que NODE_ENV está definido. Isso é o que traz a necessidade de as pessoas usarem DefinePlugin() .

Mas eu acho que é a área "_reasonable_" mais próxima de _guess_ ou _imply_ que o usuário está executando seu código em um ENV de produção. Essa seria a única área que gostaríamos de ter certeza de que a comunidade e a equipe estão bem.

@TheLarkInn Acredito que isso mudou na v2: https://webpack.js.org/guides/production-build/#node -environment-variable

Ah desculpe isso mesmo estou enganado. No entanto, não é usado com frequência porque as pessoas querem um controle mais refinado sobre o que otimizam. (Como @addyosmani mencionado)

Isso é realmente tão comum? Quando eu estava começando com o webpack, -p claramente parecia o caminho a seguir. Como mencionei acima, mesmo bibliotecas com muitos motivos para aplicar mais ajustes ainda usam -p .

Poderíamos criar um novo padrão de resolução que verificará o package.json do React (ou qualquer fw que precise dele) para algo como abaixo:

"webpack": {
"plugin": "ReactEnviornmentPlugin"
}
que se aplicaria automaticamente a uma configuração de compilador de usuários sem que eles precisassem saber ou se importar.

@TheLarkInn se eu estiver lendo isso corretamente, para acionar o padrão do resolvedor, o package.json de um aplicativo precisaria especificar manualmente o ReactEnvironmentPlugin , certo? Ou estou entendendo mal a proposta? :)

Eu poderia imaginar alguma mágica de resolução no Webpack que detecta que um projeto está usando React e faz a troca de ambiente certa para eles, mas isso soa como um acoplamento apertado de otimização específica de estrutura para um empacotador e pode não ser tão desejável.

Menos que detectaria reagir, e mais que detectaria campos de descrição de módulos js incluem um campo webpack com um plug-in. Mas você está certo, é muito bem acoplado e também não é minha ideia favorita.

Eu não acho que isso realmente lhe dê nenhuma garantia, a menos que o webpack tenha um conceito de modo "produção" para descobrir como configurar o React - e isso parece redundante, já que, como discutido acima, -p já faz o certo coisa, e é o que os usuários geralmente buscam ao fazer uma compilação de produção minificada com o webpack de qualquer maneira.

Já conversamos um pouco mais sobre isso e acho que há uma solução razoável.

Há muito tempo consideramos habilitar uma “caixa de aviso” para avisos do React em desenvolvimento. Você pode ver uma demonstração aqui (PR: https://github.com/facebook/react/pull/7360). Ele só aparece quando você tem avisos, mas eles são muito comuns durante o desenvolvimento (e devem sempre ser corrigidos), então presumivelmente qualquer pessoa que tenha passado mais de cinco minutos desenvolvendo um aplicativo verá a caixa de diálogo e saberá que ela existe.

Após essa alteração, será mais difícil desconhecer o modo de desenvolvimento. Você provavelmente procurará por “como remover a caixa de diálogo de aviso” e aprenderá sobre a criação para produção. Se você não fizer isso, provavelmente receberá alguns avisos implantados em algum momento e seus usuários os verão. Eu acho que neste caso as pessoas não vão culpar o React por si só porque nós não mostramos apenas a caixa como desagradável - nós apenas fazemos o que o modo de desenvolvimento deve fazer.

(A propósito, estamos usando uma caixa de aviso semelhante em desenvolvimento no Facebook há muito tempo, então ela corresponde a como pretendemos que o React seja usado.)

Estou muito feliz em ver essa proposta, @gaearon! É tudo o que sonhei que fosse ;)

Apenas como um lado: talvez valha a pena considerar ter um link diretamente na caixa para não exigir que os desenvolvedores pesquisem no Google como se livrar dele.

Sim, bom ponto. Vamos adicionar algo.

@gaearon Acho essa solução altamente desagradável; Eu nunca gostaria que os avisos invadissem o DOM mesmo durante o desenvolvimento. Isso não serve a nenhum propósito para o desenvolvedor comum e provavelmente seria desabilitado inteiramente pela maioria. As ferramentas do desenvolvedor exibem avisos por um motivo, eles não precisam ser inventados.

Também acho preocupante que as soluções DOM continuem surgindo com zero refutações a qualquer um dos meus argumentos anteriores contra elas. Se meus pontos devem ser ignorados, então tudo bem, este não é meu repositório, então isso é justo o suficiente, mas é desanimador ver o mesmo argumento surgir, as pessoas postam contra ele, as pessoas parecem pelos pontos, pois nunca há um argumento contra eles , então eles simplesmente voltam para cima. Enxaguar, repetir.

Embora eu concorde que isso seja verdade sobre a maioria dos avisos, os avisos do React apontam especificamente os bugs em seu código. Não são apenas sugestões.

A caixa de diálogo é fácil de ignorar e os avisos individuais são fáceis de adiar (caso você não se importe com eles por um tempo), mas eles precisam ser corrigidos.

Para comparação, é assim que a caixa de diálogo se parece na base de código do Facebook:

Milhares de engenheiros não têm problemas com isso e são mais produtivos graças a ele, então achamos que é um padrão razoável. Para ser claro, a versão de código aberto será menos gritante:

Se você tiver sugestões sobre ajustes de estilo, sinta-se à vontade para comentar https://github.com/facebook/react/pull/7360.

Adicionando ao que Dan disse, estou construindo em cima do #7360 para conectar nosso fluxo de registrador de erros recentemente adicionado. Atualmente, estou testando alguns estilos de notificações do sistema que são um pouco menos intrusivos. Vou postar algumas capturas de tela e/ou um Plnkr em breve para feedback.

Esses avisos incluiriam o aviso "código de desenvolvimento minificado"? Isso resolveria muitas coisas perfeitamente se assim fosse.

Não vejo por que também não poderia ser usado para esse fim.

@gaearon

Embora eu concorde que isso seja verdade sobre a maioria dos avisos, os avisos do React apontam especificamente os bugs em seu código. Não são apenas sugestões.

Esses devem ser erros ou exceções IMO. Por que eles não são? Exceções forçam as coisas a serem corrigidas, mas um aviso descartável não.

Milhares de engenheiros não têm problemas com isso e são mais produtivos graças a ele, então achamos que é um padrão razoável.

Eu mencionei isso em um ponto anterior, mas acho que esses engenheiros provavelmente são melhores do que bons 90% das pessoas que usarão a versão de código aberto. Acho que é o oposto de um padrão razoável. Há uma razão pela qual as ferramentas de desenvolvimento têm avisos; reinventá-los não faz sentido para mim. Ele será desativado e nunca mais será visto.

Isso parece que o React está tentando fazer muito IMO.

Quando fiz contratos com o governo, tínhamos uma biblioteca comum que todos os front-ends tinham que usar. Levaria erros no console e os exibiria como um brinde. Não só foi implantado em produção várias vezes por várias equipes, mas muitos desenvolvedores o viram uma vez e perguntaram como desativá-lo permanentemente. Eu vejo isso como mais do mesmo.

Há muito tempo consideramos habilitar uma “caixa de aviso” para avisos do React em desenvolvimento. Você pode ver uma demonstração aqui (PR: #7360). Ele só aparece quando você tem avisos, mas eles são muito comuns durante o desenvolvimento (e devem sempre ser corrigidos), então presumivelmente qualquer pessoa que tenha passado mais de cinco minutos desenvolvendo um aplicativo verá a caixa de diálogo e saberá que ela existe.

Gosto muito do #7360, @gaearon. É animador ouvir o apoio para destacar a necessidade de mudar para PROD para implantações na nova caixa de aviso. É bonito e visual.

Adicionando ao que Dan disse, estou construindo em cima do #7360 para conectar nosso fluxo de registrador de erros recentemente adicionado. Atualmente, estou testando alguns estilos de notificações do sistema que são um pouco menos intrusivos. Vou postar algumas capturas de tela e/ou um Plnkr em breve para feedback.

@bvaughn Ansioso para ver mais de suas iterações :)

Para pessoas que acham que a abordagem da caixa de aviso pode ser muito intrusiva, outras bibliotecas (por exemplo, VueJS) já exibem sobreposições de DOM durante o fluxo de trabalho de desenvolvimento/iteração para incentivar a correção de bugs ou caminhos lentos:

Minha própria experiência foi que, embora seja um pequeno inconveniente, essas mensagens são mais óbvias do que você pode ver no console. Eu sinto que Dan está certo de que pelo menos colocará mais ênfase no modo dev, não sendo algo que você deve implantar para produzir e, esperançosamente, levará a mais sites enviando "modo mais rápido" para seus usuários finais.

Após essa alteração, será mais difícil desconhecer o modo de desenvolvimento. Você provavelmente procurará por "como remover a caixa de diálogo de aviso" e aprenderá sobre a criação para produção. Se você não fizer isso, provavelmente receberá alguns avisos implantados em algum momento e seus usuários os verão. Eu acho que neste caso as pessoas não vão culpar o React por si só porque nós não apenas mostramos que a caixa é desagradável - nós apenas fazemos o que o modo de desenvolvimento deve fazer.

Esses devem ser erros ou exceções IMO. Por que eles não são? Exceções forçam as coisas a serem corrigidas, mas um aviso descartável não.

Embora eles devam ser consertados, eu poderia ter assuntos mais urgentes em mãos. Por exemplo, eu frequentemente prototipo/mock up UIs e, ao fazer isso, escrevo código rápido e geralmente abaixo da média sobre o qual o React pode avisar. Embora eu queira corrigir esses avisos, não me importo até saber que não vou jogar fora todo o código na próxima hora, pelo menos. Forçar as pessoas a corrigi-los instantaneamente diminuirá drasticamente o desenvolvimento experimental.

Para pessoas que acham que a abordagem da caixa de aviso pode ser muito intrusiva, outras bibliotecas (por exemplo, VueJS) já exibem sobreposições de DOM durante o fluxo de trabalho de desenvolvimento/iteração para incentivar a correção de bugs ou caminhos lentos:

captura de tela 24/01/2017 às 10 57 11 am

Tem certeza que é do próprio Vue? Parece muito com os erros de compilação do webpack exibidos com a sobreposição de erro de webpack-hot-middleware . Se este for o caso, é sutilmente diferente porque é uma ferramenta de construção de tempo de desenvolvimento que adiciona a sobreposição em vez de uma estrutura de front-end de uso geral.

Em geral, sou a favor da sobreposição de aviso, mas acho que ela deve conter um texto explicativo que diga o que é, por que está lá e que pode e deve ser desabilitado como parte de desligar o modo dev. Atrás de um expando, se for um pouco longo - mas parece um lugar tão bom quanto qualquer outro para transmitir a mensagem.

Eu temo atualizações como 15.2.0 com uma sobreposição. pequena colisão e de repente você tem literalmente 100s de avisos sobre props sendo passados ​​para nós DOM. erros talvez, mas não acho que os avisos de depreciação pertençam a um espaço tão intrusivo

erros talvez, mas não acho que os avisos de depreciação pertençam a um espaço tão intrusivo

Não sei se isso foi comunicado muito claramente antes, mas a ideia em relação aos avisos de caixa amarela (#7360) não era mostrar _todos_ avisos (descontinuação ou outros). Em vez disso, certos avisos que a equipe considerasse _particularmente importantes_ seriam destacados dessa maneira. O resto presumivelmente permaneceria no console.

Pelo menos essa é a minha conclusão da conversa que Tom e eu tivemos sobre esse recurso uma ou duas semanas atrás.

O aviso de prop em 15.2 também foi um erro IMO e não indicativo de nosso MO normal. Gostaríamos de ter uma maneira de controlar os níveis de aviso por versões menores para evitar isso.

A principal razão pela qual nossa equipe não usa a compilação de produção é porque não podemos executar testes de unidade JS, já que os utilitários de teste não estão incluídos.

Primeiro, outra rodada de agradecimentos à equipe do React ( @sebmarkbage , @gaearon , @tomocchino e outros) por discutir esse problema conosco e estar tão aberto a conversar conosco sobre desempenho e mobilidade no BlinkOn e outras sincronizações neste trimestre.

Verificação de status

Por @aweary em https://github.com/facebook/react/pull/7360 , a solução Yellow Box para esse problema específico foi suspensa até que o trabalho V16 de alto nível do React seja concluído, mas ainda deve estar acontecendo. https://github.com/facebook/fbjs/pull/165 precisa pousar e ser implementado em Fiber. Uma boa API pública para expor hooks também precisa ser criada. Estarei guardando meus dedos 🤞

Este problema parece ainda prevalecer

Alguns dos aplicativos de produção que chegaram à minha mesa ainda estão enviando o modo DEV para produção. Podemos ver a string de depuração When deploying React apps to production em suas compilações aqui:

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)

Ainda sou da opinião de que uma mudança pré-Yellow Box para registrar o aviso do modo DEV no console para o acima pode ter algum impacto. A sugestão de Sebastian de lançar um erro no console para que o relatório de falhas pudesse pegá-los também foi algo que achei que valia a pena considerar.

O que mais podemos fazer para mover a agulha aqui?

Melhor advocacia? Estou feliz em me comprometer a continuar defendendo as pessoas que não enviam o modo DEV para produção, mas quero ver se podemos conseguir a solução oficial após a V16 :)

No curto prazo, parece que create-react-app está em um bom lugar para ajudar novos projetos a evitar esse problema.

Melhorias nos documentos de instalação

Para todos os outros, haveria suporte para https://facebook.github.io/react/docs/installation.html , incluindo um texto explicativo claro e visível sob o título Installing React , lembrando as pessoas de estarem atentas ao modo DEV no Produção?

Como usuário, não sinto que haja um grande incentivo para ler https://facebook.github.io/react/docs/installation.html#development -and-production-versions à primeira vista.

Pensamentos?

A principal razão pela qual nossa equipe não usa a compilação de produção é porque não podemos executar testes de unidade JS, já que os utilitários de teste não estão incluídos.

Estou confuso sobre isso. Você está executando testes no site de produção? Se não, o que impede você de usar o build de produção no site de produção e o build de desenvolvimento no desenvolvimento?

Para todos os outros, haveria suporte para https://facebook.github.io/react/docs/installation.html , incluindo um texto explicativo claro e visível sob o título Instalando o React, lembrando as pessoas de estarem atentas ao modo DEV na produção?

Certo. Quer enviar um PR?

Certo. Quer enviar um PR?

Mais do que feliz.

Talvez uma palavra sobre benchmarks seria bom também para ajudar a educar aqueles que comparam perfs com react no modo dev?

Faz-me pensar que a extensão react devtools pode ser aproveitada para exibir uma notificação ou algo óbvio ao abrir uma página usando reagir no modo dev talvez?

Eu gosto desta ideia! Eu montei um conjunto de ícones propostos para os devtools (veja facebook/react-devtools/pull/652).

Precisamos decidir como detectar dev vs prod React de uma maneira que seja para trás e segura para o futuro, mas adicionei isso à agenda da reunião de segunda-feira.

Fizemos algumas etapas razoáveis ​​para resolver esse problema:

• O React DevTools (com ~ 700 mil usuários) agora exibe um ícone vermelho distinto para compilações de desenvolvimento. Isso ajuda as pessoas a aprender mais cedo sobre a diferença entre as versões. Isso também cria alguma pressão dos colegas, pois os desenvolvedores percebem isso nos sites que visitam e relatam às pessoas que trabalham neles. Vimos alguns sites importantes corrigirem o problema alguns dias após o lançamento.

• O aviso no React DevTools leva ao nosso site onde publicamos instruções para criar a compilação de produção para todos os principais bundlers . Também o tornamos mais proeminente na página de instalação .

• Create React App continuou a ganhar popularidade. Ele ensina essa distinção cedo com comandos separados. Ele também exibe um aviso permanente sobre o modo de desenvolvimento no terminal.

• O React 16 Beta 1 (e versões posteriores) é fornecido com react.development.js e react.production.min.js como nomes de arquivo para deixar claro que a compilação não minificada não deve ser usada em produção.

Acho que no futuro podemos explorar mais maneiras de resolver esse problema, mas por enquanto sinto que podemos seguir em frente sem medidas mais drásticas e ver se isso ajuda. Obrigado a todos pela discussão.