리액트의 많은 개발자들이 완전히 알지 못하는 몇 가지 알려지지 않은 측면을 소개합니다:
- 가상 DOM Diffing이 항상 완벽하지는 않습니다
리액트의 가상 DOM 차이 비교 알고리즘은 꽤 효율적이지만 완벽하지는 않습니다. 일반적인 시나리오에 최적화되어 있지만 모든 예외적인 상황을 완벽하게 처리하지 못할 수 있습니다. 복잡한 UI 업데이트나 성능 집약적인 애플리케이션의 경우 때로는 React.memo와 같은 사용자 정의 최적화나 대안적 접근 방식이 필요할 수 있습니다.
- 함수형 컴포넌트와 성능
기능 구성 요소는 때때로 클래스 구성 요소보다 성능이 뛰어날 수 있습니다. 이는 클래스 시스템과 라이프사이클 메서드의 오버헤드를 피하기 때문입니다. 그러나 useMemo 및 useCallback과 같은 훅을 신중하게 사용하지 않으면 불필요한 다시 렌더링으로 인해 성능 문제가 발생할 수 있습니다.
- 조정 및 키
리스트를 렌더링할 때 React는 요소를 고유하게 식별하기 위해 키를 사용합니다. 그러나 키는 전역적으로 고유할 필요는 없지만 형제 사이에서 고유해야 합니다. 키를 잘못 사용하면(예: 인덱스 사용) 효율적인 업데이트와 버그가 발생할 수 있습니다. 특히 리스트가 동적으로 변경될 때 문제가 발생할 수 있습니다.
- Strict 모드는 프로덕션에 영향을 미치지 않습니다.
React의 Strict Mode는 개발 중 잠재적인 문제를 식별하기 위한 도구입니다. 추가적인 검사를 수행하고 일부 라이프사이클 메서드를 두 번 호출하여 문제점을 강조하지만, 이러한 검사는 제품 빌드에 영향을 미치지 않습니다. 많은 개발자들이 이러한 검사가 제품의 성능이나 동작에 영향을 미친다고 잘못 이해합니다.
- useEffect와 Cleanup 사용
useEffect 훅은 까다로울 수 있습니다. 클린업을 적절히 처리하는 것이 중요합니다(예: 비동기 작업에서). 구독 또는 타이머와 같은 효과를 청소하는 것을 잊는다면 의도하지 않은 동작이나 성능 문제를 일으킬 수 있습니다.
- Context API 성능 고려 사항
Context API는 컴포넌트 트리 아래로 데이터를 전달하는 데 유용하지만 주의해서 사용하지 않으면 성능 문제를 일으킬 수 있습니다. 컨텍스트 값을 업데이트하면 해당 데이터를 사용하지 않는 경우에도 모든 컴포넌트의 다시 렌더링이 발생할 수 있습니다. React.memo를 사용하거나 컨텍스트를 작은 컨텍스트로 분할하면 이 문제를 완화할 수 있습니다.
- React Fiber 및 조정
React Fiber는 비동기 렌더링과 같은 기능을 가능케 하는 조정 알고리즘입니다. React Fiber는 복잡한 UI 업데이트를 처리하는 내부 아키텍처를 도입했지만 대부분의 개발자가 직접 걱정할 필요는 없습니다. React의 내부가 발전했다는 점을 이해하면 문제 해결과 성능 최적화에 도움이 될 수 있습니다.
- React의 프롭 드릴링과 대안들
프롭 드릴링(prop drilling)은 여러 계층의 컴포넌트를 통해 전달되는 프롭(prop)으로 번거로워질 수 있습니다. React의 Context API는 이 문제를 완화해주지만, Redux, Zustand, 또는 Recoil과 같은 더 복잡한 시나리오를 위한 다른 상태 관리 솔루션을 탐색하는 것도 값진 시간일 수 있습니다.
- 개발 및 프로덕션 빌드
React의 개발 빌드는 프로덕션 빌드에 없는 추가 경고 및 검사 기능을 포함하고 있습니다. 이로 인해 디버깅이 더 쉬워지지만 성능에 영향을 줄 수 있습니다. 배포 시 불필요한 오버헤드를 피하기 위해 언제나 애플리케이션이 프로덕션 빌드를 사용하고 있는지 확인하세요.
- 동시 모드 및 미래 기능
리액트의 동시 모드와 실험적인 기능은 렌더링 성능과 사용자 경험을 크게 향상시킬 것으로 기대됩니다. 그러나 이러한 기능들은 아직 실험 단계에 있고 완전히 안정화되지 않았습니다. 흥미로운 가능성을 제공하지만 조심해서 사용해야 합니다.