해당 포스팅에서는 5개의 다른 패턴을 살펴봅니다.
Counter 예제를 통한 실제 코드 예시 그리고 각 패턴의 장단점과 두 개의 기준
을 통한 비교, 마지막으로 패턴을 사용해 배포한 라이브러리의 예시 순 입니다.
<aside> 💡 두 개의 기준
Inversion of Control(IoC)
컴포넌트를 사용하는 개발자에게 주어지는 유연성(flexibility)과 제어(control)의 정도
Implementation complexity
사용하는 개발자와 만든 개발자 모두에 대해 그 패턴을 사용하는 난이도
</aside>
이 패턴은 불필요한 prop drilling 없이 Expressive(표현적 풍부한) 하고 Declarative(선언적)한 컴포넌트를 만들 수 있게 도와줍니다. 만약 좀 더 customizable(사용자 정의화) 하고 관심사를 분리하도록 하고 싶다면 이 패턴을 다시 고려해보아야 합니다.
이 패턴은 컴포넌트를 controlled component
로 바꿔준다. 외부 상태는 single source of truth(SSOT
)로 사용되어 유저(사용 개발자)로 하여금 커스텀 로직을 삽입할 수 있게끔 한다.
좀 더 IoC에 집중해보자. 메인 로직은 이제 custom hook으로 들어간다.
hook은 State, Handler와 같은 내부 로직들을 포함하며 유저(사용 개발자)에게 더 많은 통제권을 준다.
*Custom Hook Pattern
이 엄청난 통제권을 주긴 하지만, 그만큼 컴포넌트를 이용하기 어렵게 만든다. Props Getters Pattern
은 이런 복잡도를 감싸기 위해 시도한다.*