간략하게 Lessons Learned만 일단 정리하여 공유합니다.
Lessons Learned
도메인으로 포함되는 로직 감싸기
Q. query 관련 로직을 컴포넌트 내부에 배치할까, 외부에 배치할까?
다음은 예약 현황 페이지에서 내 현황 영역 컴포넌트를 렌더링하는 부분만 짧게 가져온 code snippet이다.
export funciton ReservationStatusPage() {
const { data: myReservationList = [] } = useMyReservations();
...
<MyReservationSection myReservationList={myReservationList} getRoomName={getRoomName} onCancel={handleCancel} />
}
useMyReservations(query 관련 로직)을 부모에 정의할까, 아니면 컴포넌트 내부에 정의할까 고민을 많이했는데 중요한 고민이 아닌 거 같아 컴포넌트 밖에서 정의했다.
A. 도메인을 이름에 나타냈으면 안에서 도메인 로직을 책임지게 만들자.
MyReservationSection이라는 이름이 붙은 순간 이 컴포넌트는 특정 도메인의 로직을 처리하는 컴포넌트라는 맥락을 가지므로, query data를 굳이 외부에서 줄 필요 없이 내부에서 정의하는 게 추상화 레벨에 맞는 거 같다.
네임스페이스 패턴 과다사용 경계하기
- 같은 name에 묶여서 내부 구현을 숨겨버리는 효과가 발생한다. 따라서 개발자가 구현이 알고 싶으면 직접 구현을 찾아들어가게 만들텐데, 이럴 필요가 있는지 다시 한번 생각해 볼 필요가 있다.
예)
<TimeSelect>
<TimeSelect.Title>선택 가능 시간<TimeSelect.Title>
<TimeSelect.Option>10:00<TimeSelect.Title>
<TimeSelect.Option>10:30<TimeSelect.Title>
<TimeSelect.Option>10:30<TimeSelect.Title>
</TimeSelect>
문제점:
- HTML Native element 'select'의 컨벤션을 따르고 있지 않아 예측하기가 어렵다.
- TimeSelect namespace에 어떤 컴폰넌트가 있는지 알고 싶다면 AI던 개발자던 결국 소스코드를 탐색해서 들어가야 한다. Title 컴포넌트가 숨겨져 있어서 존재 자체를 알기 어려워 다른 개발자들은
TimeSelect.Title을 사용하지 않고 직접 구현하게 되는 일까지 벌어질 수 있다. 이러면 유지보수하기 더욱 힘들어질 것이다.
여전히 의문인 점
리팩토링 단계 설계하기
- 재엽님이 코드를 고치신 방식: 인터페이스를 먼저 설계하신 다음에 LLM에게 인터페이스대로 리팩토링해달라고 지시함.
- 문제점: 프로덕션 코드 같은 경우 그렇게 수정하면 그렇게 변경점이 많아져 리뷰어가 리뷰하기가 힘들 거다. 따라서 레거시 코드의 리팩토링을 단계별로 진행해야 할텐데 어떤 식으로 단계별로 쪼개야 할까?
P.999 onChange 대신에 onValueChange는 어떠한가?
- Native HTML의 인터페이스를 그대로 웬만해서 가져오는 게 예측하기 쉽다고 말씀하셨고, 이에는 전반적으로 동의한다.
- 그런데 onChange 같은 경우에는 event를 인자로 전달해주는 함수라는 느낌이 든다. 따라서 value를 전달하는 함수라는 것을 명확히 해주기 위해 onValueChange라는 이름으로 핸들러 인터페이스를 구성하는 것은 어떤가?
- 레퍼런스: Radix-Primitive의 `onValueChange' 함수 인터페이스(https://www.radix-ui.com/primitives/docs/components/tabs)
Top comments (0)