1. Prop Drilling
Q
prop이 부모에서 자식 컴포넌트로 전달될 때 여러개의 중간 컴포넌트를 거쳐서 전달하게 되는 현상
A
Context API로 해결
2. 컴포넌트 내 데이터 변환
Q
외부 API나 백엔드에서 받은 데이터가 프런트엔드에 적합하지 않은 형태인 경우 컴포넌트 내부에서 복잡한 데이터 변환 로직을 직접 작성
- 명확하지 않음: 데이터 가져오기와 변환, 렌더링 작업이 하나의 컴포넌트 안에서 이루어지므로 이 컴포넌트가 어떤 역할을 하는지 알기 어려움
- 재사용성이 떨어짐: 다른 컴포넌트에서 유사한 변환이 필요한 경우, 로직의 중복 발생
- 테스트하기 어려움: 테스트를 하려면 변환 로직을 고려해야 하므로 테스트 코드가 더 복잡해짐
A
유틸리티 함수나 Custom hook을 이용하여 보다 명확하고 모듈화된 구조로 바꿔야함 컴포넌트는 렌더링과 비즈니스 로직에 집중
3. 뷰 영역의 복잡한 로직
Q
설계상 컴포넌트는 비즈니스 로직을 신경쓰지 않고 프레젠테이션에 집중 해야함. 뷰 컴포넌트 안에서 비즈니스 로직을 다루는 경우 깔끔한 관심사 분리를 방해할 뿐만 아니라 컴포넌트가 크고 복잡해져 테스트와 재사용을 어렵게함.
- 재사용성: 다른 컴포넌트에서 유사한 필터가 필요한 경우. 로직이 중복됨
- 테스팅: 렌더링 뿐만 아니라 비즈니스 로직도 테스트해야 하므로 단위 테스트가 복잡해짐
- 유지보수성: 애플리케이션이 커지면서 더 많은 로직이 추가되기 때문에 유지보수하기 어려워짐
A
각각의 모듈 또는 함수가 애플리케이션의 하나의 기능에 대한 책임을 가짐. 계층화된 아키텍쳐를 통해 비즈니스 로직과 프레젠테이션 계층을 분리하여 모듈화되고 관리하기 쉬운 코드베이스를 구축
4. 테스트 부족
Q
사용자가 발견하기 전까지 오류 확인 못함
A
테스트 주도 개발 (TDD) 로 테스트 코드를 먼저 작성하고, 실제 컴포넌트 로직을 나중에 작성
5. 중복된 코드
Q
유지보수, 가독성, 재사용성
A
모든 정보를 하나의 출처에서만 공급 데이터 요소를 한곳에서만 업데이트 하고 참조하는 모든 요소에 전파
6. 너무 많은 기능을 가진 컴포넌트
Q
하나의 구성 요소가 하나의 기능만을 수행해야 한다는 단일 책임 원칙에 위배
A
핵심 기능을 분석하고 부가적인 지원 로직들을 더 작고 집중된 컴포넌트나 hook 으로 분리
7. 안티패턴을 없애기 위한 접근 방식
Q
널리 퍼져있는 안티패턴 해결
A
render prop, 고차 컴포넌트, hook 과 같은 기술을 활용 계층화된 아키텍쳐, 관심사의 분리처럼 뻐대가 되는 패턴을 활용하면 로직과 데이터, 프레젠테이션을 일관된 방식으로 나누어 코드베이스를 간소화 할 수 있다.
인터페이스 지향 프로그래밍 인터페이스를 통해 소프트웨어 모듈 간에 발생하는 상호작용을 중심으로 소프트웨어를 구성하는데 중점 소프트웨어 모듈을 쉽게 변경하면서 일관성 유지
헤드리스 컴포넌트 패러다임 직접적인 렌더링 역할은 없지만 상태 또는 로직을 관리하는 컴포넌트를 구현. 사용하는 컴포넌트에 UI 렌더링 넘김 재사용 편리