과제 배포 링크
advanced - esoby.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는 분리되어 있나요?
-
데이터 흐름에 맞는 계층구조를 이루고 의존성이 맞게 작성이 되었나요?
심화과제
-
이번 심화과제는 Context나 Jotai를 사용해서 Props drilling을 없애는 것입니다.
-
어떤 props는 남겨야 하는지, 어떤 props는 제거해야 하는지에 대한 기준을 세워보세요.
-
Context나 Jotai를 사용하여 상태를 관리하는 방법을 익히고, 이를 통해 컴포넌트 간의 데이터 전달을 효율적으로 처리할 수 있습니다.
-
Context나 Jotai를 사용해서 전역상태관리를 구축했나요?
-
전역상태관리를 통해 domain custom hook을 적절하게 리팩토링 했나요?
-
도메인 컴포넌트에 도메인 props는 남기고 props drilling을 유발하는 불필요한 props는 잘 제거했나요?
-
전체적으로 분리와 재조립이 더 수월해진 결합도가 낮아진 코드가 되었나요?
과제 셀프회고
과제를 하면서 내가 알게된 점, 좋았던 점은 무엇인가요?
-
팀원들과 엔티티와 ui에 대해 이해해본 걸 공유하는 시간을 가지면서 과제를 시작했는데요. 덕분에 프로그래밍에서 엔티티에 대한 개념이 명확해졌고, 나름 덜 헤매면서 과제를 할 수 있었습니다! 좋은 토론 시간이었어요
-
뚜렷한 기준 안에서 로직을 분리해보는 경험은 처음이라 너무 좋았습니다. 이번 과제는 아쉽게 마무리 했지만, 나중이라도 다시 들여다보고 더 배워가고 싶은 과제로 느껴졌습니다.
-
전역 상태 관리로 jotai 도입을 도전하게 되었는데요. 리코일스러움을 느꼈어요. 컨텍스트보다 직관적이고 사용 방식이 간단한 것 같아서 좋았습니다.
-
프로바이더를 잊지 말자 .. jotai는 프로바이더가 필요없는 것 같아서 따로 세팅을 안 해두었는데 테스트 환경에서는 필요했나 봅니다. 셀프 e2e 테스트 해보면 잘 돌아가는데, 단위 테스트는 자꾸 실패해서 거의 포기하고 있었던 차에 ,, 따수운 항해 분들의 도움 덕분에 해결했습니다 헤헤헤헤헤 라이브러리 사용하면서 막연하게 사용법만 익히기 보단 전역 상태가 어떻게 관리되는지, 컴포넌트들이 어떻게 접근할 수 있는 건지 디테일하게 생각해보아야 할 것 같습니다.
-
밤새지 말자 .................. 비효율적이다.
이번 과제에서 내가 제일 신경 쓴 부분은 무엇인가요?
- 테스트 코드가 깨지지 않는 선에서 한 단계씩 점진적으로 개선해보자! 는 마인드로 임했습니다. 뚜렷한 상태 관련 로직을 도메인별로 커스텀 훅으로 분리하고 -> 순수 비즈니스 로직을 모델로 덜어내고 -> 반복 되는 계산 함수를 빼는 식으로 진행했습니다.
이번 과제를 통해 앞으로 해보고 싶은게 있다면 알려주세요!
-
로직에 신경 쓰느라 컴포넌트 분리를 촘촘하게 못 한 점과 재사용되는 코드 활용을 많이 못 한 점이 아쉬워서 이 구조 그대로 좀 더 고민해보는 시간을 꼬옥 가져보려고 합니다!
-
또 이번 과제로 리팩토링과 코드 분리의 기준에 대한 방향성이 많이 잡힌 것 같아 실무에서도 그걸 잘 활용해보고 싶어요!
리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문 편하게 남겨주세요 :)
-
useProducts 훅이 addNotification 함수를 props처럼 주입 받는 방식과 훅 내부에서 직접 useSetAtom(addNotificationAtom)을 호출하는 방식과 고민하다가 매번 의존성을 주입해주는 게 번거로워서 후자로 선택했는데, 어떤 방식이 더 좋은 설계라고 생각하실까요? 혹은 아예 독립적으로 분리가 되어야 하는 부분이었는지 궁금합니다.
-
Atom을 products, cart, ui 등 도메인별로 분리했는데, 어느 정도까지 분리하는 것이 적절한지에 대한 기준이 궁금합니다. 예를 들어, 관리자 페이지에서만 사용하는 폼 관련 상태(productForm, showProductForm 등)도 모두 Atom으로 만드는 것이 좋을까요, 아니면 지금처럼 해당 로직을 가진 훅 안에서 useState로 관리하는 것이 더 나은 선택일까요? 전역 상태와 지역 상태를 구분하는 명확한 기준에 대한 조언을 구하고 싶습니다.
과제 피드백
고생하셨습니다 소희님 ㅎㅎ 밤새서 진행하셨나봐요 ㅠㅠ 전반적으로 과제의 목표대로 잘 작성해주셨네요! 회고에 남겨주신 것 처럼 테스트 코드가 깨지지 않는 선에서 한단계씩 차근차근 나아가는게 리팩토링의 핵심인 것 같아요. 그 관점에 맞춰서 잘 진행해주셨던 것 같습니다 ㅎㅎ 그리고 리팩토링은 점진적으로 진행이 되어야 하고 아쉬운점에서 말씀해주신것처럼 채로 거르는것 같이 여러번 과정을 거치면서 나아가야 하는 것 같아요. 그 개선 시점에는 개선에 대한 관점만 가지고 개선하는걸로요. 잘 하셨고 여유가 있으실 때 꼭 아쉬우셨던 점 하시면 좋겠네요 ㅎㅎ
질문 답변 드려보면요.
useProducts 훅이 addNotification 함수를 props처럼 주입 받는 방식과구현했습니다.
제 개인적으로는 후자가 더 좋은 선택인 것 같아요. jotai 철학상으로도 필요한 곳에서 필요한 아톰을 호출하는 형태로 구현하기 위해 특화된 훅이나 접근 방식을 제공했던 것으로 알려져있는데요. useProducts가 매우 범용적이게 사용할 수 있고 주입받는 noti에 대한 아톰이 다양한 형태의 타입인 noti라면 주입받는게 적절할 것 같아요. 만약 여러 타입인 경우에는 이렇게 분리를 하게 되면 테스트에 대한 용이성도 생기고 인터페이스를 통일 시키는 중간 계층도 하나 생겨서 확장성도 좋아질 거구요. 근데 지금은 그런 케이스는 아니지 않을까..! 싶습니다.
Atom을 products, cart, ui 등 도메인별로 분리했는데, 어느 정도까지 분리하는 것이 적절한지에 대한 기준이 궁금합니다.
지금도 잘 정리해주셨어요. 다만 폼 상태나 이런것들은 지역상태로 유지하면서 컴포넌트를 시작하지만, 너무 엄격하게 해당 훅이나 컴포넌트 로컬에서 상태를 관리하려고 강조하기보다는 여러 컴포넌트에서 사용해서 드릴링이 발생하는 경우 또는 폼에 대한 특별관리가 필요하거나.. 편의성 관점에서 고민해봐도 될 것 같아요! 사실 리덕스를 쓰던 과거에는 이런것들을 분리하는것 자체가 비용이였는데 지금은 써보신것처럼 구성을 하고 관리하는 것 자체가 어렵진 않으니까요.
고생하셨고 다음주도 화이팅입니다~~