변경에 유연
- Headless 기반의 추상화
- 한가지 역할만 하기
- 도메인 분리하기
컴포넌트는 무엇을 할까?
데이터 관리 : 외부에서 들어오는 데이터, 상태 같은 내부 데이터를 관리
UI : 그 데이터를 어떻게 보여질지를 정의
유저와 상호작용
Headless 기반의 추상화
데이터 추상화
디자인에 의존하는 UI를 컴포넌트가 관리하는 '데이터'와 분리해보자
내가 제작한 로그인 페이지를 예로 살펴보자
데이터와 UI를 분리해보자
로그인 정보에 필요한 데이터를 추상화해서 useLogin라는 hook으로 표현해줌
이제 이 Login이라는 컴포넌트에서는 컴포넌트에서는 hook에서 반환된 값을 어떻게 보여질지만 정의하면됨
로그인 정보를 관리하는 창 혹은 로그인 관련된 정보를 보여줘야 하는 창에서는 이 useLogin hook을 가져다 사용 할 수 있음.
지금 이렇게 한 작업은 ui를 관심사에서 제거한 작업임. => Headless
오로지 데이터에만 집중해서 모듈화를 진행. 한가지 문제에만 집중하기 때문에 더 많은 곳에서 사용할 수 있고, 다른 변경으로부터 격리시킬 수 있음.
동작 추상화
로그인, 회원가입, 주문페이지 등등 쇼핑몰 프로젝트 내부 다양한 페이지에서 input창의 쓰이고 그럴때마다 input에 관련된 동일한 동작들에 대한 코드가 반복됨 => 컴포넌트 내부에 여러가지 로직이 들어가게 되고 결국 복잡해짐
데이터 부분을 추상화했던 것처럼 상호작용 부분을 추상화
: 메모이제이션을 활용해 input을 추상화
한가지 역할만 하기
변경에 유연해지려면 각 컴포넌트들이 한가지 역할만 하는게 중요함.
결국 같은 UI 내부에 있어도 각 컴포넌트들은 기능별로, 데이터별로 분리되어 있어야 하고, 그에 따라 서로의 역할을 몰라야함.
그래야 변경에 유연하게 컴포넌트를 제작할 수 있음.
도메인 분리하기
모든 컴포넌트에서 데이터로 접근할 수 있지만, 컴포넌트를 주입 받듯 데이터를 주입 받자 -> 도메인을 분리
이해하기 쉽게 설명을 해보자면, 컴포넌트에서 도메인에 해당하는 정보들을 걷어내는거임.
A 컴포넌트와B 컴포넌트는 각각 다른 데이터를 통해 비슷한 UI를 보여준다고 가정해보자. 만약A 컴포넌트제작 시,A 컴포넌트의 데이터들에 국한되게 컴포넌트들을 네이밍한다면, 그대로B 컴포넌트에 해당 컴포넌트를 재사용하기는 어려워질 것이다.정리하자면, 컴포넌트에서 도메인에 해당하는 정보, 즉 데이터에 관련된 정보를 걷어내서 네이밍을 일반적으로 함으로써 여러 페이지에서 재사용이 가능해지는 것이다.
-
컴포넌트 인터페이스는 일반적일수록 이해하기 쉬움
-
사람은 배경지식으로 무언가를 해석함
=> 최대한 일반적인 단어로 표현해야 의도를 드러내기 쉽다.
실제 프로젝트를 하면서도 네이밍을 일반적이지 않게 했다가, 나중에 비슷한 UI를 제작하고 해당 인터페이스를 가져다 사용하려고 할때, 네이밍을 다시 일반적이게 수정한 경험이 수두룩하다.
결국 표준에 가까울수록 많은 사람들이 쉽게 이해할 수 있음.
구현해야하는 기능이 이미 있듯이 작성하고, 그것을 사용하듯이 개발해라
🫠
