Back

React.StrictMode

오랜만에 CRA 프로젝트 생성을 해보니 index.html에 뭔가 이상한 컴포넌트가 감싸진 형태로 만들어진다.

<React.StrictMode> 라는 낯선 친구가 보인다. 뭐 strict mode 관련한 것은 알겠는데, 얘는 무엇이고, 뭐가 달라진 것이고 왜 이렇게 하는 것일까 알아보게 되었다.

ReactDOM.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>,
  document.getElementById('root')
);

오래전에 CRA 프로젝트 생성했을 때도 저런 것이 있었는지 확실하게 검증하기 위해 옛날 프로젝트 커밋 내용을 뒤져봤다. 다행이 저런 컴포넌트는 없었다. 처음 생성하면 하면 index.html에 기본적으로 다음과 같이 생성이 된다.

ReactDOM.render(<App />, document.getElementById('root'));

둘의 차이를 생각해보니, 아래의 것은 2020년에 생성했던 프로젝트인데 그차이 뿐일까 하고 package.json을 열어 버전을 확인하게 되었다.

2020년에는 react 16버전 이고 글쓰는 지금 시점의 react는 17 버전이다.

Strict Mode - React

공식 documentation에 잘 나와있다.

  • 이 엄격모드는 애플리케이션에 잠재적인 문제가 될 수 있는 것들을 강조해준다.
  • fregment처럼 실제로 랜더링 되지 않으며, 프로젝트의 문제를 강조하고, 추가검사 경고를 활성화 한다.
  • 개발모드에만 실행되며, 빌드하면 없는 것이나 마찬가지니까 신경쓰지 말아라.
  • <React.StrictMode> 안에 감싸진 컴포넌트들만 검사가 이루어진다.
  • 감싸진 레벨에 해당하는 컴포넌트들만 검사하는 것이 아니라, 그 내부에 존재하는 자손들까지 검사가 이루어진다.

아무튼 그냥 신경쓰지 않더라도 아무런 변화가 없다는 것이다.
이 strict 모드를 사용하면 개발에 필요한 몇가지 도움이 된다고 한다.

이 strict mode 관련 글을 작성했을 때 알게된 것은 아니지만, 아래와 같은 일을 겪고, 이 글을 다시 읽게 되었다.

react router를 사용했을 때 react router 공식 문서에 존재하는 authentication 관련 예제를 그대로 사용하면서 알게된 것인데, 인증이 이루어진 상태에서만 router에 포함된 컴포넌트를 부를 수 있게 만든 상위의 컴포넌트에서 인증이 없다면 alert를 띄우는 코드를 작성했었다.

useEffect를 사용하지도 않고, 그냥 컴포넌트 안에 alert를 작성했는데, 두 번 뜨는 현상이 발생했다. 공식문서에서는 예제를 stackblitz를 통해서 보여주는데, 여기서도 직접 alert를 넣어보니 두 번 보이게 되었다.

아니 이 react router를 사용한다는 것은 컴포넌트를 두 번 렌더링을 해야 하는 일이 무조건 필요한 것인가? 이런 생각을 했고 다양한 시도를 했었다.

그리고 알고보니 꼭 react router로 부른 컴포넌트 뿐만 아니라 일반적인 컴포넌트도 컴포넌트 안에 넣은 alert는 두 번 보였고, debugger를 통해 확인해봐도 두 번 걸리게 되었다. console.log는 한 번만 보였다.
useEffect를 사용해보니 한 번만 동작했다.

처음에는 redux store 라던가 내가 파악하지 못한 어떤 state값이 변경하면서 다시 렌더링이 되는 것이라고도 생각도 해봤지만, 아무것도 없는 깨끗한 청정지역 최상위 app.js에서도 동일한 현상이 일어났고, 이는 뭔가 잘못 되었다고 생각하고 검색을 해보게 되었다.

stackoverflow에서 이는 strict 모드 때문이라고 하였고, 이 strict모드를 끄고 테스트를 해보라는 답변을 봤다.
직접 해보니 한 번만 실행이 되었다.

Strict Mode - React

해당 공식문서에서도 자세하게 알아보게 되었다.

strict mode에서는 의도적으로 두 번 실행하도록 만든다고 한다.

아직까지는 이렇게 하면 어떤 이점이 있어서 부작용이 검사되는지는 확실하게는 모르겠다.
그래도 react 프로젝트 contributors 들이 집단지성을 통해 잘 만들어줬기에 그것이 곧 법이고 믿고 사용한다.
두 번 진행하도록 하여 의도적으로 오류를 만들며, 이렇게 하더라도 오류가 없도록 하는 코드를 작성해야만 미래에 잠재적인 오류를 피할 수 있다는 것이라고 두루뭉실하게 이해했다.

이는 strict mode를 사용하는 개발모드에서만 이렇고, 실제 프로덕션에 사용하기 위해 빌드를 할 경우에는 이런 현상이 없다고 한다.

한 번 겪었으니 다음에는 이것 때문에 당황하는 일은 없을 것이다.

Published 2021-07-05