presentational and container 패턴이란 무엇인가
1주차를 기억해 보자…
우리는 맨 처음에 Presentational and Container 패턴을 이용해서 짰다.
그 결과 page 컴포넌트와 template 컴포넌트가 분리되었고
재한이의 말에 따라 business logic을 page 컴포넌트에(Container 컴포넌트에 해당), view를 template 컴포넌트에(Presentational 컴포넌트에 해당) 분리하였다.
야심차게 짠 구조이지만 이는 유지보수가 너무 어렵고 한 컴포넌트에 상태가 너무 몰려 있어 알아보기 힘들다는 크롱님과 나의 피드백을 받아 단 첫 주만에 갈아 엎어졌다…
우선 해당 패턴에 대한 설명은 위 링크에 잘 나와 있으니 링크를 타고 들어가서 읽어보기를 권장한다
❓유지보수가 어려웠던 이유
❗props drilling 문제
컴포넌트의 depth가 불필요하게 너무 깊었음. 예를 들어 옵션 카드의 경우
옵션 페이지(여기에 옵션 카드리스트의 인덱스와 같은 state를 선언) → 옵션 카드리스트 → 옵션 카드 → styled component
정도면 되는데 기존의 구조를 따르면
옵션 페이지(여기에 state가 있음) → 옵션 템플릿(???) → 이하 동일
과 같은 구조여서 템플릿이라는 불필요한 단계가 한 단계가 더 추가되고, 이 템플릿이 page에 있는 state를 그대~로 props를 통해 옮겨주게 됨. 그런데 잘 생각해보면 이 때문에 page가 너무 많은 state를 가지게 되고(page를 제외한 모든 컴포넌트를 view, 그러니까 Presentational 컴포넌트로 분리한 것. 이는 명백한 설계 미스.) 템플릿 컴포넌트의 props가 너무너무 많아졌다.
뿐만 아니라 TypeScript이기 때문에 이 props의 개수만큼 interface도 그만큼 길어지는데 당시에 백엔드에서 API 명세조차 나오지 않은 상황이었기 때문에 변수명과 type을 예측해서 개발할 수밖에 없었고 이는 단 하나의 props를 바꾸더라도 중간에 수많은 변수들을 모두 건드려야 해서 유지보수 시간이 말도 안되게 길어졌다.
첫 주차에 리팩토링을 해서 다행이지 실제로 그 이후에 백엔드에서 API를 줬을 때 구조가 예상했던 것과 생각보다 많이 달랐기 때문에 만약 이전 구조 그대로 API에 맞춰 수정해야 했다면… 상상만 해도 끔찍하다.
따라서, 팀원들과 원만한 합의 끝에 비즈니스 로직과 뷰를 같은 컴포넌트에 선언하는 현대의 방식을 쓰기로 했다.