다음은 많은 개발자가 완전히 인식하지 못하는 React의 잘 알려지지 않은 측면입니다.

1. 가상 DOM 비교가 항상 완벽한 것은 아닙니다.

React의 가상 DOM 비교 알고리즘은 매우 효율적이지만 완벽하지는 않습니다. 일반적인 시나리오에 최적화되어 있지만 모든 극단적인 경우를 완벽하게 처리할 수는 없습니다. 복잡한 UI 업데이트나 성능 집약적인 애플리케이션의 경우 때로는 맞춤 최적화나 대체 접근 방식(예: React.memo)이 필요합니다.

2. 기능적 구성요소 및 성능

기능적 구성 요소는 클래스 시스템 및 수명 주기 메서드의 오버헤드를 피하기 때문에 클래스 구성 요소보다 성능이 더 좋을 수 있습니다. 그러나 useMemo 및 useCallback과 같은 후크를 주의 깊게 사용하지 않으면 기능적 구성 요소가 불필요한 다시 렌더링으로 인해 성능 문제를 겪을 수 있습니다.

삼. 조정 및 키

목록을 렌더링할 때 React는 키를 사용하여 요소를 고유하게 식별합니다. 그러나 키는 전역적으로 고유할 필요는 없지만 형제 간에는 고유해야 합니다. 키를 부적절하게 사용하면(예: 인덱스 사용) 비효율적인 업데이트와 버그가 발생할 수 있으며, 특히 목록이 동적으로 변경되는 경우에는 더욱 그렇습니다.

4. 엄격 모드는 프로덕션에 영향을 주지 않습니다.

React의 Strict 모드는 개발 시 잠재적인 문제를 식별하기 위한 도구입니다. 추가 검사를 수행하고 일부 수명 주기 메서드를 두 번 호출하여 문제를 강조하지만 이러한 검사는 프로덕션 빌드에 영향을 주지 않습니다. 많은 개발자는 이러한 확인이 생산 성능이나 동작에 영향을 미친다고 잘못 생각합니다.

5. useEffect 및 정리 사용

useEffect 후크는 까다로울 수 있습니다. 메모리 누수를 방지하려면 정리를 적절하게(예: 비동기 작업에서) 처리하는 것이 중요합니다. 구독이나 타이머와 같은 효과 정리를 잊어버리면 의도하지 않은 동작이나 성능 문제가 발생할 수 있습니다.

6. 컨텍스트 API 성능 고려 사항

Context API는 구성 요소 트리 아래로 데이터를 전달하는 데 유용하지만 주의 깊게 사용하지 않으면 성능 문제가 발생할 수 있습니다. 컨텍스트 값을 업데이트하면 업데이트된 데이터를 사용하지 않더라도 모든 소비 구성 요소의 다시 렌더링이 트리거될 수 있습니다. React.memo를 사용하거나 컨텍스트를 더 작은 컨텍스트로 분할하면 이 문제를 완화할 수 있습니다.

7. React Fiber와 화해

React Fiber는 비동기 렌더링과 같은 기능을 지원하는 조정 알고리즘입니다. 복잡한 UI 업데이트 처리를 개선하는 새로운 내부 아키텍처를 도입했지만 대부분의 개발자가 직접적으로 걱정할 필요는 없습니다. React의 내부 구조가 진화했다는 사실을 이해하면 문제 해결 및 성능 최적화에 도움이 될 수 있습니다.

8. React의 Prop 드릴링 및 대안

프롭이 여러 구성 요소 레이어를 통과하는 프롭 드릴링은 번거로울 수 있습니다. React의 Context API가 이 문제를 완화하는 데 도움이 되지만 더 복잡한 시나리오의 경우 Redux, Zustand 또는 Recoil과 같은 다른 상태 관리 솔루션을 살펴보는 것도 좋습니다.

9. 개발 및 프로덕션 빌드

React의 개발 빌드에는 프로덕션 빌드에는 없는 추가 경고 및 검사가 포함되어 있습니다. 이렇게 하면 디버깅이 더 쉬워지지만 성능에 영향을 줄 수 있습니다. 불필요한 오버헤드를 피하기 위해 애플리케이션이 배포용 프로덕션 빌드를 사용하고 있는지 항상 확인하세요.

10. 동시 모드 및 향후 기능

React의 Concurrent 모드와 실험적 기능은 렌더링 성능과 사용자 경험을 크게 향상시킬 것을 약속합니다. 그러나 이러한 기능은 아직 실험적이며 완전히 안정화되지 않았습니다. 흥미로운 가능성을 제공하지만 주의해서 사용해야 합니다.