React: Devtools V4: 하이라이트 업데이트는 어디에 있습니까?

동일한 문제가 여기에 있습니다. 하이라이트 업데이트가 사라졌습니다.
업데이트를 추적하기 위해 지금 프로파일러를 사용해야 하는지 궁금합니다.

https://www.reddit.com/r/reactjs/comments/cqx554/introducing_the_new_react_devtools/ex1r9nb/

솔직한 대답은 그것을 구현할 시간이 없었고 다른 모든 기능이 출시되는 것을 차단할 만큼 중요하다고 생각하지 않았다는 것입니다.

그러나 우리가 그것을 다시 추가할지 확신할 수 없는 더 깊은 이유가 있습니다. 다시 렌더링하는 것 자체가 나쁘다는 잘못된 생각에 기여합니다(저렴한 경우에는 그렇지 않음). 그래서 사람들은 쓸모없는 것들을 최적화하고 실제 성능 문제를 놓치는 데 시간을 보냅니다.

새로운 DevTools에는 코드에서 실제 성능 문제를 찾는 데 도움이 되는 프로파일러가 포함되어 있습니다. 추가 렌더를 찾기 위한 초경량 방법에 대한 열망을 이해합니다. 아마도 추가할 것입니다. 하지만 먼저 작동 방식에 대해 더 생각해야 합니다.

인라인 주석을 추가하도록 수정 됨

일부 관련 이전 토론 https://github.com/bvaughn/react-devtools-experimental/issues/244

하이라이트 업데이트는 성능 문제를 수정하는 데는 그다지 유용하지 않았지만(새 프로파일러가 그 점에서 훨씬 우수함) 놀라운 렌더링을 발견하는 데는 매우 유용했습니다. 특히 한 가지 변경으로 인해 앱의 다른 부분에서 다시 렌더링될 수 있는 컨텍스트로 작업할 때 수많은 시간을 절약할 수 있었습니다. 프로파일러에서 작업할 때 트리의 일부에만 집중하는 경향이 있으므로 회귀를 놓치기 쉽습니다.

잘못된 아이디어를 주는 것에 대한 @gaearon 의 우려를 이해합니다.

1. 렌더링 시간에 따라 윤곽선 색상 선택

저렴한 렌더는 녹색이어야 하고 값비싼 렌더는 노란색 또는 빨간색이어야 합니다. 또는 프로파일러에서 사용하는 것과 똑같은 색상을 사용하십시오.

2. 윤곽 페이드 속도 변경

윤곽 페이드 애니메이션은 렌더링 지속 시간에 상대적이어야 합니다. 빠른 렌더는 즉시 페이드되어야 하고 느린 렌더는 더 천천히 페이드되어야 합니다.

3. 도색된 부분의 구분

나는 때때로 Highlight Updates 를 Chrome의 Paint Flashing . 이것은 DOM 효과가 없는 렌더와 다르게 강조표시되도록 다시 칠하도록 하는 렌더를 만들었습니다. DevTools에는 비슷한 기능이 내장되어 있어야 한다고 생각합니다.

• 다시 칠하지 않는 값비싼 렌더는 성능 최적화의 주요 대상이 되어야 합니다.
• 다시 칠하는 렌더링은 분명히 수행해야 할 작업을 수행하고 있습니다.
• 다시 칠하지 않는 빠른 렌더링은 무시해도 됩니다.

위의 첫 번째 항목만 깜박이는 설정이 있을 수도 있습니다(일부 구성 가능한 임계값 포함).

"저렴한" 또는 "빠른" 렌더를 식별하는 것은 다음과 같은 요인으로 인해 생각만큼 간단하지 않습니다.

• 개발 빌드는 프로덕션 빌드보다 훨씬 느립니다.
• 개발자 랩톱은 일반적으로 최종 사용자 랩톱보다 훨씬 빠릅니다.

프로파일러의 좋은 점은 속도를 상대적으로 보고하여 주어진 세션에서 애플리케이션의 가장 느린 부분에 집중할 수 있다는 것입니다. (가장 느린 부분이 충분히 빠를 때를 결정할 수 있습니다.) 이것은 돌이켜보면서만 수행할 수 있습니다.

또한 커밋에 대한 정적 스냅샷과 변경된 props/state를 제공하여 특정 구성 요소가 얼마나 자주 렌더링되는지(예상보다 많았습니까?) 뿐만 아니라 구체적으로 _왜_ 다시 렌더링되었는지, 그 밖의 사항을 확인할 수 있습니다. 그것으로 다시 렌더링됩니다.

프로파일러의 일부로 DevTools에 일종의 업데이트 플래싱 메커니즘을 다시 추가하는 방법을 고려할 수 있는 좋은 기회가 있다고 생각합니다. 프로파일링이 활성화되어 있을 때만 깜박일 수도 있습니다(예전처럼)? 프로파일링이 중지된 후 프로파일러에서 새 커밋을 선택하면 다시 렌더링된 모든 구성 요소가 깜박일까요? (뭔가 놓친 경우 "재생"할 수 있기 때문에 그 아이디어가 마음에 듭니다.) 약간의 실험을 통해 가장 잘 작동하는 것을 확인해야 합니다.

이 기능을 많이 사용하여 렌더링해야 하는 구성 요소만 렌더링되도록 했습니다. 동일한 구성 요소를 다른 ID로 여러 번 렌더링하는 앱이 있으며 다시 렌더링해야 하는 모든 요소가 아니라 하나만 렌더링되도록 하고 싶습니다. 새 프로파일러로 이를 확인할 방법이 없습니다.

새 프로파일러로 이것을 확인할 방법이 없습니다

당신은 무엇을 시도 했습니까? 프로파일러는 하나의 자식이 다시 렌더링되는지 아니면 여러 개인지 명확하게 보여야 합니다.

저는 '업데이트 하이라이트'를 자주 사용하고 있었습니다. 제가 가장 많이 사용한 dev-tools의 기능이었습니다. 업데이트 빈도가 아니라 업데이트된 내용을 확인하기 위한 것입니다. 물론 프로파일러를 사용하여 이 작업을 수행할 수 있지만 빠른 시각적 표시보다 훨씬 번거롭습니다.

나에게 "업데이트 하이라이트"는 "킬러 기능"이었습니다 ...

우리는 당신의 말을 듣습니다 :-) 나는 "나는 이것을 사용했습니다"라고 말하는 더 이상의 의견이 이 스레드에서 가치가 있는 것에 대해 크게 도움이 될 것이라고 생각하지 않습니다. 우리는 이 기능을 사용하는 사람들이 있다는 것을 알고 있으며 이를 다시 되돌릴 수 있는 올바른 방법이 무엇인지 생각하고 있습니다. 피드백 주셔서 감사합니다!

이 옵션은 렌더링 문제를 즉시 표시하기 위해 일상적인 작업 프로세스에 필수적인 구성 요소였습니다. 이 멋진 기능을 곧 다시 가져올 수 있다면 정말 기쁠 것입니다.

재렌더링에 대한 높은 수준의 빠른 보기를 가능하게 하는 이 기능의 일부 버전을 다시 가져올 때 +1입니다(컨텍스트를 업데이트할 때와 같이 완전히 괜찮은 재렌더링의 경우에도).

다시 가져올 때 +1

이 멋진 기능을 곧 다시 가져올 수 있다면 정말 기쁠 것입니다.

위에서 요청한 대로:

"이것을 사용했습니다"라고 말하는 추가 댓글은 큰 도움이 될 것이라고 생각하지 않습니다.

이것을 더 명시적으로 바꾸려면:

우리는 당신을 듣고!

많은 사람들이 이 저장소를 구독하고 있습니다. 우리는 몇 시간마다 같은 댓글로 스팸을 보내고 싶지 않습니다. 또한 개인적으로 GitHub 알림을 사용합니다. 이 스레드가 매일 "+1"로 부딪히면 결국 노이즈를 줄이기 위해 구독을 취소해야 합니다. 당신의 의도와 반대일 가능성이 높습니다.

댓글을 작성하기 전에 이전에 말하지 않은 내용을 추가하고 있는지 확인하십시오. 쓰고 싶은 것과 비슷한 댓글이 보이면 대신 👍 반응을 추가하세요.

이해 주셔서 감사합니다.
귀하의 의견에 감사드립니다. 하지만 👍는 작업의 우선 순위를 정하는 데 도움이 됩니다.

이전에 말하지 않은 것을 추가하고 있다는 것입니다.

이전 버전의 확장 프로그램을 설치할 수 있는 방법이 있는지 묻고 싶습니다
_(독립형 버전을 설치하려고 했지만 v3 repo의 이 링크가 끊어져 Crome 확장에 대한 링크가 최신 버전으로 연결됨)_

새로운 DevTools에는 코드에서 실제 성능 문제를 찾는 데 도움이 되는 프로파일러가 포함되어 있습니다.

그리고 여기에 새로운 확장이 내 흐름을 중단시킨 이유가 있습니다. 프로파일러는 버튼을 눌러 프로파일링을 시작한 다음 끝내도록 권장하지만 즉시 실행되지는 않습니다. 업데이트 하이라이터를 사용하면 추가 동작 없이 모든 것을 볼 수 있습니다. 또한 실제 업데이트와 실제로 트리거된 내용을 매우 직관적인 방식으로 보여줍니다.

이것은 실시간 업데이트 이기도 한 Chrome DevTools의 자체 성능 모니터를 생각나게 합니다. 그 움직임은 복잡성과 성능에 대한 영향 때문에 아마도 의미가 있었겠지만, 요점은 엄청난 마찰을 추가한다는 것입니다( @Carduelis가 지적했듯이 시작/중지 버튼을 누르지 않는 것이 훨씬 쉽습니다). 그것은 OODA 루프에 렌치를 던집니다. 의심할 여지 없이 사용자가 이 기능을 사용하는 빈도에 영향을 미치고 앱 자체의 품질에도 영향을 미칠 것입니다.

이것을 잘못된 방식으로 받아들이지 마십시오 --- 새로운 성능 모니터는 멋지고 깊이 파고들 필요가 있을 때 유용하지만 이전 업데이트 강조 표시와 같은 빠르고 더러운 시각화를 단순히 대체할 수는 없습니다.

이전 버전의 확장 프로그램을 설치할 수 있는 방법이 있는지 묻고 싶습니다.

@Carduelis 이전 버전의 DevTools에 대한 설치 지침은 릴리스 블로그 게시물에서 다룹니다. https://reactjs.org/blog/2019/08/15/new-react-devtools.html#how -do-i-get- 구버전-뒤로

위의 지침에 따라 Chrome에 v3를 설치하려고 약간 서클을 돌았지만 독립 실행형 프로파일러가 변경 사항을 강조 표시하도록 할 수 없었습니다. 따라서 작동하고 구성 요소 최적화로 돌아가고 싶다면 자세한 단계별 지침을 작성했습니다.

React Dev Tools V3 설치(단계별 지침) :
https://gist.github.com/oztune/01be16a2f90283aad82422b37221d522

기술적인 수준에서는 "심층적인 프로파일링 도구" > "어리석은 강조 표시 기능"처럼 보일 수 있지만 우리는 모두 인간일 뿐이며 단순한 시각적 신호에서 많은 정보를 빠르게 수집합니다. 어떤 면에서 강조 표시 기능은 사용하기 쉽기 때문에 매우 중요합니다. 저에게는 이것이 제가 React Dev Tools를 90% 여는 이유입니다.

기술적인 수준에서는 "심층적인 프로파일링 도구" > "어리석은 강조 표시 기능"처럼 보일 수 있지만 우리는 모두 인간일 뿐이며 단순한 시각적 신호에서 많은 정보를 빠르게 수집합니다. 어떤 면에서 강조 표시 기능은 사용하기 쉽기 때문에 매우 중요합니다.

나는 Dan이나 내가 그것이 "사용하기 더 쉽다"는 것에 대해 논쟁했다고 생각하지 않습니다. 단지 사람들이 "고장"되지 않은 것을 "수정"하는 데 시간을 투자하도록 장려할 수 있을 것입니다 (일명 느리지 않은 것을 최적화하는 것 이상). . 우리는 "성능" 비용에 대한 두려움 때문에 인라인 함수를 광범위하게 기피하는 것과 같은 상황에서 이 패턴을 본 적이 있습니다. 문제가 아닌 문제를 해결하는 데 투자한 에너지는 잠재적으로 더 중요한 다른 문제를 해결하는 데 사용되지 않는 에너지입니다.

위에서 말했듯 이 프로파일러의 일부로 DevTools에 일종의 업데이트 플래싱 메커니즘을 다시 추가할 수 있는 좋은 기회가 있다고 생각합니다.

현실적으로 그것은 내 접시에서 가장 높은 우선 순위가 아니므로 이 대화를 반복하는 것보다 인내심을 요구할 것입니다. 우리는 이 기능이 중요하다는 것을 듣고 인정합니다. 우리는 위에서 언급한 다른 고려 사항과 편의성을 비교하여 현재 가지고 있는 것보다 더 많은 것을 생각해내려고 노력할 것입니다.

과도한 최적화에 대한 요점에서는 시각적 렌더링 강조 표시가 이를 장려할 수 있음을 증명할 수 있습니다. 그러므로 나는 여기 토론에 무언가를 추가하고 싶습니다.

기능을 놓친 사람들을 위해 https://github.com/welldone-software/why-did-you-render 더 많은 정보를 찾을 수 있습니다.

이것은 이 기능이 구현될 때 고려해야 할 사항일 수 있습니다. 기본적으로 WhyDidYouRender는 깊은 값 비교를 수행하고 재렌더링 간에 실제로 변경되지 않은 경우에만 보고합니다. 시각적 렌더 하이라이트에 이와 동일한 필터링을 적용하는 것이 좋습니다. 이것은 더 사려 깊은 최적화를 지시할 것입니다(또한 프로파일러가 제공하지 않는 구별입니다).

이론상으로는 성능 문제 없이 전체 앱을 다시 렌더링할 수 있어야 하므로 렌더링 강조 표시를 피하기 위해 모든 곳에 SCU를 추가하는 것은 비생산적인 경로입니다.

나는 여전히 rerender 하이라이트가 React 작동 방식에 대한 데모에 유용하다는 것을 알았습니다.

기본적으로 WhyDidYouRender는 깊은 값 비교를 수행하고 재렌더링 간에 실제로 변경되지 않은 경우에만 보고합니다.

실제로 성능 문제가 있는 앱의 경우 매우 느리게 들립니다. 어떤 종류의 심층 비교도 확실히 우리가 항상 하고 싶은 것은 아닙니다. 켤 때(저속 성능을 선택하기 위해) 프로파일러를 시작하지 않는 이유는 무엇입니까?

이것은 더 사려 깊은 최적화를 지시할 것입니다(또한 프로파일러가 제공하지 않는 구별입니다).

프로파일러는 다음 버전을 제공합니다.

다시 렌더링된 구성 요소를 보았지만 props/state/hooks가 변경되지 않은 경우 설명하고 있는 것입니다.

@bvaughn 일반적으로 한 번에 단일 구성 요소에 대해서만 심층 비교를 켭니다. 따라서 기본적으로 모든 구성 요소에 대해 설정하는 것이 아니라는 데 동의합니다. 아마도 녹색 막대를 마우스 오른쪽 버튼으로 클릭하고 "렌더 업데이트 강조 표시"를 선택하는 것입니다.
그것은 꽤 매끄럽고 매우 유용하지만 파헤쳐야 하는 것입니다.

@bvaughn 저는 "이것이 왜 렌더링 되었습니까?"를 좋아합니다. 기능(중간에 Highlight Updates 이 다시 고려되는 동안)이지만 사용 가능한 모든 문서를 읽고 YouTube 자습서를 훑어본 후에도 몇 가지 경우에 대해 해석하는 방법이 아직 확실하지 않습니다.

밑줄이 의미하는 바가 직관적이지 않습니다.

왜 렌더링 되었습니까?

• 소품 변경: (__)

후크 API만 사용하지만 여전히 의미가 확실하지 않습니다.

왜 렌더링 되었습니까?

• 후크 변경

변경된 실제 props / state 를 나열하는 명백한 경우 외에 이러한 경우와 내가 아직 만나지 못한 다른 경우에 대한 한 문장 또는 두 개의 설명이 있을 가능성이 있습니까?

밑줄이 의미하는 바가 직관적이지 않습니다.

앱에서 __ 라는 이름의 소품이 전달되고 커밋 사이에 해당 소품이 변경되는 것 같습니다 😄

후크 API만 사용하지만 여전히 의미가 확실하지 않습니다.

#16477을 참조하십시오.

안녕하세요

저는 하이라이트 업데이트를 많이 사용하고 있었습니다. 저는 자주 새로 고침되는 앱을 개발 중이며 그 미래는 제 일상 업무에 필수적이었습니다.

@bvaughn이 제시한 솔루션을

이것을 다시 구현하시겠습니까?? 그렇지 않다면 어떻게 내 React Dev Tools를 다운그레이드할 수 있습니까? 왜냐하면 그것 없이는 개발할 수 없기 때문입니다.

이것을 다시 구현하시겠습니까?? 그렇지 않다면 어떻게 내 React Dev Tools를 다운그레이드할 수 있습니까? 왜냐하면 그것 없이는 개발할 수 없기 때문입니다.

@oztune이 이미 답변했습니다.

이전 버전을 다시 받으려면 어떻게 해야 합니까?
https://reactjs.org/blog/2019/08/15/new-react-devtools.html#how -do-i-get-the-old-version-back

이전 버전을 다시 원합니다. 새 기능에서 손실된 기능이 너무 많아 도움이 되지 않습니다.

이전 버전을 다시 원합니다. 새 기능에서 손실된 기능이 너무 많아 도움이 되지 않습니다.

나를 위해 일한 이전 버전을 다시 얻는 방법은 다음과 같습니다.
https://gist.github.com/oztune/01be16a2f90283aad82422b37221d522

안녕하세요 @einarq 실제로 새 버전에서 누락된 기능을 갖고 싶습니다. 나는 좋은 새로운 것들을 많이 보았지만 오래된 것들 중 일부는 중요했으며 제거 된 방식으로 이해하지 못합니다. 이제 다시 렌더링을 확인하기 위해 렌더링 기능에 콘솔 로그를 넣어 다시 렌더링 횟수를 줄이는지 여부를 확인합니다. 이상적이지는 않지만 작동합니다. 이전 버전은 내가 발견할 수 있는 다른 불필요한 렌더링을 보여주기 때문에 이것을 엄청나게 쉽고 유용하게 만들었습니다. 지금, 이것은 단지 고통스럽습니다.

누락된 기능을 새 버전으로 되돌리십시오.

내 단어로 새 버전은 다음을 의미합니다. 이전 버전의 재설계 및 개선과 새로운 미래가 추가되었습니다. 제거되지 않고 이전 버전과 다른 새로운 기능이 추가되었습니다.

또한 왜 이제 상태 값을 변경할 수 없습니까?

그리고 props Boolean은 더 이상 체크박스가 아닙니다 ?? 정말 멋졌습니다. 그리고 또 갔다.

이제 상태를 변경할 수 없으며 대신 false/true를 입력해야 합니다. 대신 클릭하고 구성 요소가 이에 어떻게 반응하는지 확인합니다.

짜증나.

안녕하세요 @PMustard 입니다 .

저는 이 작업을 하지 않습니다. 새 버전이 마음에 들지 않으면 이전 버전의 dev-tools를 되돌릴 수 있는 한 가지 잠재적인 접근 방식을 제안했을 뿐입니다. 그것은 나를 위해 일했습니다.

dev-tools(주로 Brian Vaughn?)에서 작업하는 팀이 별도의 문제를 만들면 귀하의 우려 사항을 고려할 것이라고 확신합니다.

그리고 약간의 감사를 표시하는 것을 잊지 마십시오. 우리는 이러한 도구를 무료로 받고 있습니다 :)
건설적인 피드백만 가능합니다.

문안 인사,

에이나르

이 기능이 긴급하게 필요한 경우 이전 버전을 해결 방법으로 사용할 수 있습니다. https://reactjs.org/blog/2019/08/15/new-react-devtools.html#how -do-i-get-the -이전 버전-뒤로. 또한 Profiler를 사용해 볼 것을 권장합니다. 실행하는 데 약간의 노력이 필요하지만 어떤 재렌더링이 중요하고 어떤 것이 중요하지 않은지 알려줍니다. 렌더 번호를 계산하는 것은 종종 실제 성능 문제에서 주의를 산만하게 합니다.

예상치 못한 렌더링을 쉽게 찾아내는 것이 중요하다는 것을 이해합니다. 우리는 https://github.com/facebook/react/issues/16437#issuecomment -523629000에서 이것이 우리의 레이더에 있으며 "이것이 필요합니다"라는 더 많은 의견이 도움이 되지 않는다고 설명했습니다. 그럼에도 불구하고 이 스레드는 "이것이 필요합니다"라는 의견을 계속 수집하고 있으므로 알림 홍수를 줄이기 위해 잠글 것입니다. 목소리가 들리니 안심하십시오.

다음 주의 사항과 함께 새 DevTools(#16989)에서 이 기능을 구현했습니다.

• 현재로서는 브라우저 확장(및 react-devtools-inline NPM 패키지)에서만 활성화되어 있으므로 React DOM만 지원합니다.
• 후속 PR을 제출하려는 경우 누군가가 추가할 수 있지만 레거시 렌더러(v15)에는 구현되지 않습니다.

#16989가 상륙하므로 이 문제를 종료합니다. 오늘 새로운 기능과 함께 4.2가 출시될 것입니다.