[TIL] 0617

context Api의 단점과 해결책

면접 때 context Api단점이 무엇이고 그 단점을 어떻게 보완할 수 있는지 질문이 들어왔는데,
대답은 했지만 아주 정확히 알고 있지는 않구나 라는 생각이 들어서 복습했다.

전역 상태관리란?
props drilling없이 여러 컴포넌트가 접근할 수 있도록 전역범위에서 상태를 관리하는 것.

Context API
provider를 만들어서 공유할 값들을 넣어주고 consumer로 값을 받아서 사용한다.

장점
다른 라이브러리를 설치할 필요 없이 리액트 자체적으로 전역 상태를 관리할 수 있다

단점

• Context.Provider는 value로 저장된 값이 변경되면 자기의 모든 자식을 다 같이 리렌더링시킨다. 변한 상태를 쓰는 컴포넌트가 아니어도 리렌더링 되는 것
• value에 있는 값을 사용하면 그 값이 변하지 않았어도 같이 리렌더링 됨.

해결책

• split context → Provider hell을 야기
  • 상태 종류마다 프로바이더를 만들어주는게 좋음 (그 프로바이더 상태 안쓰면 리렌더링안되니까)
  • 데이터와 핸들러의 provider를 나눈다 (핸들러만 받아서 쓰는 컴포넌트가 상태가 변할 때도 같이 리렌더링되기 때문)
• useMemo, reactMemo를 사용 → 코드가 복잡해지고 비교 연산이 늘어난다.

결론

• 전역 상태가 많지 않고, 자주 바뀌지 않는 정적인 값을 사용할 때 좋다
• 정적인 값에 가까운 값을 props drilling 대신할 때 적절하다.

폼 태그 사용 시의 렌더링 최적화

리액트에서 form관련 태그를 사용할 때에는 무조건 제어 컴포넌트 방식으로 사용해야하는 줄 알았다.
제어 컴포넌트 방식은 입력을 할 때마다 리렌더링되는데, 다중 폼태그를 사용하면 불필요하게 리렌더링되는 엘리먼트가 많아진다는 단점이 있었다. 면접에서 이러한 불필요한 렌더링을 어떻게 막을 수 있을지 질문하셨는데 React.memo훅을 사용하는 것밖에 생각이 안났다. 면접관님이 비제어 컴포넌트와 useRef를 사용해서 해결할 수 도 있다고 알려주셔서 공식문서를 보면서 자세히 알아보게되었다.

또한 useMemo를 무분별하게 사용하면 오히려 메모리를 낭비하게 되어 성능이 안좋아진다는 것도 알게됐다. memoization 기능을 사용할 때는 memoization 후, 얼마나 재활용이 가능한 것인가를 잘 따져봐서 재활용이 많이 될 때만 사용해야 한다.