배포 링크 (심화)

https://dev4n4.github.io/front_6th_chapter2-2/

과제의 핵심취지

• React의 hook 이해하기
• 함수형 프로그래밍에 대한 이해
• 액션과 순수함수의 분리

과제에서 꼭 알아가길 바라는 점

• 엔티티를 다루는 상태와 그렇지 않은 상태 - cart, isCartFull vs isShowPopup
• 엔티티를 다루는 컴포넌트와 훅 - CartItemView, useCart(), useProduct()
• 엔티티를 다루지 않는 컴포넌트와 훅 - Button, useRoute, useEvent 등
• 엔티티를 다루는 함수와 그렇지 않은 함수 - calculateCartTotal(cart) vs capaitalize(str)

기본과제

• Component에서 비즈니스 로직을 분리하기

• 비즈니스 로직에서 특정 엔티티만 다루는 계산을 분리하기

• 뷰데이터와 엔티티데이터의 분리에 대한 이해

• entities -> features -> UI 계층에 대한 이해

• Component에서 사용되는 Data가 아닌 로직들은 hook으로 옮겨졌나요?

• 주어진 hook의 책임에 맞도록 코드가 분리가 되었나요?

• 계산함수는 순수함수로 작성이 되었나요?

• Component에서 사용되는 Data가 아닌 로직들은 hook으로 옮겨졌나요?

• 주어진 hook의 책임에 맞도록 코드가 분리가 되었나요?

• 계산함수는 순수함수로 작성이 되었나요?

• 특정 Entitiy만 다루는 함수는 분리되어 있나요?

• 특정 Entitiy만 다루는 Component와 UI를 다루는 Component는 분리되어 있나요?

• 데이터 흐름에 맞는 계층구조를 이루고 의존성이 맞게 작성이 되었나요?

심화과제

• 재사용 가능한 Custom UI 컴포넌트를 만들어 보기

• 재사용 가능한 Custom 라이브러리 Hook을 만들어 보기

• 재사용 가능한 Custom 유틸 함수를 만들어 보기

• 그래서 엔티티와는 어떤 다른 계층적 특징을 가지는지 이해하기

• UI 컴포넌트 계층과 엔티티 컴포넌트의 계층의 성격이 다르다는 것을 이해하고 적용했는가?

• 엔티티 Hook과 라이브러리 훅과의 계층의 성격이 다르다는 것을 이해하고 적용했는가?

• 엔티티 순수함수와 유틸리티 함수의 계층의 성격이 다르다는 것을 이해하고 적용했는가?

과제 셀프회고

음... 처음에는 그냥 거대 컴포넌트를 자잘하게 나누고 분리하는 거라고 생각했어서 그리 어렵지 않겠거니 생각했었는데 역시나 이번에도 생각보다 까다로웠다. 여러가지 엔티티의 코드들이 한곳에 뭉쳐있고 함수도 많고 UI도 많고 해서 분리하면서도 너무 헷갈려 했던 기억이 난다... UI를 쪼개면서도 이렇게 쪼개는 게 맞는지 잘 모르겠고 더 쪼개야 하나? 지금 여기서 멈춰야 하나? 고민하다가 내가 보기에 잘 읽히는 기준(비슷한 특성의 UI끼리 모음..)으로 쪼갠 것 같은데 왠지 더 좋게 만드는 법이 있을 것 같다... 나는 너무 파편화된 UI 컴포넌트를 싫어해서(개인적으루 오히려 타고타고 들어가면서 더 읽기 힘들어진다고 생각합니다..) 내 눈에는 지금이 제일 읽기 편한 것 같긴 한데... 아닐수도,,,

그리고 전 회사를 다닐 때 맨날 useState, useEffect 만 가져다 썼었고 custom hook은 많이 안써봐서 이번에 custom hook으로 분리하는 게 좀 걱정이 되었었는데 생각보다 별거 아니었으면서 별거였다.

아 뭐야! 그냥 한 엔티티와 관련된 useState, useEffect랑 그걸 가져다 쓰는 함수들을 한 데 모아둔거잖아!

...로 정리가 됐는데 그걸 여러 컴포넌트에서 import 해서 쓰는건 좀 신세계였다. 뭔가 리액트를 헛쓰고 있었다는 생각이 들었고... 전 회사에서 내가 남긴.. hook으로 분리되지 않은 코드들이 생각이 났고 좀 부끄러워졌다!

그리고 Jotai도 이번에 처음 사용해봐서 좀 걱정했는데 생각보다 간단해서 다행이었고 Jotai로 props drilling을 정리하니까 너무 행복했다... 진짜 이렇게까지 깔끔해진다고! 싶었다. 완전 재밌었다. 그 수많은 props들이 사라지는 것 만으로도 컴포넌트의 이름이 더 잘 보여서 아 여기로 들어가면 ~~가 나오겠구나~ 하고 흐름이 잘 읽혀서 좋았다. 사실 이전까지 나한테 전역 상태관리 라이브러리는 그냥 막연히 뭔가... 일단 플젝 시작하면 하나 선택해서 깔아서 써야 하는 것? 또 다른 공부할 라이브러리? 그런 느낌이었고 그래서 어떤게 props drilling의 기준이 되는지도 잘 와닿지 않고 애매해서 전역상태를 쓸 때마다 아.. 진짜 지금 써두 되나 하고 고민하구 그랬었는데 (최대 몇 depth까지가 drilling인지 지피티한테 물어보고 그랬던 것 같다.) 이번에 전역 상태관리가 필요할 때 도입해서 사용해보고 코드가 확실히 깔끔해진 것을 경험해봐서 좋았다.

어디서 전역 상태를 남발하면 안좋다는 말을 줏어들었었어서 그냥 막연히 아 지금이 필요할때인가...아닌가... 그러던 과거에서는 벗어난 것 같구 이제는 전역 상태를 사용해서 코드가 이전보다 깔끔해지고 간결해질 것 같으면 사용할 것 같다.

과제를 하면서 내가 제일 신경 쓴 부분은 무엇인가요?

models와 hooks의 관계성을 몰라서 찾아보고 적용을 했었고

models = 순수 비즈니스 로직 담당 hooks = 상태 관리 및 side-effect 담당 hooks에서 models에 선언해 둔 함수들을 가져다 쓴다.

그 과정에서 models에 들어가는 함수들을 순수함수로 바꾸기 위해 고민하고 적용하였다. 처음에 이걸 어떻게 순수함수로 바꾸나... 하고 막막해서 고민을 좀 했었다. 결국 대체로 받은 인자를 조건에 따라 일정한 객체 형태로 return 하고 그걸 hooks에서 가져다 쓰는 형태로 만들었다. 근데 그렇게만 해도 코드가 어느정도 패턴화 되면서 뭔가 깔끔해진 것 같다는 느낌이 들었다.

그리고 과제를 하면서 컴파운드 패턴을 공부했으니까 한번 써보고 싶었고 쓸만한 상황이 올까? 생각하면서 작업을 했었는대 하다보니 Layout 쪽에는 써도 괜찮지 않을까 해서 써봤다. 뭔가 비슷한 컴포넌트끼리 묶인 느낌이 들어서 좋았다! 아 이건 Layout 컴포넌트구나 하고 프리픽스 처럼 붙어서 알게 되니까 좋다고 생각했다.

Icon들도 비슷한 성질의 컴포넌트인데 약간 <Icon.Close> 이런 느낌의 컴파운드 패턴으로 해도 괜찮지 않나? 생각도 했었다. 근데 컴파운드 패턴으로 구현하면 이 컴포넌트를 사용할 때 전체가 Import 되니까 Icon에는 부적절하겠거니 싶었다. Icon 같은것은 전체 중에서 보통 몇개만 필요로 하니까 그냥 배럴 패턴이 나을 것 같다는 생각이 들어 적용하지 않았다.

과제를 다시 해보면 더 잘 할 수 있었겠다 아쉬운 점이 있다면 무엇인가요?

몇몇 분들께서 fsd를 공부해서 그 구조를 적용시켰다고 하셨다는 것을 듣고 나도 그렇게 했으면 좋았을 걸 싶었다. fsd 패턴도 한번도 안써봤어서.. ㅠㅠ 이번 기회에 이것도 공부하고 적용시켰으면 좋았을텐데 아쉽다.

리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문 편하게 남겨주세요 :)

대체로 테오 코치님께서 초기에 제공해 주신 힌트를 보고 그것 기반으로 분리를 진행했는데요. 지금 컴포넌트들의 크기들이 적절히 잘 쪼개진 것인지 아니면 더 작은 단위로 분리할 필요성이 있을지 궁금합니다. (개인적으로 컴포넌트를 잘게 쪼개는 것을 별로 안좋아하는데.. 아집일까요... 왜 저는 너무 쪼개면 오히려 가독성이 안좋아질 것 같죠...ㅠㅠ 제가 혹시 지금 너무 큰 단위들로 잘라놨나요? ㅠㅠ 아집이면 팩폭 부탁드립니다...)