React: 사용자에게 DEV 모드를 프로덕션으로 제공하지 않도록 권장하는 방법 탐색

참고: https://github.com/facebook/react/pull/8782

문맥상 React의 DEV 버전을 축소했음을 감지하면 이미 경고합니다. https://github.com/facebook/react/blob/8791325db03725ef4801fc58b35a3bb4486a8904/src/renderers/dom/ReactDOM.js#L91 -L98

사용자에게 알리기 위해 유사한 휴리스틱을 찾을 수 있고 DOM 대화 상자를 더 적극적으로 표시할 수 있는 한 그래야 합니다.

나는 또한 사람들이 주의를 기울인다면 우리가 제공하는 경고가 성능을 크게 향상시킬 수 있음을 분명히 하고 싶습니다. 이 스레드는 기본값이 아닌 경우 나중에 배포하기 어려운 이유에 대한 몇 가지 근거를 설명합니다 .

또한 renderToString 가 개발 모드에서 호출되는 경우 단일 console.warn 제안과 함께 차임하고 싶습니다. 분명히 대부분의 상황에서 renderToString 는 노드에서 호출되며 DOM 대화 상자를 경고하거나 팝업할 수 없습니다.

불행히도 NODE_ENV 가 production 로 설정되어 있는지 뿐만 아니라 process.env.NODE_ENV 가 컴파일되었는지도 확인하고 싶습니다. 누구든지 그렇게하는 방법을 알고 있습니까?

@sebmarkbage 스레드에 감사드리며 사실 이후에 배포하는 데 어려움이 있음을 인정합니다. 또한 현재의 경고에 감사드립니다. 일부 개발자는 배포된 사이트의 콘솔 출력을 가능한 한 자주 확인하지 않을 수 있습니다. 그러나 좋은 첫 단계입니다.

사용자에게 알리기 위해 유사한 휴리스틱을 찾을 수 있고 DOM 대화 상자를 더 적극적으로 표시할 수 있는 한 그래야 합니다.

사용자에게 알리는 데 사용되는 경험적 방법을 개선해 주셔서 감사합니다. 보다 적극적인 DOM 대화 상자가 도움이 될 것입니다. 그것은 사이트가 최종 사용자를 위해 계속 작동하도록 보장하지만 개발자가 선택할 수 있는 낮은 성능의 과일이 있다는 적극적인 힌트를 제공합니다.

대안은 원본 게시물에서 언급한 대로 빌드 도구/ENV 수준에서 이 문제를 해결할 수 있는 방법을 찾는 것입니다. 그러면 DOM 주입이 필요하지 않습니다.

DOM에 메시징을 삽입하는 것은 위험하고 너무 가정적인 것처럼 보입니다. 이는 최종 사용자가 수용할 수 없는 IMO로 보이는 예상치 못한 혼란스러운 경고를 받을 가능성을 열어줍니다.

@thelarkinn 은 이와 같은 메시지 감지를 더 쉽게 하기 위해 필요한 ENV 구성을 표준화하려고 시도했다고 제안했습니다.

이 문제를 해결하기 위한 이상적인 공간인 것 같습니다. 이는 빌드 문제이며 가능한 경우 빌드 도구로 해결해야 합니다.

일화: 과거에는 콘솔의 경고가 보이지 않거나 무시되었습니다. 여기에 정확한 수치는 없지만 콘솔 기반 경고로는 충분하지 않다고 생각합니다. 나는 DOM 기반 경고가 먼 길을 갈 것이라는 @addyosmani 의 말에 동의합니다.

@surma 더 나은 가시성을 위해 console.warn 또는 console.error 를 사용해야 합니다 😉

프로덕션 환경에서 실행 중일 때만 애플리케이션에 콘텐츠를 삽입하는 것이 어떤 시나리오에서도 허용되는지 모르겠습니다. 애플리케이션이 실제 사용자에게 푸시되기 전에 메시지가 포착되어 메시지가 잠재적으로 UX에 큰 피해를 줄 수 있다는 큰 가정을 하고 있습니다.

Btw, 우리는 Fiber에서 보다 포괄적인 오류 처리 지원을 추가할 예정이므로 오류(오류 발생)가 있는 구성 요소를 사용자 지정 오류 보기로 교체할 수 있습니다. 기본 시나리오에서도 우리는 매우 공격적일 가능성이 높으며 오류가 발생하면 트리에서 해당 구성 요소를 제거하여 어쨌든 사용자를 위한 사용자 정의 오류 UI를 원할 것입니다.

이 경고에 대해 이러한 오류를 트리거할 수 있습니다.

솔직히 console.log console.{error,warn} 가 바뀌었다고 생각하지 않습니다. 내가 말했듯이, 그 이야기는 일화입니다.

또한 DOM 대화 상자를 표시하는 것이 _the_ 솔루션이라고 말하는 것이 아닙니다. 그래도 개인적으로 마음에 드는 부분입니다. 개발 모드를 유지하는 것이 부정적인 영향을 미치는 경우 최소한 사용자는 _무언가_가 잘못되었다는 것을 알고 아마도 "도움말" 버튼을 누르기 시작할 것입니다.

결론: 프레임워크는 어느 시점에서 개발자의 얼굴에 들어가야 한다고 생각합니다. 앞으로 사람들이 개발 모드로 배포하는 것을 방지하기 위해 프레임워크 작성자가 어떤 단계와 타협을 취할 것인지 알아보기 위해 이에 대해 브레인스토밍을 하고 싶습니다.

개발용이든 제품용이든 상관없이 환경을 제공하지 않으면 React가 전혀 작동하지 않는다면 어떻게 될까요? 그런 식으로 의식적인 선택이 이루어집니다.

DOM에 주입된 메시지에 대해 전역 또는 기타를 사용하여 비활성화할 수 있습니다. 큰 문제가 없습니다. 당신이 그것을 비활성화하면, 당신은 당신이하고있는 일을 알고 있음을 인정합니다.

콘솔 메시지의 문제는 때때로 사람들이 많은 것을 기록하거나 무시하는 다른 경고가 있다는 것입니다. 스크롤을 지나면 첫 번째 콘솔 메시지가 보이지 않기 쉽습니다...

필수 env를 사용하면 필연적으로 상용구 등이 env var를 설정하므로 사용을 시작할 수 있습니다.

솔직히 console.log를 통한 console.{error,warn}이 변경되었을 것이라고 생각하지 않습니다.

개발자가 콘솔을 확인하지 않거나 콘솔에 경고가 과부하되는 것이 문제라고 생각하십니까? 개발자 교육에 관한 보다 일반적인 접근 방식으로 이 문제를 (부분적으로) 해결할 수 있습니까?

또한 DOM 대화 상자를 표시하는 것이 해결책이라고 말하는 것이 아닙니다. 그래도 개인적으로 마음에 드는 부분입니다. 개발 모드를 유지하는 것이 부정적인 영향을 미치는 경우 최소한 사용자는 뭔가 잘못되었다는 것을 알고 "도움말" 버튼 등을 누르기 시작할 것입니다.

나는 그것을 이해하지만, 나는 그것이 해결책 은 물론 이고 해결책이라고 생각하지 않는다고 말하는 것입니다. 당신이 그것에 익숙해지는 것은 좋지만 대부분의 사람들은 사용자에게 예기치 않은 오류가 표시되는 것을 원하지 않는다고 가정하고 주의를 기울이는 것이 더 낫다고 생각합니다.

결론: 프레임워크는 어느 시점에서 개발자의 얼굴에 들어가야 한다고 생각합니다. 앞으로 사람들이 개발 모드로 배포하는 것을 방지하기 위해 프레임워크 작성자가 어떤 단계와 타협을 취할 것인지 알아보기 위해 이에 대해 브레인스토밍을 하고 싶습니다.

저는 💯 개발자의 얼굴을 마주하고 싶지만 올바른 장소에서 하는 것이 중요합니다. 나에게 그것은 생산 단계가 아니라 빌드 단계입니다.

DOM에 주입된 메시지에 대해 전역 또는 기타를 사용하여 비활성화할 수 있습니다. 큰 문제가 없습니다. 당신이 그것을 비활성화하면, 당신은 당신이하고있는 일을 알고 있음을 인정합니다.

기본적으로 활성화하는 것은 구성하지 않는 것만큼이나 나쁩니다. 기본 동작은 최종 사용자에게 예기치 않은 동작을 초래할 수 있습니다. 기본적으로 비활성화되어야 하지만 개발자가 초기 문제를 인식하면 초기 문제를 해결할 수 있기 때문에 전체 목적을 무효화합니다.

콘솔 메시지의 문제는 때때로 사람들이 많은 것을 기록하거나 무시하는 다른 경고가 있다는 것입니다. 스크롤을 지나면 첫 번째 콘솔 메시지가 보이지 않기 쉽습니다...

나는 완전히 이해합니다. 콘솔이 혼잡해질 수 있고 물건을 놓치기 쉽습니다. 그러나 내가 주장하는 정확한 이유 때문에 혼잡합니다. 개발자에게 피드백이나 오류를 제공 하는 곳입니다. 주입된 메시지가 아닌 사용자 경험을 방해하지 않습니다.

이해가 됩니다. 그 이유를 이해합니다.

글쎄, 아마도 콘솔 포맷을 사용하여 무언가를 튀어 나오게 만드는 것은 적어도 뭔가가 될 것입니다.

문제는 거의 아무도 프로덕션 환경에서 콘솔을 보지 않는다는 것입니다. 거기에 있는 어떤 글꼴이든 사용할 수 있으며 사람들은 그것을 눈치채지 못할 것입니다.

그러나 프로덕션에서 기본적으로 주요 변경 사항(16 또는 17)으로 메시지를 표시하도록 하면 놓치기 어려울 것입니다. 내 말은, 그것은 (신규 사용자를 위해) 그것을 처음 배포하려고 할 때 발생하며 기존 사용자는 새로운 메이저로 업데이트할 때 릴리스 정보를 읽어야 합니다. 그래서 저는 우리가 그것에 대해 매우 명백하고 메시지를 놓칠 수 없는 한 가능하다고 생각합니다.

문제는 거의 아무도 프로덕션 환경에서 콘솔을 보지 않는다는 것입니다. 거기에 있는 어떤 글꼴이든 사용할 수 있으며 사람들은 그것을 눈치채지 못할 것입니다.

이에 대한 Chrome 팀의 경험에 대해서만 언급할 수 있지만 동의합니다. 대부분의 사람들은 반복 작업 과정에서 콘솔 메시지를 알아차리겠지만 프로덕션 사이트에서 경고를 확인하고 그에 대한 조치를 취하는 사람은 훨씬 적습니다.

그러나 프로덕션에서 기본적으로 주요 변경 사항(16 또는 17)으로 메시지를 표시하도록 하면 놓치기 어려울 것입니다. 내 말은, 그것은 (신규 사용자를 위해) 그것을 처음 배포하려고 할 때 발생하며 기존 사용자는 새로운 메이저로 업데이트할 때 릴리스 정보를 읽어야 합니다. 그래서 저는 우리가 그것에 대해 매우 명백하고 메시지를 놓칠 수 없는 한 가능하다고 생각합니다.

@gaearon과 같은 변화를 열어주셔서 감사합니다. 향후 릴리스에서 기본적으로 메시지를 시도하는 데 동의하려면 어떻게 해야 합니까? 😄

콘솔 경고가 솔루션이 아니며 페이지에 표시되는 경고가 훨씬 낫다는 데 동의합니다.

페이지 표시 경고는 다음을 수행할 수 있습니다.

• 사이트가 개발자 모드에 있음을 개발자에게 알립니다.
• 혜택 및 혜택 없이 배송하는 방법에 대한 문서 링크
• 메시지를 비활성화하는 링크... 2시간 동안 몰라요?

메시지를 비활성화하는 것은 페이지의 무언가를 방해/가릴 수 있으므로 중요합니다. 이 설정은 localstorage에 저장되므로 원본이 다르기 때문에 라이브 서버에 경고가 계속 표시됩니다.

예, 실제 사용자가 라이브 사이트에서 이 메시지를 보는 것은 매우 끔찍하지만 일부는 개발자가 수정하도록 권장되는 문제 유형인 것처럼 느껴지지만 일부는 개발 모드의 성능 문제를 안고 사는 것에 만족하는 것 같습니다.

그 경고(DOM에 삽입)를 처음 보았을 때 프로덕션 단계에 있었다면 상당히 화가 났을 것입니다. 경고는 미리 발생해야 합니다.

@rtorr 내 제안은 사이트가 개발 모드에 있을 때마다 발생하므로 내가 누락된 것이 없는 한 미리 보아야 한다는 것입니다.

@jakearchibald 혼란을 드려 죄송합니다. 제 답변은 귀하를 대상으로 한 것이 아닙니다. 스레드에 'insert into the dom' 솔루션을 사용하려는 경우 매우 조심해야 하고 사용자가 무언가를 푸시하기 전에 알도록 해야 한다는 점을 지적하고 싶습니다. .

나는 단지 어떤 개발자가 설정이나 무엇인가를 잊어버리고 경영진이 겁에 질려 있는 것을 보았습니다. 프로덕션에서 개발 모드를 사용하는 결과에 대해 그 가능성이 가치가 있습니까?

지속적으로 비활성화해야 한다는 DOM 기반 경고는 괜찮지 않습니다. 영원히 비활성화할 수 있어야 하며 localhost에 대해 전혀 표시되지 않아야 합니다.

devtools를 활성화하기 위해 활성화해야 하는 브라우저에 일종의 플래그가 있는 것이 가능하다면 저를 때린 것입니다("당신은 개발자입니까? [예/아니요]"와 함께 큰 오버레이가 있을 수 있습니다) ) 페이지에서 감지하고 개발자에게만 경고를 표시할 수 있습니다. 올바르게 작성하면 자체 XXS 공격에도 도움이 될 수 있습니다.

지속적으로 비활성화해야 한다는 DOM 기반 경고는 괜찮지 않습니다. 영원히 비활성화할 수 있어야 합니다.

개발 모드를 켠 상태로 사이트를 시작하는 것도 좋지 않습니다. 메시지를 하루에 한 번만 닫으면 될까요? 그러나 기간이 길수록 라이브로 끝날 가능성이 높아집니다. 영원히 비활성화할 수 있다면, 우리는 우리가 시작한 곳으로 바로 돌아갈 수 있습니다.

나는 또한 프로덕션에서 의도하지 않은 dom 노드가 괜찮다고 생각하지 않습니다.

어느 쪽이든, 우리는 항상 극단적인 경우가 있을 것이라고 생각합니다. 이 문제가 항상 발생한다면 개발 모드의 전달이 잘못된 것일 수 있습니다. 완벽한 세상에서 이상적이지는 않지만, 누군가의 애플리케이션을 기꺼이 수정할 수 있는 prod 모드가 중요하다고 생각한다면 아마도 기본 모드가 되어야 하고 개발 모드는 옵트인되어야 합니다.

@rtorr

나는 또한 프로덕션에서 의도하지 않은 dom 노드가 괜찮다고 생각하지 않습니다.

왜요? (당신이 틀렸다고 말하는 것이 아니라 당신의 이유를 듣고 싶습니다)

prod 도메인을 정의하기 위한 설정을 추가할 수 있습니다. prod 도메인이 설정되어 있지 않으면 항상 DEV 모드에 대한 경고(도메인 URL 설정 요청 포함)를 받고, 설정되어 있으면 URL이 prod 도메인과 일치할 때만 경고를 받습니다. 개발자에게 알리고 싶은 모든 서비스를 바인딩할 수도 있습니다.

여기에서 건설적인 논의가 이루어지고 있어 기쁩니다. 문제 해결을 볼 수 있는 두 가지 솔루션이 있습니다. Webpack은 React가 DEV를 PROD로 배송하는 사람들을 더 쉽게 피하기 위해 사용할 수 있는 NODE_ENV를 강제로 지정할 수 있지만 이는 Webpack의 주요 변경 사항이 될 것입니다. 나는 지금 Webpack 3에서 이와 같은 것이 얼마나 실현 가능한지에 대해 Sean과 이야기하고 있습니다. React + Webpack 스택을 초보자와 성능 친화적으로 유지하는 것은 두 진영 모두 관심을 갖고 있다는 것을 알고 있습니다.

두 번째(DOM 주입 아이디어)는 React가 할 수 있는 일이며 Jake가 언급했듯이 메시지가 하루에 한 번 표시되거나 무시되도록 허용하여 UX의 균형을 유지합니다. 문제를 해결하기 위해 한 줄만 변경하면 다시 배포하기만 하면 됩니다. 경영진이 놀라지 않기를 바라는 마음에 전적으로 공감합니다.

훨씬 더 빠른 경험을 제공하는 더 많은 React 사이트를 얻으려면 FB가 제공해야 할 제품을 생산하기 위해 작업했습니다. 누구든지 더 나은 아이디어가 있으면 제안하십시오.

@jakearchibald

왜요? (당신이 틀렸다고 말하는 것이 아니라 당신의 이유를 듣고 싶습니다)

위의 내 의견으로 돌아가서 개발자에게 미리 알릴 수 없는 한(이는 실제 해결해야 할 문제인 것 같습니다), 프로덕션 페이지에서 개발자에게 경고를 표시하여 누군가의 제품을 평가 절하하는 것은 일종의 극단적인 일입니다. 많은 경우에 이것은 잠재적으로 개발 모드의 성능보다 제품을 더 손상시킬 수 있습니다.

우리가 무엇을 하든지 간에 기본값이 무엇이든 프로덕션으로 출하할 것입니다. 프로덕션 기본값을 설정하지 않는 이유는 무엇입니까? 그렇게 큰 영향을 미치지 않는 수준까지 개발 모드를 개선하지 않는 이유는 무엇입니까?

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

@jakearchibald 예, 양쪽에 문제가 있는 것 같습니다. 나는 이 스레드에 있는 사람들이 당신이 제안하는 것이더라도 좋은 것을 생각해 낼 것이라고 믿습니다. 참고로 모두 훌륭합니다. 극단적인 것이 답일 수도 있습니다.

사용자가 React dev 도구를 실행 중이면 일반 사용자가 경험하지 못하도록 DOM 노드 경고를 삽입할 수 없습니까?

@jakearchibald

개발 모드를 켠 상태로 사이트를 시작하는 것도 좋지 않습니다. 메시지를 하루에 한 번만 닫으면 될까요? 그러나 기간이 길수록 라이브로 끝날 가능성이 높아집니다. 영원히 비활성화할 수 있다면, 우리는 우리가 시작한 곳으로 바로 돌아갈 수 있습니다.

사이트가 시작되었을 때 누군가가 "준비"된 것으로 결정을 내렸으므로 상태는 좋지 않지만 재앙은 아닙니다. 그러나 수십만 명의 개발자가 사이트 파괴(DOM 경고는 사이트의 나머지 부분과 상호 작용하는 방식을 모르기 때문에 처리해야 함 경고가 표시된 상태에서 사이트를 사용할 수 있는 경우) 경고 5개 또는 하루에 한 번만 경고하는 것은 재앙입니다. 대부분의 개발자는 빌드 체인(사용자 지정, create-react-app 또는 기타)을 올바르게 설정하고 해당 경고를 전혀 사용할 수 없으므로 제거할 수 있어야 합니다.

@dan-gamble 저는 개발자가 React Dev Tools를 사용하지 않는 것이 이 경고의 가장 시급한 대상이라고 생각합니다.

@Pajn 잠재적으로 Chrome 확장 프로그램을 다운로드한다고 해서 자동으로 prod / dev 스위치를 인식하게 한다고 생각하지 않습니다.

@dan-gamble 아니요, 물론 아닙니다. 그러나 앱 없이 전체 앱을 개발하는 사람들이 있는데, 이는 개발 도구를 많이 사용하지 않으므로 축소된 코드에 대한 현재 경고를 볼 가능성이 적습니다.

나는 일반적으로 요점이 이미 제기된 것처럼 느껴질 때 긴 토론에 추가하지 않지만 이 점에 동의하고 강조하고 싶습니다. DOM을 만지고 내가 dev 버전을 사용하고 있다고 경고하는 React 큰 실수가 될 것입니다. 내가 아는 한 다른 프레임워크에는 이에 대한 전례가 없습니다.

모든 튜토리얼, 모든 플레이그라운드, dev 모드를 사용하여 React를 가르치는 모든 작은 사이드 프로젝트를 상상해 보세요. React에서 재미있는 것을 탐색하거나 테스트 케이스를 분리하려고 함께 하는 모든 작은 테스트 사이트. 수동으로 비활성화해야 하는 이러한 사이트의 모든 단일 경고를 통해 반응하면 나는 엄청나게 화를 낼 것입니다. 그것은 위압적인 부모처럼 느껴지고 새로운 것을 시도할 때마다 손목을 때리기 때문에 React를 사용하는 것을 적극적으로 권장하지 않습니다 .

심지어 2시간에 한번씩 ? 아니요 괜찮습니다. 이와 같은 끊임없는 잔소리는 확실히 사용자가 React에서 개발하는 것을 방해할 것이고 솔직히 말해서 사람들이 다른 프레임워크를 채택하도록 밀어낼 것이라고 생각합니다. 이것이 Chrome 개발자가 원하는 것이 아닐까요?

예, 이것이 어떻게든 생산에 들어갈 것이라는 사실은 말할 것도 없고, 특정 팀이 React를 채택하도록 설득하는 것은 이미 충분히 어렵습니다.

내가 React에 대해 가장 좋아하는 것은 ReactDOM.render(...) 를 호출할 때까지 아무 것도 하지 않고, 그렇게 할 때 사용자가 지시한 DOM에만 물건을 넣는다는 것입니다. 이것이 바로 이것이 훌륭하고 격리된 기능적 라이브러리인 이유입니다.

사람들이 축소되지 않은 번들을 배송하는지 여부도 감지해야 합니까? 캐싱해야 할 때 캐싱하지 않으면 어떻게 됩니까? nginx를 최적으로 구성하지 않은 경우는 어떻게 됩니까? 아니면 shouldComponentUpdate 를 사용해야 할 때 사용하지 않습니까? 아니면 필요하지 않은데도 모든 것을 불필요하게 렌더링하고 있습니까?

성능이 좋지 않은 데에는 몇 가지 이유가 있으며 React의 개발 모드에서만 이를 비난하는 것은 잘못된 것입니다. 사이트를 배포할 때 최적화된 사이트를 배포하는 방법을 이해하고 있어야 합니다. 우리가 할 수 있는 일이 없다는 말은 아니지만 이 문제의 핵심 이유는 벤치마크 작성자가 실사를 하지 않고 있으며 우리가 그 비용을 지불할 필요가 없기 때문입니다. 우리는 그것을 불러낼 다른 방법을 찾아야 합니다.

나는 올바른 해결책이라고 생각하는 것에 대한 후속 조치를 취하려고 했습니다. 도구에 이러한 종류의 제한을 두는 것입니다. 웹팩이나 프로덕션을 위해 사이트를 구축하는 데 사용하는 도구가 이러한 검사를 강제해야 하는 위치인지 확인하고 빌드 프로세스에 적용하려는 모든 종류의 제한 사항이 없습니다.

NODE_ENV 설정을 강제하는 webpack과 관련하여(이미 해당 저장소에 문제가 있을 수 있음) env 설정에 의존하지 않는 라이브러리를 사용하는 것이 더 어려워지지 않습니까?

아니면 NODE_ENV 사용을 감지하고 코드가 사용하는 경우에만 강제로 사용한다는 아이디어입니까?

"2시간"에 너무 연연하지 맙시다. 그것은 작동하는 한 기간이 될 수 있습니다.

또한 로컬 스토리지 이벤트는 오리진당 한 번만 해제하면 됨을 의미합니다. 한 페이지에 여러 데모가 있는 경우 하나를 닫으면 다른 것도 닫힙니다.

경고가 실시간으로 실행되는 경우 사용자에게 도움이 되는 빠른 수정이 필요할 정도로 시끄럽습니다. React가 공개적으로 어떻게 보이는지 걱정된다면 이와 같은 불필요한 속도 저하를 피하고 싶습니다.

물론 이것은 잘못된 캐싱 헤더 등을 감지하지 못합니다. 이것은 "개발 모드"만 감지하는 것입니다. 또한 "미끄러운 경사" 인수는 도움이 되지 않습니다.

개발자가 다른 빌드 도구를 사용하거나 프로덕션 모드로 전환하지 못하는 경우 동일한 문제가 발생하므로 문제를 빌드 도구로 옮기는 것은 유용하지 않다고 생각합니다. 개발 모드 프레임워크는 이미 콘솔 경고를 생성하며 분명히 작동하지 않습니다.

이것은 벤치마크에 관한 것이 아니라 스위치가 전환되지 않았기 때문에 실제 사용자에게 느리게 실행되는 실제 웹사이트에 관한 것입니다.

@jakearchibald 감정이입된 저의 이성적인 답변에 감사드립니다. React에서 사이트가 느려지는 데에는 여러 가지 이유가 있다는 것이 타당한 지적이라고 생각합니다. 개발 모드 및 브라우저 내 경고에 대한 조잡한 확인보다 더 나은 성능 향상을 제안할 수 있는 방법을 보고 싶습니다. React 앱을 분석하고 개발 모드와 같은 모든 것부터 너무 많은 재렌더링에 이르기까지 성능에 대한 진지한 제안을 제공하는 도구가 있다면 훨씬 더 유용할 것입니다. 이와 같은 일반 도구는 webpack, browserify 등 모든 파이프라인에 연결할 수 있습니다.

이것이 내가 말하고 싶은 주요 내용입니다. 언젠가는 jsbin, 자습서, 심지어 작은 테스트 사이트를 함께 던지고 file:// 프로토콜로 여는 것과 같은 5-10개의 다른 장소에서 React 개발 모드를 사용할 것입니다. 강제적인 브라우저 내 경고는 웹이 매우 뛰어난 이러한 종류의 유연한 개발에 적대적입니다. 나는 웹의 여러 도메인에서 React를 배우고 있기 때문에 모든 곳에서 이러한 경고를 보게 될 것입니다.

경고가 실시간으로 실행되는 경우 사용자에게 도움이 되는 빠른 수정이 필요할 정도로 시끄럽습니다. React가 공개적으로 어떻게 보이는지 걱정된다면 이와 같은 불필요한 속도 저하를 피하고 싶습니다.

최종 사용자에게 개발자별 경고가 표시될 가능성을 허용하는 것조차 용납되지 않는 것 같습니다. 느린 사이트는 한 가지이지만 이와 같은 메시지는 특히 보안에 중점을 둔 사이트의 경우 사용자 신뢰를 훼손할 수 있습니다(은행 사이트에 갑자기 수수께끼 같은 오류가 표시된다면 기쁠 것입니까?) 잠시만이라도 사용자가 갑자기 이 경고를 받게 됩니까?

또한 로컬 스토리지 이벤트는 오리진당 한 번만 해제하면 됨을 의미합니다. 한 페이지에 여러 데모가 있는 경우 하나를 닫으면 다른 것도 닫힙니다.

중복 제거를 위해 localStorage 에 의존할 수 없습니다. localStorage (또는 다른 로컬 영구 데이터)가 어떤 간격으로도 지워지지 않는다는 보장은 없습니다.

편집 : 또한 {INTERVAL} 마다 한 번만 오류를 표시함으로써 결정론적으로 재현할 수 없기 때문에 재현 및 디버그하기가 훨씬 더 어려워졌습니다.

해결해야 할 2가지 경우가 있습니다.

• 잘못된 벤치마크, 성능 테스트 방지: 큰 콘솔 메시지로 쉽게 해결됩니다.
• DEV를 프로덕션 사이트로 배송하는 것을 방지: 사람들은 프로덕션에서 devtools를 열지 않습니다.

DOM을 건드리지 말라는 주장은 설득력이 있습니다.

크고 화려하고 분명한 콘솔 경고가 있는 경우 프로덕션으로 배송하기 전에 사람들이 개발 버전을 사용하고 이 명백한 콘솔 메시지를 볼 가능성이 있습니다. 또는 일부 코드가 이미 프로덕션으로 배송되었지만 다른 프로젝트에서는 콘솔 메시지를 놓칠 수 없는 다음 반응 버전을 사용할 것입니다. 아마도 그들은 프로덕션으로 배송한 사이트를 기억하고 거기에서 DEV가 활성화되어 있는지 확인할 것입니다.

콘솔 메시지는 교육적일 것입니다. 예를 들어 React 개발을 하는 사람이라면 누구나 DEV에 대해 정말 중요한 것이 있다는 것을 알고 있으며 개발을 위해 React를 사용할 때마다 그것을 봅니다.

사람들은 일반적으로 제거할 수 없는 경고를 좋아하지 않기 때문에 https://github.com/facebook/react/pull/8782 에 대해 주저했습니다(https://github.com/facebook/react/issues/ 참조). 3877), 그러나 대안을 고려하면 수용 가능한 솔루션일 수 있습니다.

궁금한. localStorage를 사용하면 다른 방식으로 적용되지 않는 사이트에서 EU 쿠키 법률이 적용됩니까?

개발 중 유익한 경고가 좋은 생각이라면 왜 다른 라이브러리에서는 그렇게 하지 않습니까? 글쎄, 한 가지 이유는 이와 같은 문제에 대한 것입니다. 다른 사람들이 이것을 하기를 원했다면 그들도 유사한 UI를 팝업해야 합니까? 모두 닫아야 하나요?

이 문제를 처리하기 위해 더 중심적인 것이 있으면 이상적일 것 같습니다.

Chrome에 개발 모드가 있을 수 있습니까? 라이브러리는 호스트에게 개발 모드에 있음을 알리면 Chrome에서 배지를 추가하거나 이를 나타내기 위해 팝업을 표시할 수 있습니다.

react devtools 확장을 활용하여 dev 모드에서 react를 사용하여 페이지를 열 때 알림이나 분명한 것을 표시할 수 있다고 생각합니까?

@sebmarkbage

개발 중 유익한 경고가 좋은 생각이라면 왜 다른 라이브러리에서는 그렇게 하지 않습니까?

누군가가 먼저 되어야 한다고 생각합니다. Angular에는 http://code.gov 와 같은 항목이 개발 모드에서 시작되는 유사한 문제가 있습니다. 다른 프레임워크가 없는 곳에서 React가 이 항목을 잡기 시작하면 비슷한 변경을 하도록 밀어붙일 것입니다.

나는 그들에게 비슷한 변화를 일으키도록 강요할 것입니다.

@jakearchibald 각 프레임워크가 자체 경고를 제공해야 한다고 제안하고 있습니까? 프로덕션 환경에서 자체 개발 경고를 제공하는 프레임워크/라이브러리에 대한 표준을 설정하는 것은 좋은 생각이 아니라고 생각합니다. 플랫폼에서 표준화를 시도해야 하지 않습니까? @sebmarkbage 가 언급했듯이

Chrome에 개발 모드가 있을 수 있습니까? 라이브러리는 호스트에게 개발 모드에 있음을 알리면 Chrome에서 배지를 추가하거나 이를 나타내기 위해 팝업을 표시할 수 있습니다.

좋은 아이디어라고 생각합니다. 선례: Safari에는 DevTools에 액세스하기 위해 활성화해야 하는 별도의 모드가 있습니다. Chrome이 동일한 작업을 수행했다면 DEV 모드에 대한 표시기와 이를 트리거하는 API를 안전하게 추가할 수도 있습니다. 이 표시기는 개발자에게만 표시되므로 사용자 경험을 방해하지 않습니다.

브라우저 공급업체가 이러한 작업을 구현하는 데 시간이 걸릴 때까지 기다리지 않습니까?

@jide 예, 하지만 이 문제를 빨리 해결하는 것보다 올바르게 해결하는 것이 더 중요합니다. 또한 표준화 노력(필요한 경우)을 고려하기 전에 단일 브라우저에서 구현할 수 있습니다.

@피곤한

각 프레임워크가 자체 경고를 제공해야 한다고 제안하고 있습니까?

각 프레임워크가 자체 개발 모드를 제공한다는 점을 감안할 때(해당 모드는 프레임워크마다 매우 다를 수 있음), 프레임워크가 유사하게 고유한 방식으로 경고를 구현해야 하는 것이 완전히 공정해 보입니다.

브라우저는 페이지에 devtools가 노출되는 것을 피하기 위해 어느 정도 노력했습니다. 여기에서 devtools를 진입 장벽으로 만든다면 DOM 경고가 놓칠 수 없는 많은 사용자를 놓치게 될 것입니다. DOM 경고는 더 간단할 뿐만 아니라 플랫폼 종속성이 적고 더 많은 개발자에게 도달합니다. 더 간단하고 효과적인 사운드가 승리합니다.

@gaearon Chrome DevTools 측에서는 웹 플랫폼 및 프레임워크 작성자가 중요한 경고를 알리는 데 사용할 수 있는 라이브 "위반 API"를 브레인스토밍했습니다. 이는 다가오는 감사 패널 새로 고침과 같은 위치에 표시됩니다. 귀하의 질문과 유사하게 들리며 DEV 모드 감지에 대한 경고를 트리거하는 데 사용할 수 있습니다.

이 특정 문제의 경우 원래 계획했던 것보다 조금 더 큰 소리를 내고 있을 수 있습니다. 콘솔 로그 메시지와 유사한 위반 패널은 패널이 통찰력을 제공할 것임을 알아야 합니다. 프레임워크가 메시징에 대해 표준화할 수 있는 페이지 아래에 매우 눈에 띄는 페이지 오버레이를 표시하는 무언가를 위한 추가 UX 공간이 있을 수 있습니다. @paulirish 와 @s3ththompson 에서 휴일 주말 이후의 생각을 반복합니다.

Fwiw, 내 생각에 이 API는 앞으로 몇 달 동안 준비되지 않을 것입니다. 그렇다면 처음에는 Canary에서만 사용할 수 있으며 6-7주 후에는 안정화될 수 있습니다.

DOM 경고는 더 간단할 뿐만 아니라 더 효과적입니다.

나는 이것에 대해 Jake와 동의합니다. DevTools 솔루션에 대해 계속 이야기합시다. 하지만 API가 귀하의 요구 사항에 맞지 않거나 타임라인이 현명하지 않은 경우에 대비하여 React가 대체 무엇을 할 수 있는지 알아내고 싶습니다.

각 프레임워크가 자체 개발 모드를 제공한다는 점을 감안할 때(해당 모드는 프레임워크마다 매우 다를 수 있음), 프레임워크가 유사하게 고유한 방식으로 경고를 구현해야 하는 것이 완전히 공정해 보입니다.

@jakearchibald 표준으로 설정하면 여러 프레임워크(또는 제품군에서 뒤따르는 라이브러리)를 사용하는 페이지가 최종 사용자에게 임의의 양의 비결정론적으로 렌더링된 암호 경고가 표시될 수 있다는 것을 알고 있습니까?

브라우저는 페이지에 devtools가 노출되는 것을 피하기 위해 어느 정도 노력했습니다.

그리고 그 이유는 적어도 부분적으로는 개발자별 메시징이 최종 사용자에게 노출되어서는 안 되기 때문이라고 확신합니다.

DOM 경고는 더 간단할 뿐만 아니라 더 효과적입니다.

솔루션의 단순성이나 효율성에 대해 이의를 제기하는 사람은 아무도 없습니다. 그것은 작동 하지만 사용자 경험을 희생시키면서. 사용자에게 부정적인 영향을 줄 수 있는 것은 속도만이 아닙니다.

Fwiw, 내 생각에 이 API는 앞으로 몇 달 동안 준비되지 않을 것입니다. 그렇다면 처음에는 Canary에서만 사용할 수 있으며 6-7주 후에는 안정화될 수 있습니다.

@addyosmani 더 나은 솔루션이라면 그것이 어떻게 문제가 될지 모르겠습니다. React에 대한 모든 변경 사항은 주요 릴리스에 포함될 것이며 릴리스 타이밍이 어쨌든 진행되는 한 미정이라고 생각합니다.

결정된 솔루션은 향후 모든 개발에 잠재적으로 영향을 미칠 것입니다. 그런 맥락에서 몇 주 대 몇 달은 IMO로 받아들일 수 있습니다.

프레임워크가 DOM에 자신이 넣지 않은 것을 삽입하면 일부 개발자는 침입을 받는다는 느낌을 이해합니다. 그러나 페이지 하단에 "이 사이트는 DevMode에 있습니다."라는 배너가 있으면 사용자 경험에 큰 영향을 미치지 않는 훌륭한 솔루션이 될 것 같습니다. 왜 많은 사람들이 반대로 생각하는지 이해하고 싶습니다.

@aweary : "보안 중심" 사이트가 DevMode에서 시작되면 문제를 해결할 때까지 신뢰할 수 없습니다. "DevMode"에는 비활성화된 CORS 검사 또는 노출된 템플릿 소스 코드 등과 같은 모든 종류의 보안 관련 바로 가기가 포함될 수 있습니다. 사이트가 보안에 중점을 둔 경우 이러한 일은 _반드시_ 발생하지 않아야 합니다.

("DevMode"가 React에서 매우 구체적인 의미를 갖는다는 것을 알고 있지만 여기서는 개발자가 아닌 사람의 관점을 가정하려고 합니다)

@피곤한

표준으로 설정하면 여러 프레임워크를 사용하는 페이지가 최종 사용자에게 임의의 양의 비결정적으로 렌더링된 비밀 경고가 표시될 수 있다는 것을 알고 계십니까?

나는 그것을 절대적으로 깨닫는다. 개발 모드에서 여러 프레임워크가 있는 페이지는 정당한 이유 없이 사용자 경험을 심각하게 손상시킵니다. 눈에 띄지 않고 수정되지 않은 상태로 진행되는 것을 선호하는 것 같습니다. 개발자가 아닌 개발자(개발자를 대상으로 하는 가시적인 메시지)에게 너무 좋지 않아 개발자가 즉시 수정하여 훨씬 더 나은 사용자 경험을 제공했으면 합니다.

사용자에게 부정적인 영향을 줄 수 있는 것은 속도만이 아닙니다.

달리 주장하는 사람이 보이지 않습니까? 이런 반응이 너무 안타깝다 😞

당신은 차라리 눈에 띄지 않고 고정되지 않는 것을 원하는 것 같습니다.

@jakearchibald 좀 이상한 결론이군요. 이 문제가 해결되는 것을 원하지 않으면 여가 시간을 여기에서 당신과 이야기하면서 보낼 것 같지 않습니까? 내가 당신의 해결책에 동의하지 않는다고 해서 내가 그것을 미해결 상태로 두는 것을 사임한다는 의미는 아닙니다. 정말 불공평합니다.

개발자가 아닌 개발자(개발자를 대상으로 하는 가시적인 메시지)에게 너무 좋지 않아 개발자가 즉시 수정하여 훨씬 더 나은 사용자 경험을 제공했으면 합니다.

근본적으로 용납할 수 없는 일이라고 생각합니다. 먼저 명시적으로 사용자를 처벌하는 것입니다.

"보안 중심" 사이트가 DevMode에서 시작되면 문제를 해결할 때까지 신뢰할 수 없습니다.

@surma dev 모드는 본질적으로 안전하지 않지만, 사용자에게 이를 전달하는 것이 괜찮다고 가정하는 선을 넘고 있습니다.

개발 도구를 열거나 활성화해야 하는 솔루션이 충분하지 않다고 생각합니다. 이를 알리려면 QA, 경영진 및 최종 사용자가 볼 수 있어야 합니다. 개발자들은 이것을 보는 데 너무 익숙해질 것입니다. 문제가 있는 SSL 구성이 강조 표시되는 방식과 유사합니다. 많은 것이 필요하지는 않지만 누군가가 그것에 대해 물어보고 고칠 것이라는 것을 알아차릴 만큼 충분합니다.

DOM에 주입하는 것은 여러 가지 이유로 문제가 됩니다. 우리는 DOM 라이브러리이고 DOM 진입점이 있기 때문에 React에 대해 좀 더 실현 가능합니다. DOM에 국한되지 않고 작업자에서 실행될 수 있는 라이브러리의 경우 더 어렵습니다.

우리가 할 수 있는 한 가지는 파비콘을 명시적으로 재정의할 수 있는 방법을 제공하는 한 파비콘을 변경하는 것입니다. 많은 사이트에는 이미 개발 모드에 대해 별도의 파비콘이 있습니다.

DOM을 제자리에 유지하지 못할 수 있는 React의 오류를 처리하기 위한 기본 경험을 파악해야 합니다. master의 현재 기본 구현은 오류가 발생하면 트리에서 React 콘텐츠를 삭제합니다. 그것도 침습적이다.

개발 모드가 아님을 감지할 수 있는 방법이 있는 경우 해당 오류 모드를 트리거할 수 있습니다. 그렇다면 영구적으로 개발 모드를 선택할 수 있는 확실한 방법이 필요합니다.

문제가 있는 SSL 구성이 강조 표시되는 방식과 유사합니다.

이것이 바로 내가 생각하기에 완벽할 것 같은 종류의 것입니다. 사용자는 방문하는 사이트에 대한 보안 정보를 제공하는 브라우저에 이미 익숙합니다. 성능 정보는 거기에서 크게 향상되지 않습니다. 또한 잠재적인 성능 문제를 보고하고 사용자 워크플로를 직접 방해하지 않는 모든 프레임워크/라이브러리에 대해 일관성이 있습니다. 👍

나는 파비콘 아이디어를 좋아한다: 눈에 띄고, devtools나 확장 없이 작동하고, 모든 사람이 눈에 띄고, 사용자에게 해를 끼치지 않으며, 주의를 끌도록 애니메이션될 수 있고, 개발자가 사라지고 싶을 정도로 짜증나게 할 수 있습니다.

DEV 모드를 옵트인하는 것은 어떻습니까?
나쁜 DX는 알아차리기 쉽기 때문에 "좋은 UX"에 오류가 있습니다(이와 같은 문제에 대한 IMHO는 사용자가 선택할 수 없지만 개발자는 선택할 수 있기 때문에 "승리"해야 함).
일부 프레임워크에서는 이미 이 작업을 수행하고 있다고 확신합니다(예: 올바르게 기억한다면 Relay).

구현 방법에 대한 제안:

• NODE_ENV 가 명시적으로 development 로 설정된 경우에만 개발 모드를 활성화합니다.
• 전역 __DEV__ 가 === true 인 경우 개발 모드를 활성화합니다.
• 사용자 영역에서 활성화할 디버그 도구 모듈 내보내기

첫 번째가 가장 좋은 이유는 다른 두 개는 가드 없이 하드 코딩되어(예: if(NODE_ENV === 'development') 문) 어쨌든 프로덕션으로 배송될 수 있기 때문입니다.

@mattecapu 에 관한 두 번째 의견을 참조하십시오. https://twitter.com/sebmarkbage/status/820047144677584896

개발자가 DEV 모드에서 실행하여 시작하도록 강제하는 유사한 방법이 있는 경우 기본값이 무엇인지는 중요하지 않습니다. 하지만 뒤처지면 정말 곤란하다.

여기에 대해 언급할 내용이 많고 생각이 있지만 개발자 경고를 비활성화하는 방법에 대한 질문에 대해 구체적으로 언급하고 싶습니다.

저는 특정 브라우저에서 일정 시간 동안 DOM 경고를 비활성화하는 버튼의 열렬한 팬이 아닙니다. @jlongster가 지적했듯이 자주 발생하면 개발자에게 고통입니다. 그러나 나에게 더 중요한 것은 브라우저 고유의 동작 변동성을 도입하여 버그를 재현할 수 없는 "내 컴퓨터에서는 잘 작동하지만 내 컴퓨터에서는 잘 작동합니다"로 쉽게 이어질 수 있다는 것입니다.

기본값 ["localhost", "127.0.0.1"] 으로 개발자 상자로 간주되는 도메인을 나열하는 매개변수를 렌더링에 전송하는 것을 선호합니다. 다음과 같이 보일 것입니다.

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

현재 도메인이 목록에 있으면 dev 경고가 표시되지 않습니다. 그렇지 않으면 그렇습니다. 이 체제에서:

• localhost 또는 127.0.0.1 를 사용하여 로컬 시스템에서 dev 빌드 사용 : 개발자 경고가 없으며 개발자 조치가 필요하지 않습니다.
• 다른 호스트 이름을 사용하는 개발 머신에서 dev 빌드 사용 : render 에 전달된 목록에 도메인 이름을 추가할 때까지 DOM 경고를 받습니다. 그 후에는 DOM 경고가 표시되지 않습니다.
• prod 머신에서 dev 빌드 사용 : React를 prod 버전으로 전환할 때까지 DOM 경고를 받습니다.

이 솔루션에 대해 내가 걱정하는 한 가지는 개발자가 코드에 있는 모든 개발 서버 도메인 목록을 남기고 해당 코드가 프로덕션에 적용될 수 있다는 것입니다. 개발 서버 도메인을 비밀로 여기는 회사의 경우 문제가 됩니다. 생각?

@aickin 해당 접근 방식의 문제는 사용자가 구성을 알고 있어야 하며, 결과적으로 해결하려는 문제가 있다는 것입니다. 문제는 사람들이 처음부터 개발/제품 구분을 인식하지 못한다는 것입니다.

편집 : 신경 쓰지 마세요. 개발 중인 DOM 경고가 여전히 있습니다.

서버 측 환경은 디버그 세부 정보가 포함된 "특수" 오류 페이지를 표시하고 프로덕션 환경에서 제공하지 말라고 알려줌으로써 이 문제를 해결합니다.

사용자 지정 오류 경계를 제공하지 않는 한 React를 "빠르게 실패"하고 뷰를 마운트 해제할 계획이므로 교육 페이지 역할을 하는 개발에 기본 "빨간색 상자" 오류 경계를 추가할 수도 있습니다.

그런 다음 사용자가 프로덕션에서 처음으로 버그가 있을 때 특별한 자세한 오류 메시지가 표시됩니다. 이것은 DEV 빌드에 대해 교육할 수 있는 기회가 될 수 있습니다.

그러나 페이지 하단에 "이 사이트는 DevMode에 있습니다."라는 배너가 있으면 사용자 경험에 큰 영향을 미치지 않는 훌륭한 솔루션이 될 것 같습니다. 왜 많은 사람들이 반대로 생각하는지 이해하고 싶습니다.

대부분의 사용자는 웹 앱이라는 것을 알면 웹 앱을 싫어합니다. 그 이유는 무엇입니까? 웹에 대한 이전의 일반적인 사고 방식은 웹이 화면에 나타나면 아무리 나쁜 행동을 하고 사용자가 웹이 나쁘다는 것을 배웠더라도 끝난다는 것이었습니다. 그러나 웹에서 훌륭한 UX를 만드는 것은 완벽하게 가능하지만 그렇게 하려면 DOM을 소유해야 합니다. 누군가가 임의의 위치에 임의의 배너를 삽입하면 잘못된 요소가 스크롤되기 시작하거나 스크롤할 때 전체 화면이 다시 그려지거나 예를 들어 드래그 제스처나 다른 것을 방해할 수 있습니다. 요점은 그 배너가 있는 한 그 배너가 없어져도 경험이 똑같다는 것을 알 수 없기 때문에 나는 발전할 수 없다는 것입니다.

프레임워크 솔루션으로서 파비콘 아이디어가 정말 마음에 듭니다. 개발을 방해하지 않고, 사용자에게 이상하게 보이지도 않고, UX를 파괴할 가능성도 없지만 주목받을 것입니다. 그러나 실제로는 당시 단일 라이브러리 또는 프레임워크에서만 작동하며 작업자에서 실행되는 라이브러리에서는 전혀 작동하지 않습니다. 실제 솔루션은 여러 프레임워크와 라이브러리를 지원할 수 있고 모든 컨텍스트에서 액세스할 수 있는 브라우저를 통해 이를 수행하는 좋은 방법입니다.

여러 프레임워크와 라이브러리를 지원하고 더 명확하지만 권한 요청이 필요한 또 다른 솔루션은 브라우저 알림을 표시하는 것입니다.

아이디어는 다음과 같습니다. react의 홈페이지에서 시작하기 문서를 업데이트하여 react 앱을 더 많이 생성하도록 합니다. 그리고 그 문서에서 npm build의 중요성을 강조하십시오. DOM 경고는 필요하지 않습니다. 인식이 필요합니다.

내 생각에 @ropilz 는 스레드의 초기에 "_.. 우리가 devs.._에게 알리고 싶은 모든 서비스를 바인딩할 수도 있습니다." 주석으로 이 문제에 대해 언급했지만, 눈치채지 못한(또는 승인되지 않은) 것일 수 있습니다.

내가 이해하는 한 여기에서 해결되는 근본적인 문제는

• 프로덕션 _최종 사용자_가 개발 모드에서 실행 중인 사이트를 경험할 때 어떻게든 _개발자_에게 경고하기 위해
• 프로덕션에서 console.log 메시지(또는 해당 문제에 대한 DOM 경고)를 보는 개발자에 의존할 수 없습니다. 단, 해당 개발자가 프로덕션 사이트 자체를 적극적으로 사용하지 않는 한(또는 최종 사용자, QA/ 이러한 경고를 개발자에게 다시 보고하기 위해 지원 팀 등)
• 개발자 청중을 위한 DOM 표시 경고를 최종 사용자에게 표시하는 (유효한) UX 인수 _against_가 있습니다.

CSP의 report-uri 와 유사한 것이 있다면 프레임워크가 최종 사용자가 볼 수 있는 사이트에서 현장 경고를 표시하는 대신 개발 모드 경고를 보낼 수 있습니까?

분명히 다음과 같이 여러 가지 고려해야 할 사항이 있습니다.

1. 이러한 보고는 기본적으로 켜져 있는 것이 이상적이지만 기본 report-uri 는 무엇입니까? (우리는 각 프레임워크가 https://report-uri.io와 유사한 자체 무료 서비스를 호스팅할 것으로 예상할까요? (이는 React & Angular와 같은 대규모 회사 후원 프레임워크에서는 _may_ 가능하지만 소규모 오픈 소스 프레임워크에서는 확실히 비실용적입니다. Preact, Vue 등)
2. 경고가 보고되면 사이트 소유자/개발자에게 어떻게 통지됩니까? (비개발자가 프로젝트에 참여하는 좋은 방법은 이러한 보고서를 모니터링하고 유지 관리자를 추적/통지하는 데 자원하여 도움을 주는 것입니다.)

나는 이 제안이 단지 생각에 불과하다는 것을 완전히 인정하며 이것이 얼마나 실용적인지 또는 실제로 어떻게 작동하는지 고려하지 않았습니다. 하지만 CSP/HPKP 보고에 대해 '프로덕션 문제에 대한 보고' 문제가 이미 부분적으로 해결된 것 같아서 여기에서 비슷한 것을 탐색할 수 있을 것 같아서 올려보고 싶었습니다.

한 걸음 물러서서 React가 프레임워크라는 것을 깨닫는 것이 중요합니다. 다음 행위 를 해서는 안 됩니다 .

• 개발자 를 위한 알림으로 시각적으로 표시되도록 DOM을 수정합니다. 개발자를 방해하지 않고 모든 환경에서 작동할 수 있는 무언가를 이해하고 개발하지 않는 한 이것이 바로 잘 작동하는 방법은 없습니다. 개발자를 방해하고 프로덕션 환경에서 팝업되는 경우 사용자의 신뢰를 잃지 않으면 꽤 자주 그리고 많은 사람들이 그것을 끄는 빠른 수정을 배포할 수 없을 것입니다).

• 파비콘을 수정합니다. favicon은 짜증나게 캐싱되어 북마크에 사용되며 모바일 장치에 저장된 웹 앱 아이콘(다른 항목이 지정되지 않은 경우) 등에 사용됩니다. 이로 인해 실수로(또는 의도적으로) 프로덕션 배포를 개발 모드로 배포하여 브랜드 로고를 지울 위험이 있습니다.

• 브라우저 알림. 당신이 시선을 받고 있을 때, 당신은 사용자에게 시선을 받고 있을 가능성이 높습니다. 알림 팝업은 브라우저 권한을 요청하고 사용자가 이해할 수 없는 이상한 팝업을 표시합니다. 내 경험에 따르면 이러한 것들이 대부분 개발자에게 표시될 것이라는 가정은 정확히 반대이며 사용자에 대한 신뢰를 망칠 수 있습니다.

개발자를 돌보는 것은 React의 일이 아닙니다. 나는 다음 중 하나를 제안합니다.

1. 개발 모드를 옵트인으로 설정합니다. 개발자가 디버그할 수 없다는 사실을 알게 되면 이를 켜는 방법( 어디에나 문서화해야 함)을 찾을 것입니다. 아니요, 다시 끄라고 말하는 것은 React의 일이 아닙니다. 그들의 문제.

2. 간단한 console.log 메시지에 그대로 두십시오(이는 비활성화 가능해야 함). 개발자가 찾아서 처리하도록 하십시오. 그렇지 않다면 오 글쎄. 모든 조직에 접근하여 일을 올바르게 수행하도록 할 수는 없습니다. 확장이 불가능할 뿐입니다.

경고를 표시하기 위해 DOM을 만지는 것에 동의하지 않습니다. React는 DOM 라이브러리이기 때문에 쉽고 간단해 보이지만 모든 라이브러리가 DOM에 자체 경고를 표시해야 한다고 상상해 보세요. 총체적 난국이 될 것입니다.

개발자가 자체 개발 모드를 사용하는 라이브러리가 너무 많습니다. process.env.NODE_ENV 를 production 로 설정하는 것은 이미 브라우저용 모듈 번들의 일반적인 표준이라고 생각합니다. 이것이 우리가 인식을 개선하기 위해 필요한 것입니다.

나는 React 문서가 개발 빌드와 프로덕션 빌드 사이에 차이가 있다는 것을 눈에 띄게 보여주지 않는다는 데 동의합니다. 문서를 열 때 고급 가이드 를 통해 개발 빌드와 프로덕션 빌드의 차이점을 읽어야 합니다. 제목은 Optimizing Performance 입니다. 초보자들은 React가 빠르다고 들었기 때문에 사용하기 때문에 절대 보지 않을 것입니다. 빠른 시작 섹션에서 "프로덕션에서 React 사용" 또는 이와 유사한 제목의 다른 문서를 갖도록 문서를 개선할 수 있다고 생각합니다.

초보자는 일반적으로 고급 가이드를 읽지 않지만 제목이 충분히 명확하고 중요해 보이는 경우 빠른 시작에서 일부 링크를 엽니다. 내가 React를 배우기 시작할 때 하는 일이기 때문에 그렇게 했다는 것을 압니다. 시작 안내서는 읽지 않았지만 빠른 시작 섹션의 일부 페이지는 읽었습니다.

우리가 취할 수 있는 또 다른 접근 방식은 React가 문서에 대한 해당 지점을 수정하기 위한 링크와 함께 개발 모드에서 사용될 때 콘솔에 경고를 표시하는 것입니다. 개발자를 위해 프로덕션 환경에서 콘솔을 여는 것은 드문 일이지만 개발할 때 로컬 환경에서는 확실히 콘솔이 열립니다. 이렇게 하면 로컬에서 개발할 때 프로덕션에 게시하기 전에 해야 할 일이 있음을 알게 됩니다.

콘솔 경고에도 불구하고 http://code.gov 가 시작되었습니다. 이것이 바로 우리가 예방해야 하는 종류의 것입니다. (해당 사이트는 Angular이지만 React에도 동일하게 적용됩니다)

누구든지 그들에게 연락하거나 PR을 보내려는 경우 code.gov에 대한 문제는 다음과 같습니다. https://github.com/presidential-innovation-fellows/code-gov-web/issues/221

Angular 2 is running in the development mode. Call enableProdMode() to enable the production mode.

저는 Angular 2를 사용한 적이 없습니다(이 경우 초보자가 됨). 경고를 본 후의 초기 반응은 enableProdMode() 를 호출하려고 한다는 것입니다. 작동하지 않습니다. Angular 케이스에 대한 콘솔 메시지가 개선될 수 있다고 생각합니다. 마법에 의존하는 대신 문서를 가리켜야 합니다.

Angular 문서를 열면 프로덕션 빌드에 대해 아무 것도 볼 수 없습니다. 나는 이것이 Angular와 React 모두의 문제라고 생각합니다. 둘 다 dev 모드를 사용하지만 문서에 있는 사람들에게 비활성화하는 방법을 알려주지 않습니다. 그렇기 때문에 문서 개선이 개발자 교육에 큰 도움이 될 수 있습니다.

개발자가 "실수"를 할 때 사용자 경고를 표시하는 것을 반대하지는 않지만 임의의 DOM 요소를 삽입하는 것은 방해가 됩니다. 나는 브라우저가 사이트가 안전하지 않다는 것을 보여주는 전용 UI를 가지고 있는 브라우저가 HTTPS 문제를 처리하는 방법을 좋아합니다. 성능 관련 상태에 대한 정보가 없습니다. 일반적으로 웹 성능에 대한 우려가 높아지는 것을 감안할 때 브라우저 공급업체가 사용자에게 방문하는 사이트가 형편없다고 말할 수 있는 방법을 제시하지 않는 이유를 모르겠습니다.

이것은 도구 수준에서 해결되어야 하므로 webpack과 Babel은 개발자에게 NODE_ENV 설정의 이점을 알릴 수 있습니다.

@pveyes 동의했습니다. Angular 팀에 대해서도 같은 지적을 했습니다.

@matthewp 이 https://github.com/presidential-innovation-fellows/code-gov-web/issues/129 에 대한 훨씬 오래된 문제가 있으며 Angular 팀이 직접 연락하여 수정 사항을 제공했습니다. 그것을 적용하려는 작은 욕망. 질문은 DOM 경고가 이 수정 사항을 더 긴급하게 만들었습니까? 아니면 처음부터 개발 모드에서 시작하지 못하게 했습니까?

질문은 DOM 경고가 이 수정 사항을 더 긴급하게 만들었습니까? 아니면 처음부터 개발 모드에서 시작하지 못하게 했습니까?

그들은 개발 단계에서 경고를 볼 가능성이 높으며 Google에서 비활성화하고 비활성화하는 방법을 알 수 있습니다. 그런 다음 잊어 버리기 때문에 미래에 그것을 깨닫지 않고 개발 모드로 배포했습니다. 개발 중에는 프로덕션처럼 보이기를 원하므로 임의의 DOM 청크가 삽입될 수 없습니다. 생산을 나타내는 것이 아니기 때문에 QA 또는 스테이징 시스템이 이것을 볼 수 없습니다.

따라서 사이트의 UX를 망치는 이것을 비활성화하는 많은 정크 코드로 끝납니다. 개발 중에 비활성화한 원래 엔지니어가 반드시 기억하는 것과는 다릅니다. 그들은 생산에 들어가기 전에 이동했을 수도 있습니다.

code.gov에서 배포 프로세스가 어떻게 작동하는지 잘 모르겠지만 실수로 개발 모드를 프로덕션에 배포하는 것보다 정부 계약자로서 경험한 것과 같은 경우 다음 중 하나를 수행합니다.

1. 전체 배포를 강제로 롤백(일부는 승인을 받고 UI 변경에서 서버 소프트웨어 업데이트에 이르기까지 모든 것을 번들로 묶는 데 6개월이 소요됨)하고 아마도 다음 날에 발생한 일에 대한 회의와 후속 문서 작업을 받게 됩니다. 새 배포 창 예약(UI의 단일 경고 때문에 DB 스크립트나 서비스 또는 기타 모든 것이 개발 모드에 있는지 계속해서 묻습니다.) 나는 이것이 아주 사소한 일에 일어나는 것을 보았습니다. 때로는 YMMV가 아닌 예외가 발생할 수 있습니다.

2. 사용자가 알아차리면 수정되지만 영향을 미치지 않을 가능성이 높기 때문에 다음 배포 창까지 기능이 업데이트되지 않습니다. 따라서 모든 사용자는 몇 주 또는 몇 달 동안 볼 수 있습니다.

적어도 내 경험은 그랬다. 요점은 배포 직후 DOM 침입 이 감지되더라도 해당 인프라/프로세스가 어떤 것인지 알 수 없으며 즉시 수정할 수 있는 것이 아닐 수도 있습니다(할 수 있어야 함에도 불구하고).

경고 메시지는 #7360(노란색 상자)이 병합될 때 더 눈에 띄게 됩니다. 노란색 상자에 메시지를 추가할 수도 있습니다("React Development Mode Warnings"라고 합니까?).

Angular 문서를 열면 프로덕션 빌드에 대해 아무 것도 볼 수 없습니다. 나는 이것이 Angular와 React 모두의 문제라고 생각합니다. 둘 다 dev 모드를 사용하지만 문서에 있는 사람들에게 비활성화하는 방법을 알려주지 않습니다. 그렇기 때문에 문서 개선이 개발자 교육에 큰 도움이 될 수 있습니다.

설치 페이지에 있습니다.

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

성능 최적화:

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

나는 문서가 그것에 대해 선행하지 않는다고 말하는 것은 공정하지 않다고 생각합니다.

문서를 열 때 고급 가이드를 통해 개발 빌드와 프로덕션 빌드의 차이점을 읽어야 합니다. 제목은 Optimizing Performance입니다. 초보자들은 React가 빠르다고 들었기 때문에 사용하기 때문에 절대 보지 않을 것입니다. 빠른 시작 섹션에서 "프로덕션에서 React 사용" 또는 이와 유사한 제목의 다른 문서를 갖도록 문서를 개선할 수 있다고 생각합니다.

바로 첫 번째 페이지(설치)에 있습니다.

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

네가 옳아. 미안 내 실수. 나는 프로덕션 빌드가 다른 섹션에 있다고 가정하여 거기를 보지 않고 대신 사이드바에서 관련 제목을 검색했습니다(최적화 성능 페이지를 찾았습니다). 내가 더 잘 알았어야 했다.

저는 React의 초보자가 아닙니다. 그래서 내 가정을 확인하기 위해 문서를 열 때 - React 문서는 prod vs dev에 대해 사전에 있지 않습니다 - 설치 문서를 열지 않았습니다 🙇

걱정 마. 눈에 잘 띄지 않으면 더 나은 배치를 위한 제안을 받을 수 있습니다. 예를 들어 전용 페이지를 만들 수 있습니다( Deploying to Production ).

이 문제는 해결해야 할 중요한 문제이지만 강조해야 할 가장 중요한 문제가 아님을 잊지 마십시오. 나는 또한 사람들이 그것을 보고 탐색하고 잊어버리고 "내가 하는 일을 알고 있다"고 생각할 것이기 때문에 맨 앞 페이지에 강조 표시되더라도 충분할 것이라고 확신하지 못합니다. 그래서 나는 문서에 대해 지나치게 피벗하지 않을 것입니다.

이를 해결하는 유일한 실제 방법은 감지하고 알리는 것입니다.

@KrisSiegel 파비콘이 캐시되는 것은 좋은 점입니다. 1~2초 후에 전환한 다음 몇 초마다 짧게 다시 뒤집어야 하는지 궁금합니다. 그렇게하면 캐싱 및 북마크 문제가 재정의 된 아이콘 시간에 시간을 맞출 가능성이 거의 없습니다.

나는 favicon에 대한 JS 조작이 캐시되지 않는다고 생각했지만 아마도 내가 틀릴 수 있습니다.

나는 이것을 위한 후크를 갖는 적절한 장소가 Chrome이나 Firefox가 아니라 webpack, Browserify 또는 Rollup이라고 주장하고 싶습니다.

React용 프로덕션 번들로 의도되었지만 프로덕션 모드를 활성화하지 않고 빌드하는 것은 빌드 오류일 뿐입니다. 런타임에 이것을 표시하는 방법에 대한 합의가 없는 이유는 이것이 런타임에 처리되어야 하는 문제가 아니라는 점을 반영한다고 생각합니다.

@taion 동의합니다. 나는 이것이 확실히 DOM이 아닌 빌드 도구에 속한다고 생각합니다.

노드 env가 프로덕션 코드에 대해 프로덕션으로 설정되어야 한다고 가정하는 빌드 도구 장소여야 한다고 생각합니다. 모든 프로젝트에 필요한 것은 아니지만 좋은 가정이라고 생각합니다.

npm run build 가 터미널에서 실행되고 환경이 프로덕션으로 설정되지 않은 경우 기본 출력과 함께 터미널에 빨간색 경고가 표시되어야 합니다. env is not set to production, some scripts may be in development mode

현재 webpack에서 그러한 경고를 받지 않습니다.

편집: 추가 설명

아니면 정말 NODE_ENV를 설정하십시오.

콘솔 경고가 작동하지 않으면 빌드 경고가 작동할지 확신할 수 없습니다.

빌드는 사용자를 위해 구성해야 하며, 그렇지 않으면 프로덕션용으로 잘못 구성되면 실패합니다. 적어도 React의 경우 이 _is_ 빌드 시간 플래그입니다.

@jakearchibald 일부 사람들은 여전히 ​​무시할 것이라고 확신하지만, 프로덕션 환경에서는 절대 열리지 않을 수 있는 브라우저 콘솔에 경고가 숨겨져 있기 때문에 표시되지 않는 대신 최소한 빌드할 때 경고가 표시될 것입니다. . 가장 중요한 것은 경험이 적은 사람들에게 코드 생산을 준비하기 위해 무엇을 해야 하는지에 대한 단서를 제공한다는 것입니다.

많은 개발자가 라이브러리를 업데이트하지만 웹팩 및 더 일반적으로 도구를 업데이트하지 않는 것이 일반적입니다. 많은 사람들이 웹팩이 제대로 작동한다고 가정하고 웹팩 및 공동 업데이트를 업데이트하는 것이 어려울 수 있기 때문입니다.

React용 프로덕션 번들로 의도되었지만 프로덕션 모드를 활성화하지 않고 빌드하는 것은 빌드 오류일 뿐입니다.

CDN에서 미리 패키징된 버전의 React를 사용하는 것도 지원되는 구성 이지만 해당 워크플로에는 빌드 단계가 전혀 없습니다. 따라서 빌드에만 초점을 맞춘 이 문제에 대한 솔루션은 CDN 사용 사례를 무시합니다.

나는 솔직히 그것에 대해 어떻게 느끼는지 잘 모르겠습니다. 나는 React CDN 사용에 대한 개발자 경고를 갖는 것에 대한 찬성과 반대 모두를 볼 수 있습니다.

@taion 빌드 전용 솔루션을 지원하는 사람으로서 이것이 다루어야 할 중요한 사용 사례라고 생각하십니까?

다른 분들은 어떻게 생각하시나요?

거기에 있는 문서는 프로덕션에 .min.js 번들을 사용해야 한다는 것이 꽤 분명하다고 생각합니다. 아마도 굵고 더 큰 글꼴 크기와 같은 것을 사용할 수 있습니다. 그러나 누군가가 웹 사이트를 위해 프로덕션에서 축소되지 않은 React 번들을 사용하고 있다면 어쨌든 다른 문제가 있습니다.

거기에 있는 문서에는 프로덕션에 .min.js 번들을 사용해야 한다는 것이 꽤 분명하다고 생각합니다.

동의하지만 React를 npm 패키지로 포함하는 경우 프로덕션용 빌드 도구를 구성하는 방법에 대한 페이지도 매우 명확합니다. 이 문제의 요점은 문서의 해당 페이지를 주의 깊게 읽지 않는 사람들을 위해 성공의 구덩이를 만들려는 것이었습니다.

그러나 동의하지 않을 수 있으며 CDN의 dev 빌드를 사용하는 것이 더 적극적인 dev 경고로 예방하는 데 중요한 경우가 아니라고 생각하는 것처럼 들립니다. 그것이 당신의 입장에 대한 공정한 요약입니까, 아니면 제가 약간의 뉘앙스를 놓치고 있습니까?

CDN+dev 구성은 사용자가 React의 축소되지 않은 빌드를 사용해야 한다는 점에서 더 명백하게 잘못된 구성이라고 생각합니다. 축소된 빌드를 사용하는 데 필요한 지식의 부담이 더 적기 때문에 이러한 방식으로 실패하는 것이 더 어렵습니다.

webpack 또는 Browserify에서 축소를 실행했기 때문에 프로덕션 준비가 된 것 _생각_ 하는 구성이지만 실제로는 NODE_ENV 를 설정하지 않았기 때문에 그렇지 않습니다. CDN 번들을 통해 이를 얻을 수 없습니다.

Chrome Developer Tools 의 React 탭은 우리가 DEV Mode 에 있는지 알려주기에 충분하다고 생각합니다.

개발 모드에서 페이지에 DOM 요소를 주입하는 프레임워크에 대한 몇 가지 선례가 있다는 점은 주목할 가치가 있다고 생각합니다.

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

내가 말할 수있는 한 이것이 기본적으로 켜져 있다고 생각하지 않습니다.

위의 논의에 따르면 모든 제약 조건을 충족하지만 모든 사람이 개발 모드에서 실행하지 않아야 할 때 안정적으로 중지하는 완벽한 솔루션을 달성하려는 일반적인 목표가 있는 것 같습니다. OP는 개발자와 사용자를 위한 잠재적 경험 사이에 절충점이 필요하다고 말했고 이것이 매우 사실이라고 생각합니다.

문제를 다시 언급하려면:

• 0이 아닌 수의 React 사이트가 개발 모드를 비활성화하지 않고 프로덕션으로 만듭니다.
• 우리는 이 숫자를 줄이고 싶습니다
• 우리는 React 개발자들을 귀찮게 하고 싶지 않습니다
• 우리는 React를 처음 접하는 사람들을 미루고 싶지 않습니다.
• React로 구축된 사이트의 최종 사용자가 cyptic 개발자 경고를 보는 것을 원하지 않습니다.
• 우리는 외부 DOM 요소의 존재로 인해 사이트를 중단하고 싶지 않습니다.

이러한 점을 감안할 때 적절한 첫 번째 단계는 개발 모드의 React가 console.warn 또는 console.info 를 통해 개발 모드에 있음을 알리고 이것이 프로덕션에서 비활성화되어 있는지 확인하는 지침이 될 것이라고 생각합니다. 전개.

물론, 이것이 모든 사람을 사로잡을 수는 없지만 _괜찮은 시작입니다_. 이렇게 하면 실수로 프로덕션 환경으로 배송되는 사람의 수를 줄이고 향후 개선을 위해 문을 닫지 않습니다.

이러한 점을 감안할 때 적절한 첫 번째 단계는 개발 모드의 React가 console.warn 또는 console.info를 통해 프로덕션 배포에 대해 비활성화되었는지 확인하는 지침과 함께 개발 모드에 있음을 알리는 것이라고 생각합니다.

개발 중일 때 개발 모드에 있는 것이 잘못된 것은 아닙니다. 다른 어떤 휴리스틱을 사용할 수 있습니까?

또한 프로덕션 환경에서 아무도 콘솔을 읽지 않는다는 점을 감안할 때 충돌 보고 솔루션을 사용하는 경우 기록되도록 시간 제한을 던질 수 있는지 궁금합니다.

개발 중일 때 개발 모드에 있는 것이 잘못된 것은 아닙니다. 다른 어떤 휴리스틱을 사용할 수 있습니까?

현재 React DevTools 공지와 유사해야 한다고 생각합니다.

현재 개발 모드에 있으며 프로덕션 사이트에서는 개발 모드를 비활성화해야 함을 알려주는 정보 메시지입니다. 이것은 (이론적으로) 더 많은 개발자가 구별이 있으며 프로덕션 사용을 준비하기 위해 몇 가지 조치를 취해야 한다는 것을 인식하게 해야 합니다.

당신이 말했듯이 거의 아무도 실제 프로덕션에서 콘솔 경고를 보지 않을 것입니다. 그리고 그 시점까지는 약간 늦습니다.

정지된 레코드처럼 들리게 해서 미안하지만 콘솔 경고가 작동하지 않는 것 같습니다. 예: https://code.gov.

정지된 레코드처럼 들리게 해서 미안하지만 콘솔 경고가 작동하지 않는 것 같습니다. 예: https://code.gov.

단일 반대 사례는 그것이 오류가 없다는 것을 보여주지만 어떤 접근 방식도 그렇게 될 것이라고는 생각하지 않습니다.

콘솔 경고가 인지도를 높이고 실수로 개발 모드를 실행하지 않아야 할 때 실행하는 사람들의 수를 줄일 수 있다면 올바른 방향으로 나아가는 단계인 것 같습니다. 완벽한 것은 선의 적이다.

@jakearchibald

예, 하지만 code.gov의 빌드 도구가 여기에서 후크와 함께 설정되어 있다면 최소한 이를 위해 빌드 타임 후크를 사용하는 React의 컨텍스트에서 관찰하는 문제를 방지했을 것입니다. 그들은 결국 웹팩을 사용하고 있습니다.

웹팩이 빌드 경고를 내보내야 한다고 말하는 것이 아닙니다. 올바른 수정은 webpack이 process.NODE_ENV 를 설정하거나 적절한 프로덕션 구성 없이 프로덕션 빌드를 만들려고 하면 해당 웹팩이 기본적으로 빌드에 실패한다는 것입니다.

DevTools "위반"에 대한 @addyosmani 의 이전 요점에 신속하게 대응하고 싶었습니다. 우리는 Chrome DevTools에서 특정 오류에 대한 더 강력한 표시를 보여주는 프로토타입 을 만들고 있지만 이 작업은 아직 초기 단계이며 저는 @jakearchibald 가 경고를 표시하는 데 동의하는 경향이 있습니다( console.warn 보다 더 무섭더라도). 충분히 좋은 솔루션입니다.

NODE_ENV == 'development' 또는 호스트 이름이 localhost / 127.0.0.1 인 경우에만 React를 프로덕션 모드로 기본 설정하고 개발 모드를 켜는 것은 어떻습니까? 대부분의 개발자는 기본적으로 올바른 동작을 얻을 수 있으며 정말로 필요한 경우 개발 모드를 수동으로 강제 실행하는 방법이 항상 있습니다.

항상 상당히 복잡한 조건부(노드에서 실패하지 않아야 하기 때문에)로 해당 분기를 계속 공격하는 것은 이상적이지 않은 것 같습니다.

BTW, 웹팩 2의 -p ("생산" 모드, 기본 설정으로 축소도 가능)은 사용자를 위해 NODE_ENV 를 설정합니다. https://webpack.js.org/guides/production-build /#노드 - 환경 변수.

이것은 나에게 매우 합리적으로 보이며 webpack을 사용하는 거의 모든 사람들에게 이 문제를 방지해야 합니다. 런타임에 이것을 처리해야 한다고 주장하는 이유는 무엇입니까?

webpack 2의 BTW, -p(기본 설정으로 축소도 가능하게 하는 "프로덕션" 모드)는 사용자를 위해 NODE_ENV를 설정합니다: https://webpack.js.org/guides/production-build/#node -environment-variable.

네. 우리는 이것을 알고 있습니다. Webpack core의 @TheLarkInn 이 확실히 확인할 수 있지만 -p 는 Webpack 커뮤니티 atm에서 널리 사용되지 않는 것으로 알고 있습니다. 여기서 근본적인 문제는 현재 console.log 경고가 있는 현재 상태와 유사한 솔루션이 옵트인된 경우 React 사용자에게 실제 변화가 없을 가능성이 있다는 것입니다. 우리는 사람들에게 '빠른' 배송에 대해 더 나은 변화를 주고 싶습니다.

Webpack에서 DEV 및 PROD 환경을 쉽게 감지할 수 없다는 점(-p가 충분하지 않음)도 https://github.com/webpack/webpack/issues/3216에서 약간의 고통을 주었다는 점을 언급할 가치가 있습니다.

올바른 수정은 webpack이 process.NODE_ENV를 설정하거나 적절한 프로덕션 구성 없이 프로덕션 빌드를 만들려고 하면 해당 웹팩이 기본적으로 빌드에 실패한다는 것입니다.

나는 우리가 이것을 추구하는 것을 지지하지만 내가 말할 수 있는 것에서 Webpack에 대한 획기적인 변화가 될 것입니다. 저는 개인적으로 몇 가지 지능형 경험(localhost, DevTools 열기 등)을 사용하여 표시되는 명확한 오버레이 메시지 _only_와 관련된 런타임 솔루션이 우리를 적절하게 다룰 것이라고 생각합니다.

즉, Webpack process.NODE_ENV 항목으로 계속 돌아 가면서 @sokra 또는 @TheLarkInn 이 이에 대한 의견이 있는지 궁금합니다.

내 이해는 당신과 다릅니다 -p 는 웹팩의 전문가가 아닌 대부분의 사용자가 프로덕션 빌드를 설정하는 사실상의 방법이라고 생각합니다.

유명한 패키지도 -p 를 사용하여 프로덕션 빌드를 생성합니다.
https://github.com/ReactTraining/react-router/blob/5e69b23a369b7dbcb9afc6cdca9bf2dcf07ad432/package.json#L23
https://github.com/react-bootstrap/react-bootstrap/blob/61be58cfdda5e428d8fb11d55bf743661bb3f0b1/tools/dist/build.js#L10

webpack에서 Uglify 플러그인을 직접 구성하는 것은 매우 드문 일이므로 -p 가 없으면 사람들은 축소되지 않은 빌드를 사용하게 되며 이 경우 더 큰 문제가 발생합니다.

저는 개인적으로 몇 가지 지능형 경험(localhost, DevTools 열기 등)을 사용하여 표시되는 명확한 오버레이 메시지를 포함하는 런타임 솔루션이 우리를 적절하게 다룰 것이라고 생각합니다.

나는 이것이 일어날 _only_ 시나리오를 실제로 평가하지 않고 이것이 여러 번 격추된 것처럼 느낍니다("프레임워크가 DOM에 무언가를 주입하는 것은 허용되지 않습니다").

개발하는 동안 지속적으로 DOM에서 영구적인 메시지와 예상치 못한 일에 대처해야 하는 것은 용납될 수 없다는 점에 전적으로 동의합니다. 하지만 여기서 제안하는 것은 DevMode가 프로덕션에 배포되는 경우에만 표시되는 메시지입니다(경험적 방법을 입력하세요!). 이를 방지하기 위해 임의의 수의 검사 및 콘솔 메시지를 도구, CI 및 브라우저 확장에 구축할 수 있습니다.

그러나 필사적인 최후의 비상 안전 장치로서 화면에 보이는 배너가 적절하고 적절한 솔루션이라고 생각합니다.

DevMode가 프로덕션에 배포된 경우에만 표시됩니다(휴리스틱 입력!)

따라서 개발자는 이 메시지를 절대 볼 수 없으며 (아마도 실수로) 개발 모드를 프로덕션에 배포하고 갑자기 모든 사용자가 볼 수 있도록 이 새 HTML이 애플리케이션에 표시되는 것을 보게 되는 것입니까?

그것은 나에게 더 많은 형벌처럼 들린다. 아직 개발 모드를 이해하지 못하고 메시지와 함께 이 이론적인 새 버전의 React를 사용하여 배포하면 놀라움을 느끼게 될 것이며 당시 웹 애플리케이션의 사용자도 이를 보게 될 것입니다. 나는 이것이 개발자나 회사를 난처하게 만드는 데 도움이 되는 방법을 알지 못합니다. 물론 그렇게 하면 문제가 해결될 수 있지만 내 생각에는 그 비용이 너무 높고 공감이 조금 부족합니다.

그러나 필사적인 최후의 비상 안전 장치로서 화면에 보이는 배너가 적절하고 적절한 솔루션이라고 생각합니다.

이 솔루션의 문제는 너무 이상적이며 프레임워크를 개발할 때 다른 회사에는 최고의 배포 정책이나 최고의 QA(있는 경우)가 없을 수도 있다는 현실에 집중 해야 한다는 것입니다.

예, 누군가 프로덕션에서 개발 모드로 배포하는 경우 이를 보고 빠르게 변경할 수 있어야 합니다. 불행히도, 특히 기술 산업 외부에서는 이것이 불가능 하거나 쉽지 않습니다 . 여기에 댓글을 다는 사람들의 대다수는? 그들의 회사에는 이 시나리오에 잘 대처할 수 있는 배포 프로세스가 있을 수 있습니다. 구글, 페이스북, 플레이스테이션 등 이 모든 기술 회사가 이 정도는 잘 처리할 수 있지만 이것은 React를 사용하는 대다수의 사용자를 대표하는 것은 아닙니다. 그렇죠? (사실, React 사용에 대한 통계가 있습니까? 편리할 것입니다!)

예, 그렇습니다. 이러한 회사와 정부는 배포 프로세스와 정책 등을 변경해야 합니다. 그러나 현실은 이것입니다. 대부분의 회사는 배포 프로세스가 허술하고 QA가 존재하지 않습니다.

제가 개인적으로 경험한 두 가지 시나리오를 살펴보겠습니다.

첫째 , 정부에서 근무하는 동안 지사 및 부서에 따라 3-6개월마다 단일 배포가 있을 수 있습니다. 이러한 배포는 가능한 한 많은 것을 롤업하고 전체 배포의 일부가 실패하면 모든 것이 롤백될 수 있습니다. 그래서 우리는 OWF라고 하는 이 소프트웨어를 사용하고 있었습니다. 이 소프트웨어는 익숙하지 않으시겠지만 iframe을 사용하여 단일 웹 응용 프로그램에 여러 웹 응용 프로그램을 표시한다는 점에서 iSocial과 비슷합니다. 몇 가지 애플리케이션 배포에 수동 구성 단계가 있어 의도한 애플리케이션 대신 일부 iframe에 404 및 500 오류가 표시되지 않았습니다.

개발자는 일반적으로 배포되는 시스템에 액세스할 수 없기 때문에 문제를 알아내기까지 많은 시간이 걸렸습니다. 그 시점에서 우리는 상사가 다른 사람의 상사에게 전화를 걸어 전체 배포를 롤백하지 않도록 다른 사람에게 영향을 미치지 않는다고 말하도록 해야 했습니다. 그런 다음 며칠 후에 다른 사람이 일부 구성을 다시 실행하도록 하기 전에 작성해야 할 수많은 서류 작업과 문서가 있었습니다. 그 동안 애플리케이션은 그 전체 기간 동안 작동할 수 없었습니다.

두 번째 로, 제가 재무 부서에서 일할 때 웹 사이트의 실제 항목 레이아웃 대신 개발자 이름을 실수로 포함하는 배포가 있었습니다(그가 뭔가를 테스트하고 있었던 것 같아요?). 어쨌든, 그것은 바로 알아차렸지만 그것을 고치기 위해 우리는 그날 훨씬 늦게까지 걸리는 긴급 변경 통제를 받아야 했습니다. 그래서 그들의 고객들은 이 어리석은 배너를 고치기까지 거의 8시간 동안이나 봐야 했습니다.

제 요점은: 개발자가 넣지 않은 임의의 요소를 DOM에 삽입할 때 세심한 주의가 필요합니다. 특히 일부 시나리오 에서만 표시하는 것에 대해 이야기하는 경우 누군가가 처음으로 그것을 볼 때 신속하게 비활성화하여 다시 귀찮게 할 필요가 없도록 하는 방법을 알아낼 것입니다.

@KrisSiegel

아직 개발 모드를 이해하지 못하고 메시지와 함께 이 이론적인 새 버전의 React를 사용하여 배포하면 놀라움을 느끼게 될 것이며 당시 웹 애플리케이션의 사용자도 이를 보게 될 것입니다.

DevTools가 열려 있는 동안에만 메시지가 표시된다면(즉, 개발자가 아닌 프로덕션 사용자가 볼 가능성이 낮은) 접근 방식에 대한 귀하의 생각이 다른지 궁금합니다. React는 현재 사용하고 있는 현재 console.log 전략의 효과적인 확장입니다.

DevTools가 열려 있는 동안에만 메시지가 표시된다면(즉, 개발자가 아닌 프로덕션 사용자가 볼 가능성이 낮은) 접근 방식에 대한 귀하의 생각이 다른지 궁금합니다. React는 현재 사용하고 있는 현재 console.log 전략의 효과적인 확장입니다.

개발 도구가 열려 있으면 아마도 console.log 메시지가 표시될 것이므로 DOM 변경은 관리하기에 불필요한 복잡성과 중복되는 것처럼 보입니다. React 콘솔 메시지를 항상 더 크게/더 멋지게 만들 수 있습니다. 아마도 ASCII React 로고일 것입니다. 누군가가 거기에 들어갈 경우주의를 끌 무언가.

궁극적으로 누군가가 이 문제에 직면할 것이라고 생각하지만 Stackoverflow에서 경고를 비활성화하는 방법을 물어보면 누군가가 경고를 비활성화하는 방법을 보여주는 코드를 게시하고 사람들은 경고가 발생하면 단순히 비활성화할 것입니다. 빌드 도구는 수없이 많고 과거에 내가 이야기한 많은 사람들은 그것들이 혼란스럽거나 어렵다고 생각했습니다(Babel 6의 릴리스는 "재미있는" 시간이었습니다). 당신은 단순히 그것들을 올바르게 사용하지 않는 많은 사람들과 마주치게 될 것입니다.

적어도 내 경험은 ¯\_(ツ)_/¯

휴, 드디어 실의 바닥까지 붙었다. 괜찮아. 나는 이것을 조금 브레인스토밍했다.

Webpack은 React가 DEV를 PROD로 배송하는 사람들을 더 쉽게 피하기 위해 사용할 수 있는 NODE_ENV를 강제로 지정할 수 있지만 이는 Webpack의 주요 변경 사항이 될 것입니다. 나는 지금 Webpack 3에서 이와 같은 것이 얼마나 실현 가능한지에 대해 Sean과 이야기하고 있습니다. React + Webpack 스택을 초보자와 성능 친화적으로 유지하는 것은 두 진영 모두 관심을 갖고 있다는 것을 알고 있습니다.

이것은 지금까지 내가 가장 좋아하는 것처럼 느껴졌지만 아직 100% 판매되지는 않았습니다.

1. 따라서 누구나 webpack을 실행할 때마다 ENV가 전달되도록 할 수 있습니다. 웹팩을 실행하려면 env 변수를 제공해야 한다는 유용한 오류 메시지가 표시됩니다.

그러나 이것은 사용자에게 상당한 이탈 지점을 제공합니다. 모든 사람이 prod 또는 dev env를 위해 글을 쓰지 않거나 env가 무엇인지 알지도 못합니다. 나는 이에 대한 피드백을 얻기 위해 webpack/webpack에 대한 문제를 제기할 것입니다. 내 직감은 모든 사람이 이것을 원하지 않을 것이고 내가 동의하든 그렇지 않든 우리는 푸시백을 고려해야 하기 때문입니다.

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

2. webpacky 솔루션은 컴파일러 수명 주기에 연결할 수 있는 독립 실행형 플러그인을 만들고 코드가 제거되고 있는지 또는 ENV가 제공되지 않는지 확인하고 친숙한 경고 또는 선택한 오류를 내보내는 것입니다.

그러나 나는 그 응답이 "하지만 사용자는 그 일을 하는 방법 등을 결코 알지 못할 것"이라고 상상할 수 있습니다. 따라서 CRA, 따라서 지금 이 문제.

아래와 같이 React(또는 필요한 모든 fw)의 package.json을 확인하는 새로운 리졸버 패턴을 생성할 수 있습니다.

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

사용자가 알거나 신경 쓸 필요 없이 자동으로 사용자 컴파일러 구성에 적용됩니다.

다시 한번 정말 브레인스토밍을 합니다.

@TheLarkInn webpack 2에서 -p 의 현재 동작으로 충분하다고 생각합니다. 유일한 실패 사례는 누군가가 스스로 UglifyJsPlugin DefinePlugin 것을 잊어버린 경우이지만, 그럴 가능성은 훨씬 낮아 보입니다.

@taion 예/아니오

-p 는 프로덕션 "처리"만 코드에 적용하지만 NODE_ENV 에 대해 어떠한 가정도 하지 않으며 이에 대한 지식도 없습니다. 이것이 사람들이 DefinePlugin() 를 사용해야 하는 이유입니다.

그러나 사용자가 프로덕션 ENV에서 코드를 실행하고 있다는 _추측_ 또는 _묵시_에 가장 가까운 "_합리적인_" 영역이라고 생각합니다. 그것은 우리가 커뮤니티와 팀이 괜찮은지 확인하고 싶은 한 가지 영역이 될 것입니다.

@TheLarkInn 나는 이것이 v2에서 변경되었다고 믿습니다: https://webpack.js.org/guides/production-build/#node -environment-variable

아 맞다 제가 잘못알고있습니다 죄송합니다. 그러나 사람들이 최적화하는 항목에 대해 보다 세분화된 제어를 원하기 때문에 자주 사용되지 않습니다. ( @addyosmani가 언급한 것처럼)

정말 흔한 일인가요? webpack을 시작할 때 -p 는 분명히 가야 할 길처럼 보였습니다. 위에서 언급한 것처럼 추가 조정을 적용할 충분한 이유가 있는 라이브러리라도 -p 를 사용합니다.

아래와 같이 React(또는 필요한 모든 fw)의 package.json을 확인하는 새로운 리졸버 패턴을 생성할 수 있습니다.

"웹팩": {
"플러그인": "ReactEnvironmentPlugin"
}
사용자가 알거나 신경 쓸 필요 없이 자동으로 사용자 컴파일러 구성에 적용됩니다.

@TheLarkInn 내가 이것을 올바르게 읽고 있다면 리졸버 패턴을 트리거하려면 앱의 package.json이 수동으로 ReactEnvironmentPlugin 를 지정해야 합니다. 맞습니까? 아니면 내가 제안을 잘못 이해하고 있습니까? :)

Webpack에서 프로젝트가 React를 사용하고 적절한 환경 전환을 수행하고 있음을 감지하는 해결 마법을 상상할 수 있지만, 이는 프레임워크별 최적화를 번들러에 긴밀하게 결합하는 것처럼 들리고 바람직하지 않을 수 있습니다.

반응을 감지하는 것보다 js 모듈 설명 필드를 감지하는 것보다 플러그인이 있는 webpack 필드가 포함됩니다. 그러나 당신 말이 맞습니다. 그것은 매우 밀접하게 결합되어 있으며 실제로 제가 가장 좋아하는 아이디어도 아닙니다.

webpack에 React를 구성하는 방법을 알아내기 위한 "프로덕션" 모드의 개념이 없는 한 이것이 실제로 여러분에게 어떤 보장도 제공하지 않는다고 생각합니다. 그리고 위에서 논의한 바와 같이 -p 가 이미 옳은 일을 하고 있다는 점을 감안할 때 이것은 중복된 것처럼 보입니다. 어쨌든 웹팩으로 축소된 프로덕션 빌드를 만들 때 사용자가 일반적으로 도달하게 될 것입니다.

우리는 이것에 대해 조금 더 이야기했고 합리적인 해결책이 있다고 생각합니다.

우리는 개발 단계에서 React 경고에 대해 "경고 상자"를 활성화하는 것을 오랫동안 고려했습니다. 여기 에서 데모를 볼 수 있습니다(PR: https://github.com/facebook/react/pull/7360). 경고가 있을 때만 표시되지만 개발 중에는 매우 일반적이며(항상 수정해야 함) 앱을 개발하는 데 5분 이상을 소비한 사람이라면 누구나 대화 상자를 보고 존재한다는 것을 알게 될 것입니다.

이 변경 후에는 개발 모드를 인식하기가 더 어려워질 것입니다. "경고 대화 상자를 제거하는 방법"을 검색하고 프로덕션용 빌드에 대해 배울 것입니다. 그렇지 않으면 어느 시점에 배포된 일부 경고를 받을 수 있으며 사용자에게 경고가 표시됩니다. 나는 이 경우 사람들이 React 자체를 비난하지 않을 것이라고 생각합니다. 왜냐하면 우리는 단지 상자를 불쾌하게 보여주지 않기 때문입니다. 우리는 개발 모드가 해야 할 일을 하기만 하면 됩니다.

(참고로 우리는 페이스북에서 오랫동안 비슷한 경고 상자를 개발 중이었기 때문에 React를 사용하려는 의도와 일치합니다.)

그 제안을 보니 정말 기쁩니다 @gaearon! 내가 꿈꾸던 모든 것입니다 ;)

참고로: 개발자가 링크를 제거하는 방법에 대해 Google에 문의하지 않아도 되도록 상자에 직접 링크를 포함하는 것을 고려해 볼 가치가 있습니다.

네, 좋은 지적입니다. 우리는 무언가를 추가할 것입니다.

@gaearon 나는 그 솔루션이 매우 불쾌하다고 생각합니다. 개발 중에도 경고가 DOM을 침범하는 것을 원하지 않습니다 . 이는 일반 개발자에게 전혀 목적이 없으며 대부분의 경우 완전히 비활성화될 수 있습니다. 개발자 도구는 이유 때문에 경고를 표시하므로 발명할 필요가 없습니다.

나는 또한 DOM 솔루션이 그것에 대한 나의 이전 주장에 대한 반론이 전혀 없는 상태로 계속 나온다는 것이 문제라는 것을 알게 되었습니다. 내 요점이 무시된다면 괜찮습니다. 이것은 내 저장소가 아니므로 충분히 공평하지만 같은 주장이 나오는 것을 보는 것은 낙담합니다. , 그런 다음 바로 다시 나타납니다. 헹구고 반복합니다.

대부분의 경고에 대해 이것이 사실이라는 데 동의하지만 React 경고는 특히 코드의 버그를 지적합니다. 그것들은 단순한 제안이 아닙니다.

대화 상자는 해제하기 쉽고 개별 경고는 일시 중지하기 쉽지만(잠시 동안 신경 쓰지 않는 경우) 수정 해야 합니다.

비교를 위해 Facebook 코드베이스에서 대화 상자가 표시되는 방식은 다음과 같습니다.

수천 명의 엔지니어가 문제가 없고 덕분에 생산성이 더 높기 때문에 합리적인 기본값이라고 생각합니다. 분명히 하자면, 오픈 소스 버전은 덜 외칠 것입니다.

스타일 조정에 대한 제안 사항이 있으면 https://github.com/facebook/react/pull/7360에 자유롭게 의견을 보내주십시오.

Dan이 말한 것에 덧붙여, 저는 최근에 추가된 오류 로거 흐름에 연결하기 위해 #7360 위에 구축하고 있습니다. 저는 현재 조금 덜 방해가 되는 몇 가지 스타일의 토스트 알림을 시도하고 있습니다. 피드백을 위해 스크린샷 및/또는 Plnkr을 곧 게시하겠습니다.

이러한 경고에는 "축소된 개발 코드" 경고가 포함됩니까? 그렇다면 많은 것들이 아주 깔끔하게 해결될 것입니다.

왜 그런 용도로도 사용할 수 없는지 모르겠습니다.

@gaearon

대부분의 경고에 대해 이것이 사실이라는 데 동의하지만 React 경고는 특히 코드의 버그를 지적합니다. 그것들은 단순한 제안이 아닙니다.

오류 또는 예외 IMO여야 합니다. 그들은 왜 그렇지 않습니까? 예외는 수정을 강요하지만 무시할 수 있는 경고는 그렇지 않습니다.

수천 명의 엔지니어가 문제가 없고 덕분에 생산성이 더 높기 때문에 합리적인 기본값이라고 생각합니다.

나는 이전 시점에서 이것을 언급했지만 그 엔지니어들은 오픈 소스 버전을 사용할 90%의 사람들보다 더 나을 것입니다. 나는 그것이 합리적인 기본값의 반대라고 생각합니다. 개발 도구에 경고가 있는 데에는 이유가 있습니다. 그것들을 재발명하는 것은 나에게 의미가 없습니다. 비활성화되고 다시는 볼 수 없습니다.

이것은 React가 IMO를 너무 많이 하려고 하는 것처럼 보입니다.

내가 정부 계약을 할 때 우리는 모든 프론트 엔드에서 사용해야 하는 공통 라이브러리를 가지고 있었습니다. 콘솔에서 오류를 가져와 토스트 팝업으로 표시합니다. 여러 팀에서 여러 번 프로덕션에 배포했을 뿐만 아니라 많은 개발자가 한 번 보고 영구적으로 비활성화하는 방법을 묻습니다. 나는 이것이 더 같다고 본다.

우리는 개발 단계에서 React 경고에 대해 "경고 상자"를 활성화하는 것을 오랫동안 고려했습니다. 여기에서 데모를 볼 수 있습니다(PR: #7360). 경고가 있을 때만 표시되지만 개발 중에는 매우 일반적이며(항상 수정해야 함) 앱을 개발하는 데 5분 이상을 소비한 사람이라면 누구나 대화 상자를 보고 존재한다는 것을 알게 될 것입니다.

#7360 @gaearon 정말 좋아해요. 새로운 경고 상자에서 배포를 위해 PROD로 전환해야 할 필요성을 강조하는 지원을 듣게 되어 기쁘게 생각합니다. 멋지고 비쥬얼입니다.

Dan이 말한 것에 덧붙여, 저는 최근에 추가된 오류 로거 흐름에 연결하기 위해 #7360 위에 구축하고 있습니다. 저는 현재 조금 덜 방해가 되는 몇 가지 스타일의 토스트 알림을 시도하고 있습니다. 피드백을 위해 스크린샷 및/또는 Plnkr을 곧 게시하겠습니다.

@bvaughn 더 많은 반복을 기대합니다 :)

경고 상자 접근 방식이 너무 거슬린다고 생각하는 사람들을 위해 다른 라이브러리(예: VueJS)는 버그 수정 또는 느린 경로를 권장하기 위해 개발/반복 워크플로 중에 이미 DOM 오버레이를 표시합니다.

내 경험에 따르면 이러한 메시지는 약간의 불편을 겪지만 콘솔에서 볼 수 있는 것보다 더 분명합니다. 나는 그것이 적어도 당신이 prod에 배포해야 하는 것이 아닌 dev 모드에 더 중점을 두고 최종 사용자에게 "더 빠른 모드"를 제공하는 더 많은 사이트로 이어질 것이라는 Dan의 말이 옳다고 생각합니다.

이 변경 후에는 개발 모드를 인식하기가 더 어려워질 것입니다. "경고 대화 상자를 제거하는 방법"을 검색하고 프로덕션용 빌드에 대해 배울 것입니다. 그렇지 않으면 어느 시점에 배포된 일부 경고를 받을 수 있으며 사용자에게 경고가 표시됩니다. 나는 이 경우 사람들이 React 자체를 비난하지 않을 것이라고 생각합니다. 왜냐하면 우리는 단지 상자를 불쾌하게 보여주지 않기 때문입니다. 우리는 개발 모드가 해야 할 일을 하기만 하면 됩니다.

오류 또는 예외 IMO여야 합니다. 그들은 왜 그렇지 않습니까? 예외는 수정을 강제하지만 무시할 수 있는 경고는 그렇지 않습니다.

그것들은 고쳐져야 하지만, 나는 더 급한 일이 있을 수 있습니다. 예를 들어 UI 프로토타입/모의 작업을 자주 하고 그 동안 React가 경고할 수 있는 빠르고 일반적으로 하위 코드를 작성합니다. 이러한 경고를 수정하고 싶지만 적어도 다음 시간에는 모든 코드를 버리지 않을 것이라는 사실을 알기 전까지는 별로 개의치 ​​않습니다. 사람들이 즉시 수정하도록 하면 실험 개발이 크게 느려집니다.

경고 상자 접근 방식이 너무 거슬린다고 생각하는 사람들을 위해 다른 라이브러리(예: VueJS)는 버그 수정 또는 느린 경로를 권장하기 위해 개발/반복 워크플로 중에 이미 DOM 오버레이를 표시합니다.

스크린샷 2017-01-24 at 10 57 11 am

Vue 자체에서 온 것이 확실합니까? webpack-hot-middleware 의 오류 오버레이와 함께 표시되는 webpack 빌드 오류와 매우 유사합니다. 이 경우 범용 프론트엔드 프레임워크가 아닌 오버레이를 추가하는 개발 시간 빌드 도구이기 때문에 미묘하게 다릅니다.

일반적으로 나는 경고 오버레이에 찬성하지만 그것이 무엇인지, 왜 거기에 있는지, 개발 모드를 끌 때 비활성화할 수 있고 비활성화해야 한다는 설명 텍스트를 포함해야 한다고 생각합니다. 그것이 조금 길다면 expando 뒤에 - 그러나 메시지를 전달하기에 좋은 장소처럼 보입니다.

오버레이가 있는 15.2.0과 같은 업데이트가 두렵습니다. 사소한 충돌과 갑자기 DOM 노드에 전달되는 props에 대해 말 그대로 100번의 경고가 표시됩니다. 오류가 있을 수 있지만 감가상각 경고가 그런 침입적인 공간에 속한다고 생각하지 않습니다.

오류가 있을 수 있지만 감가상각 경고가 그런 침입적인 공간에 속한다고 생각하지 않습니다.

이것이 이전에 매우 명확하게 전달되었는지는 모르겠지만 노란색 상자 경고(#7360)에 대한 아이디어는 _모든_ 경고(지원 중단 또는 기타)를 표시하지 않는 것이었습니다. 오히려 팀이 _특히 중요하다고 생각하는 특정 경고가 이러한 방식으로 강조 표시됩니다. 나머지는 아마도 콘솔에 남아 있을 것입니다.

적어도 1~2주 전에 이 기능에 대해 Tom과 내가 나눈 대화에서 발췌한 내용입니다.

15.2의 prop 경고도 IMO의 실수였으며 일반적인 MO를 나타내지 않았습니다. 이를 방지하기 위해 마이너 버전으로 경고 수준을 제어할 수 있는 방법이 있었으면 합니다.

우리 팀이 프로덕션 빌드를 사용하지 않는 주된 이유는 테스트 유틸리티가 포함되어 있지 않기 때문에 JS 단위 테스트를 실행할 수 없기 때문입니다.

먼저 React 팀( @sebmarkbage , @gaearon , @tomocchino 및 기타)에게 이 문제에 대해 논의하고 이번 분기 BlinkOn 및 기타 동기화에서 성능 및 모바일에 대해 공개적으로 이야기해 주셔서 감사합니다.

상태 확인

https://github.com/facebook/react/pull/7360 의 @aweary 에 따르면 이 특정 문제에 대한 Yellow Box 솔루션은 React의 우선순위가 높은 V16 작업이 완료될 때까지 보류되었지만 여전히 발생해야 합니다. https://github.com/facebook/fbjs/pull/165 는 Fiber에서 구현되고 구현되어야 합니다. 후크를 노출하기 위한 좋은 공개 API도 제작해야 합니다. 내 손가락을 지킬거야 🤞

이 문제는 여전히 만연한 것 같습니다

내 책상에 있는 상당수의 프로덕션 앱은 여전히 ​​DEV 모드를 프로덕션으로 제공하고 있습니다. 여기에서 빌드에서 When deploying React apps to production 디버그 문자열을 볼 수 있습니다.

https://cdnjs.cloudflare.com/ajax/libs/react/15.3.1/react.js (tombraider.com)
https://shared.reliclink.com/dlls/vendor-f3e016f6037eb107ffc0.live-shared.min.js (dawnofwar.com)
https://d1xx3pvec9nqb7.cloudfront.net/media/js/thread.af65c1a02d15.js(thread.com )
http://www.sothebys.com/etc/designs/redesigns/sothebys/redesignlibs.min.js (sothebys.com)

나는 여전히 위의 내용에 대한 콘솔에 DEV 모드 경고를 기록하기 위해 pre-Yellow Box 이동이 약간의 영향을 미칠 수 있다는 견해를 갖고 있습니다. 충돌 보고가 이를 고를 수 있도록 콘솔 오류를 발생시키자는 Sebastian의 제안도 고려할 가치가 있다고 느꼈습니다.

바늘을 여기로 옮기기 위해 우리는 또 무엇을 할 수 있습니까?

더 나은 옹호? 저는 DEV 모드를 프로덕션에 제공하지 않는 사람들을 계속 옹호 할 것을 약속하게 되어 기쁩니다. 하지만 V16 이후에 공식 솔루션을 출시할 수 있는지 알고 싶습니다. :)

단기적으로는 create-react-app 가 새 프로젝트가 이 문제를 피하는 데 도움이 되는 좋은 위치에 있는 것 같습니다.

설치 문서 개선 사항

다른 모든 사람들을 위해 Installing React 제목 아래에 명확하고 눈에 띄는 설명을 포함하여 https://facebook.github.io/react/docs/installation.html 에 대한 지원이 있습니까? 생산?

사용자로서 저는 https://facebook.github.io/react/docs/installation.html#development -and-production-versions를 언뜻 보기에 읽을 만한 큰 동기가 없다고 생각합니다.

생각?

우리 팀이 프로덕션 빌드를 사용하지 않는 주된 이유는 테스트 유틸리티가 포함되어 있지 않기 때문에 JS 단위 테스트를 실행할 수 없기 때문입니다.

나는 이것에 대해 혼란스럽다. 프로덕션 웹 사이트에서 테스트를 실행하고 있습니까? 그렇지 않은 경우 프로덕션 웹 사이트에서 프로덕션 빌드를 사용하고 개발 중에 개발 빌드를 사용하지 못하는 이유는 무엇입니까?

다른 모든 사람들을 위해 프로덕션에서 DEV 모드를 염두에 두도록 사람들에게 상기시키는 React 설치 제목 아래에 명확하고 가시적인 설명을 포함하여 https://facebook.github.io/react/docs/installation.html 에 대한 지원이 있습니까?

확신하는. PR을 보내고 싶습니까?

확신하는. PR을 보내고 싶습니까?

무엇보다 행복합니다.

아마도 벤치마크에 대한 단어는 성능을 dev 모드에서 반응과 비교하는 사람들을 교육하는 데 도움이 될 것입니다.

react devtools 확장을 활용하여 dev 모드에서 react를 사용하여 페이지를 열 때 알림이나 분명한 것을 표시할 수 있다고 생각합니까?

나는 이 아이디어를 좋아한다! devtools에 대해 제안된 아이콘 세트를 모았습니다(facebook/react-devtools/pull/652 참조).

우리는 거꾸로 그리고 미래에 안전한 방식으로 dev vs prod React를 감지하는 방법을 결정해야 하지만 월요일 회의 의제에 추가했습니다.

이 문제를 해결하기 위해 몇 가지 합리적인 단계를 수행했습니다.

• React DevTools(최대 700K 사용자 포함)는 이제 개발 빌드에 대해 고유한 빨간색 아이콘을 표시합니다. 이것은 사람들이 버전 간의 차이점을 일찍 배우는 데 도움이 됩니다. 또한 개발자가 방문하는 사이트에서 이를 알아차리고 작업하는 사람들에게 보고하기 때문에 동료 압력도 발생합니다. 우리는 몇 가지 주요 사이트에서 이 기능을 출시한 지 며칠 만에 문제를 해결하는 것을 보았습니다.

• React DevTools의 알림은 모든 주요 번들러에 대한 프로덕션 빌드를 생성하기 위한 지침을 게시한 웹사이트로 연결됩니다. 또한 설치 페이지에서 더 눈에 띄게 만들었습니다.

• Create React App은 계속해서 인기를 얻었습니다. 별도의 명령으로 초기에 이러한 구분을 가르칩니다. 또한 터미널에서 개발 모드에 대한 영구 알림을 표시합니다.

• React 16 베타 1 (및 추가 릴리스)은 react.development.js 및 react.production.min.js 를 파일 이름으로 제공하여 비축소 빌드를 프로덕션에서 사용해서는 안 된다는 점을 분명히 합니다.

앞으로 이 문제를 해결하기 위해 더 많은 방법을 모색할 수 있다고 생각하지만 지금은 더 과감한 조치 없이 앞으로 나아갈 수 있고 도움이 되는지 확인할 수 있습니다. 토론에 참여해주신 모든 분들께 감사드립니다.