[6팀 김현우] Chapter3-2. 디자인 패턴과 함수형 프로그래밍 그리고 상태 관리 설계

[lecto17]

배포링크

https://lecto17.github.io/front_7th_chapter3-2/index.advanced.html

과제의 핵심취지

• 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는 잘 제거했나요?

• 전체적으로 분리와 재조립이 더 수월해진 결합도가 낮아진 코드가 되었나요?

과제 셀프회고

과제를 하면서 내가 알게된 점, 좋았던 점은 무엇인가요?

알게된점

React의 추구미

• 'React가 추구미'가 무엇일까 고민할 때 React로 사고하기 아티클을 읽어보며 컴포넌트 설계 단계에서 어떤 컴포넌트들로 구성할지, 컴포넌트 분리는 어떤 기준으로 할 지에 대해 정리할 수 있었다.

  • 컴포넌트를 설계할 때 1)어떤 컴포넌트들로 구성이 될지, 2)이 컴포넌트들의 계층 구조가 어떻게 될지를 정리
    • 컴포넌트를 설계한다고 할 때 어떤 것들을 고민해야하는지 다시금 짚어볼 수 있었다.
  • JSON(정의된 데이터)이 잘 구조화 되어있다면, 종종 이것이 UI의 컴포넌트 구조가 자연스럽게 데이터 모델에 대응된다는 것을 발견할 수 있습니다. 이는 UI와 데이터 모델은 보통 같은 정보 아키텍처, 즉 같은 구조를 가지기 때문입니다. UI를 컴포넌트로 분리하고, 각 컴포넌트가 데이터 모델에 매칭될 수 있도록 하세요.
    • 위 내용을 보며 근본적으로 컴포넌트를 잘 나누기 위해선 데이터 모델이 잘 설계되는 것이 필요함을 느꼈다. 그래서 FE 개발자는 단순히 데이터를 화면에 그리는 역할이 아닌, BE 개발자, 기획자와 소통하며 데이터를 설계하는데 같이 동참할 필요가 있음을 생각해보게 되었다.
  • 결론적으로 리액트가 추구하는 것은
    • '데이터'를 단방향(위 -> 아래)으로 흐르게 하는 것
    • 컴포넌트는 입력값을 받으면 화면을 나타내는 역할로 국한시켜 이외의 네트워크 요청, 전역 변수 수정 등의 작업을 렌더링 과정에서 하지 않는 것을 추구하는 것
    • 결국 순수함수(계산의 형태)처럼 컴포넌트를 작성하는 것을 리액트에서 추구하는 것을 알 수 있었다.
      zustand의 store, slice 결정 근거

• 이번 과제를 하면서, zustand를 사용할 때 store를 나눌지, 하나의 store 안에서 slice로 나눌지에 대한 나름의 기준을 정리해볼 수 있었다.

• 별도 store로 분리한 경우

  • 다른 기능과 상태 공유 필요성이 거의 없고, 도메인 자체가 독립적인 경우
    • 예: 인증, 테마/레이아웃, 토스트 등 UI 유틸성 상태
  • SSR / persist 전략이 다르거나, 특정 상태만 로컬스토리지에 저장해야 하는 경우
  • 변경 시 다른 도메인에 불필요한 리렌더를 일으키지 않도록, 렌더링 영향 범위를 줄이는 것이 중요한 경우

• 하나의 store 내부 slice로 분리한 경우

  • 하나의 도메인 내에서 상태들이 서로 긴밀하게 엮여 있고, 함께 변경/조회되는 경우
    • 예: 상품·장바구니·주문처럼 비즈니스 플로우상 강하게 연결된 상태
  • 파일/코드를 기능 단위로 나누되, 여전히 하나의 일관된 도메인 상태로 관리하는 게 더 자연스러운 경우
  • slice 간에 set/get으로 서로 상태를 참조해야 하고, 이를 위해 굳이 store를 분리할 필요가 없는 경우
    상태관리 도구를 사용하는 이유

• 요즘 상태 관리를 언제 사용해야하는가에 대한 고민이 있었다. react-query를 통해 서버 데이터를 캐싱, 동기화할 수 있고, nuqs를 활용하면 URL 기반 상태도 깔끔하게 관리할 수 있었기 때문에 상태 관리 라이브러리를 굳이(?) 사용해야 하는지에 대한 고민이 있었다. 그러다 캘린더 app, 미리디 같은 에디터 같이 서버 데이터를 사용하는 것보다 복잡한 컴포넌트로 구성된 환경에서 컴포넌트 간 데이터들을 서로 공유하기 위한 환경에서 여전히 유효할 수 있음을 알게 되었다.

좋았던 점

• 말로만 듣고, 피상적으로만 알고 있었던 함수형 프로그래밍에 대해 보다 딥하게(테오의 함수형 프로그래밍, 토스의 함수형 프로그래밍, 토스 깃헙의 상태관리 도입 전략) 조사해보고, 실제 코드에서 어떻게 녹여낼 수 있는지 고민할 수 있는 시간이 있어서 좋았다.
• 실무에서 마주칠법할 리팩토링 작업을 진행하며, 점진적으로 리팩토링해가는 전략에 대해서 고민하는 시간이 있어서 좋았다. 처음에는 비교적 큰 도메인(Admin)을 통으로 바꾸려 했었는데, 이러한 방식보다는 작은 부분부터 수정해나가는 것이 보다 안정적으로 리팩토링할 수 있음을 느끼게 되었다.
• 리팩토링을 하며 단순히 UI와 비즈니스 로직 분리, 함수 재배치 같은 단순 노동(?)의 작업만 하지 않고 DX를 챙기기 위해 고민할 수 있는 시간들이 있어 좋았다. 가령 아래와 같은 함수의 시그니처를 다른 개발자가 봤을 무엇을 기대할지 스스로에 물으며 리팩토링 하였다.

     const formatPrice = (price: number, productId?: string): string => { ... };
  

  • 함수 이름과 전달인자를 통해 함수 내의 작업을 유추할 수 있는지
    • 작업 내용을 포괄하는 함수명인가
    • 전달인자가 함수 내에서 어떤 역할을 하는지 유추할 수 있는가. 불필요한 경우 삭제
  • 함수 내에서 단일 책임 원칙에 맞게 하나의 작업만 진행하고 있는지
  • 확장성 있게 함수를 작성하되, 섣부른 추상화는 경계하였는가?

이번 과제에서 내가 제일 신경 쓴 부분은 무엇인가요?

• hooks 내 함수를 함수형 프로그래밍(액션, 계산, 데이터로의 구분) 답게 리팩토링하는 부분

이번 과제를 통해 앞으로 해보고 싶은게 있다면 알려주세요!

React Rendering 테스트

• '단일 책임 원칙(SRP)을 위반한 거대한 컴포넌트가 얼마나 안좋은지 경험해보아요!'의 취지를 더 분명하게 경험할 수 있는 시간을 갖으면 좋을 것 같다. 거대한 단일 컴포넌트와 srp 원칙을 준수한 컴포넌트 리렌더링이 수치상 어떠한 차이가 있는지를 점검해보면 좋을 것 같다.

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

• “코드를 확장성 있게 작성하라”는 이야기를 많이 들었습니다.
  다만 확장성을 의식하다 보면, 오히려 현재 요구사항에 비해 과도하게 추상화된 코드를 만들게 되는 것 같기도 합니다.
  코치님께서는 ‘확장성 있는 설계’와 ‘섣부른 추상화’를 구분하는 기준을 어떻게 가져가고 계신지 궁금합니다.

• 리액트로 사고하기(https://ko.react.dev/learn/thinking-in-react) 에서는 특정 기능을 하는 UI를 설계할 때

1. 어떤 컴포넌트들로 구성할지,
2. 이 컴포넌트들의 계층 구조를 어떻게 잡을지를 먼저 정리한다고 설명합니다.
   코치님께서는 실제로 컴포넌트를 설계하실 때 어떤 관점과 기준으로 구조를 잡으시는지, 그리고 주니어 개발자들이 초기에 특히 의식하면 좋은 포인트가 있다면 알려주시면 감사하겠습니다.