컴포넌트 분리를 잘하자

개인 프로젝트를 진행하다가 뭔가를 놓치고 있다는 불안감이 강하게 들었다.

중복 로직, Props Drilling, 점점 길어지는 파일...
코드는 늘어나는데 확신은 줄어드는 기묘한 상황

처음엔 상태관리 탓을 했다.
Zustand를 더 활용했어야 했나...?
useQuery에 대한 이해도가 부족해서 쓰레기 코드를 만들어버린건가...?

결국 반은 맞은 셈이다.
컴포넌트 분리가 제대로 되지 않아 모든 역할을 다 맡고있는 페이지가 생겼고,
분리를 했다면 재사용이 가능했던 로직들도 불러올 수 없으니 재작성하게되는 상황.

컴포넌트 분리 기준

이것부터 제대로 잡고 가야 프로젝트가 커져도 정신이 아프지 않다.
더 있을 수 있지만 내가 느낀 필요한 기준만 모아봤다. (반박 시 님말맞...반박할 수가 없을텐데?)

단일 책임 원칙(SRP)

컴포넌트는 한 가지 이유로만 변경되어야한다.
고로, 한 가지 책임만 져야한다.
검색창이면 검색창만, 모달이면 모달... 화면에 띄우는건 해당페이지에 조립만.
처음 진행했던 팀 프로젝트에서 컴포넌트를 거의 사혼의 구슬조각 마냥 나눴던 기억이 있다(나말고).

그때는 이해가 되지 않았다.

하지만 혼자 다 해보니 왜 그렇게 분리를 했는지... 그때 그 분이 했던
"이렇게 작성하면 하나 빠그러졌을때 고치기 힘들다"
가 너무 와닿는다. 너무 미안한 마음이다.

변경 빈도(자주 변하는 것과 변하지 않는것)

• UI 디자인은 자주 바뀐다.
• 하지만 데이터 모델/쿼리는 굴러가기만 하면 상대적으로 덜 바뀐다 - 물론, 백엔드가 변경되면 이것도 손봐야한다.

그래서 UI와 로직이 한 파일에 섞여있으면
작은 디자인 수정에도 로직 파일을 건드리게 되고 PR diff가 커진다.
그러니 그 순간부터 수정이 무서워질 수 밖에.

가독성

UI를 분리시켜놓으면, 가독성 면에서도 행복해질 수 있다.
React return문만 봐도 그렇듯이 디자인 요소가 늘어나면 화면에 div 밖에 보이지 않는 놀라운 일이 일어난다(상단에 중요한 로직들이 있는데! 하지만 분리가 되지 않았으면 거기도 이미 스파게티 코드 파티).

그러다가 잘못해서 디자인 수정을 잘못 건드려버리면

재사용성

지금 상황 기준 가장 중요하다 느끼는 부분이다.
이걸 잘 지키면

• 코드 중복 감소
• 공통 기능 컴포넌트 사용으로 효율성 증가
• 시간 및 비용 절감
• 상대적 행복코딩 가능

이지만, 적당히 나누고 적당히 갖다써야지 행코 가능하기 때문에 상대적 이라는 표현을 사용했다.

그래서 뭘 분리해야하는데

지금 프로젝트에서 내가 인지하고 분리했던 부분은

• Api
• instance(api 호출에 사용되는 중복 로직)
• Types
• 상태관리 store (ex.usePrincipalState)
• 커스텀 훅 hooks (ex.useFirebaseUpload)
• 유틸 함수 utils (ex.imageCroppedUtils)
• 스타일 styles (emotion css, styled component(*이때까지의 경험 상 계속 겹치는 디자인이라면 얘가 더 깔끔해보였음))
• 라우팅 / 네비게이션 설정 분리
• 컴포넌트 자체 분리 (어째선지 부분적으로 진행되었음)
• 각 페이지에서 공통적으로 사용될 모달, 사이드바 등(common)...

부족했던 부분은

• 페이지 별 컴포넌트 분리

예를 들면,
유저 정보 변경 제출 폼 페이지가 있다고 치자.
여기서 제출되는 부분들은

• 프로필 이미지
• 유저 이름
• 이메일 인증
• 비밀번호 변경

정도를 예를 들어보자.

유저 정보 변경 페이지는 실제로 한 페이지지만, 사용자 입장에서도 이미 영역이 나뉜다.

• 프로필 이미지 변경 섹션
• 유저 이름 변경 섹션
• 이메일 인증 섹션
• 비밀번호 변경 섹션

즉, 이 페이지는 본질적으로 여러 개의 독립 기능이 한 화면에 모여있는 형태다.
그래서 나는 페이지를 다음처럼 쪼개는 게 가장 자연스럽다고 판단했다.

1. Page는 레이아웃(조립) 만 담당

function AccountPage() {
  return (
    <div>
		<ProfileImageSection />
		<UsernameSection />
		<EmailVerifySection />
		<PasswordChangeSection />     
    </div>
  )
}

export default AccountPage

페이지는 순서대로 배치만 하고 각 섹션의 내부구현은 모른다.

• SRP 관점에서 페이지의 책임은 화면 구성 하나로 고정된다.

2. 각 섹션은 '기능 단위' 로 완결
예를 들어 비밀번호 변경 섹션은

• 입력 UI
• 검증
• 변경 mutation 호출
• 성공/실패 메시지 처리
  까지 그 섹션 안에서 끝낸다.

이렇게 하면 다른페이지에서 해당 로직이 다시 필요해져도, 섹션 컴포넌트만 그대로 쏙 가져다 쓰면 된다.
해당 예시와 같이 재사용성은 공용 컴포넌트로만 생기는 게 아니라,
기능이 완결된 섹션 컴포넌트에서도 발생한다.

그래서 나는 "모든걸 나눠" 방식의 도입은 아직 어색하다(아마도 앞으론 친해져야겠지만).

하지만 섹션 분리만 하면 끝이 아니지요

섹션을 나누면 페이지는 짧아지지만 섹션 내부가 또 길어질 수 있다.
이게 내가 겪은 문제의 본질이다.

프로필 이미지 변경같은 부분은 (파일 선택 -> 크롭 -> 업로드 -> 저장) 처럼 단계가 많아서 꼴보기 싫은 코드가 완성된다.

그래서 섹션 내부는 다시 이렇게 나뉜다.
UI 컴포넌트(Presentational)

• 입력창, 버튼, 에러 메시지 등 보여주는 것만 담당
• props로 데이터와 핸들러만 받는다

로직(컨테이너/훅)

• mutation, validation, submit 처리, 성공 후 invalidate 같은 행동 담당

결국 내가 정한 분리 기준은

• 공통 스타일
• 공통 입력 컴포넌트
• 페이지는 섹션 조립만
• 섹션은 기능 단위로 완결
• 섹션 내부는 UI/로직 분리(필요할 때만)

이렇게 했을 때 내가 부딪혔던 요소들이 줄어들었다.

• 중복 로직 = 섹션/훅으로 흡수
• props drilling = 섹션 단위로 범위 축소
• 파일 길이 = 페이지는 짧아지고, 섹션도 책임이 분명해져서 수정할때도 편함

마무리

프론트 컴포넌트 분리가 뭐가 대수냐 할 수 있지만, 프로젝트 규모가 커지고 로직이 길어지면서 초단위로 번아웃이 올 것 같았다...

백과 프론트를 번갈아가며 추가해야 할 로직이 산더미인데, 나는 아직 코드를 정확하고 효율적으로 굴리는 법을 공부하는 초기 단계다.

그래서 지금 내 상황에서 최대한 위험 비용이 적게, 로직은 줄이고 가독성은 늘리는 방법은 결국 프론트 컴포넌트를 깔끔하게 분리시키는 것이라고 생각이 들었다.

물론, 더 효율적이고 좋은 방법들은 존재할거지만 그건 앞으로 부딪혀보면서 배우면 개선되리라 믿는다! 아자아자 화이팅~