토스 SLASH 22 - Effective Component 지속 가능한 성장과 컴포넌트
변경에 유연하게 대응하는 컴포넌트를 만드는 것의 필요성
- 서비스의 수많은 변경 필수적이고 그것이 성장한다는 증거
- 변경은 미리 알 수 없고 그렇기에 변경에 대응해서 개발해야한다.
컴포넌트의 3가지 역할
- 외부 주입 데이터 + 내부 데이터(상태)를 관리함
- 그 데이터가 사용자에게 어떻게 보여질지 정의함 (ui)
- ui를 기반으로 어떻게 사용자와 상호작용할지를 정의함
1. Headless UI 기반의 추상화하기
- 데이터와 ui분리하기
- 컴포넌트에서 중요한 것들이 빠지고 ui만 남아있다는 의미인듯?
- 데이터+상호작용만 집중해서 모듈화 (hook으로)
- 컴포넌트의 ui는 데이터나 로직을 전달받기만 할 뿐
- 변경에 유연해지려면 각 모듈이 한 가지 일만 하는게 중요하기 때문
2. 한 가지 역할만 하기
또는 한 가지 역할만 하는 컴포넌트의 조합으로 구성하기
- 합성 가능하도록 컴포넌트 설계하는 것
- 컴파운트 컴포넌트 패턴
- ui(컴포넌트)를 세세한 기능으로 분리해서 관리하는 것.
- 하나의 거대한 부모 컴포넌트에 모든 props를 집어넣고 하위 UI 컴포넌트로 향해 내려가는 대신, 각 prop이 가장 적합한 SubComponent에 연결되도록 하는 것.
- 컴포넌트끼리의 연관성을 최대한 배제
3. 도메인 분리하기
데이터를 주입받는 컴포넌트 vs 데이터를 스스로 가져오는 컴포넌트 분리하기
- 일반적인 인터페이스로 분리하기 → 도메인 맥락을 제거하면 일반적인 기능이 됨
- 데이터를 가져오는 컴포넌트 내부에 그 데이터를 받아서 사용하는 컴포넌트를 포함시키는 것.
- 필요한 데이터를 직접 관리할 때 자율적인 컴포넌트가 되고 외부 의존성 없이 재사용하기 좋다.
바로 시도해볼 수 있는 ActionItem
1. 인터페이스를 먼저 고민해보기
- 컴포넌트를 구현하기 전에 어떻게 사용할지를 먼저 기획하는 것.
- 변경해야할 때를 고려해서 정의할 수 있다.
2. 컴포넌트를 나누기 전에 나누는 이유에 대해 다시 생각해보기
- 복잡도를 낮추기 위한 것인지
- 재사용을 위한 것인지
- 꼭 분리해야하는 지
평소에 컴포넌트의 재사용에 대해서 고민을 많이 했는데, 의문점들을 많이 해소할 수 있었다.
도메인 분리하기 부분은 내가 몬썹 리팩토링 할 때 컴포넌트 재사용을 어떻게 할지 고민하다가 적용한 방법인데 그게 맞는 방법이어서 뿌듯하기도했다..
아직 명확히 이해가 안가는 부분은 한 가지 역할만 하는 컴포넌트의 조합으로 구성하기인데 요즘 많이 사용하는 컴파운트 컴포넌트 패턴이라고 한다. 깊게 공부해보고 따라해보면서 익혀야겠다.
공부할 자료들
#프론트엔드