[항해 플러스 프론트엔드 3기] 6주차 회고록

6주차 과제
기본과제 ?? pass
심화과제 ?? fail

발제 목표

• FSD 아키텍쳐를 활용하기
• Typescript를 확실히 사용해서 코드의 이해와 리팩토링에 대한 안정성을 확보하기
• 컴포넌트에 단일 책임 원칙을 부여하여 작게 만들기
• 적절한 관심사의 분리를 통해서 폴더구조를 만들기

6주차 계획

• 5주차 솔루션 commit따라가보기
• 액션/함수도 분리해보고, useMemo 등 FSD이외 것들도 적용해보기
• 함수명 네이밍 신경쓰기

어려웠던 점

• 타입정의하는 법
  • 타입스크립트를 안해봐서 타입정의하는데에 시간이 오래걸렸다..! 그래도 React 프로젝트에서 타입을 어떻게 정의하고 사용하는지 알게되었다
• FSD 아키텍쳐
• Tanstack Query
  • useQuery를 사용하여 데이터 패칭
  • useMutation
• compoonent를 먼저 쪼개고 개선을 점진적으로 하려고 했는데 props drilling이 발생
  • jotiom zustand 전역상태관리 라이브러리를 사용해보기
  • props drilling을 피하기위해 전역 상태관리 라이브러리를 사용한다?
    -> 전역 상태관리에 의존할것인지, custom hook으로 빼서 해결할수있는 것인지 주의
• 전역 상태관리로 상태를 불러오니까 리렌더링이 너무 자주 발생하는 것 같다..
  • props로 받아야할곳과 전역상태로 값을 불러오는것의 기준을 찾아야겠다
  • jotai를 사용할때도 분리를 잘해야겠다! -> 많은 상태가 엮여있으면 불필요한 리렌더링 발생

배운점

• FSD 아키텍쳐(Feature-Sliced Design)
  
  • Layer + Slice + segment 의조합! ex) /entities/post/api
  • Layer
    • app: 애플리케이션의 전체적인 설정과 초기화를 담당
    • pages: 실제 페이지를 구성하는 컴포넌트
    • widgets: 재사용 가능한 복잡한 UI 블록
    • features: 특정비즈니스기능을담당
    • shared: 공통으로사용되는유틸리티와 UI 컴포넌트
    • entity vs features vs widget
      • entity ->순수한 비즈니스 데이터와 로직을 포함
      • features ->사용자의 액션과 관련된 비즈니스 로직
      • widgets -> features, entity를 사용할 뿐 읽기 전용
  • Slice : 도메인
  • Segment: 역할
    • ui, api, model, lib, config
• 타입 선언 시, type , interface 의 차이점
  • interface는 주로 객체 타입을 정의하고, 같은 이름으로 선언하면 자동으로 병합되어 확장하기 좋습니다.
  • type은 더 유연해서 객체, 유니온 타입, 기본 타입(string, number 등)까지 정의할 수 있지만, 같은 이름으로 중복 선언할 수는 없습니다.
    --> 확장성과 객체 지향적인 구조가 중요하면 interface
    --> 다양한 타입 조합이나 유니온이 필요하면 type
• handler가 있으면, props로 받지말고 최대한 쪼개기! 관심사를 분리하기
• props drilling 보다는 전역관리가 더 낫다
  • context api -> jotai, zustand
• props로 받는 변수의 범위
  • 내가 처리하는 것 -> 나의 책임
  • 외부로부터 import하거나 props로 받는 것-> 위임
  • 하위컴포넌트에서 상위 state를 사용하려면 props로 전달
• 리팩토링을 도와주는 extension: copiler, VSCode React Refactor, cursor(AI)
• 단일 책임 원칙: 컴포넌트가 화면을 그리는 역할만을 담당하고, 상태 관리나 비즈니스 로직은 별도의 모듈에서 처리
• 모양이 비슷하다는 이유만으로 하나의 컴포넌트로 묶으려 하면, 오히려 코드의 결합도가 높아져 수정과 유지보수가 어려워짐
  • 공통적으로 재사용할 수 있는 컴포넌트는 도메인과 관련 없는 UI 요소들만으로 구성해야함
• 클린코드 원칙
  • 단일책임원칙
  • 단방향 의존성
  • 결합도 낮게 응집도 높게
  • 테스트가 용이하도록
• 클라이언트 상태관리 vs 서버 상태관리
  • 클라이언트: jotio, zustad
  • 서버: tanstack query

회고

• 과제 질문을 좀 더 적극적으로 해보자
• 과제하면서 사용하는 라이브러리
  • 내가 쓴 라이브러리(상태관리 라이브러리의)의 이유/기술 선정 이유를 설명할수 있어야한다!
• commit 내용 잘쓰기!
  • commit 내용도 중요하다 (특히 오픈소스 기여 혹은 과제할때)
• 이력서 써서 멘토링 질문해보기!
• 클린코드를 하면서 정답은 없고, 결국에는 일관성을 가지고 나만의 기준을 찾는게 중요하다고 느끼는 발제 주제였다
  • 기준을 세울 때는 이유가 있어야한다!
• 컴포넌트 나눌때 props가 너무 많아서 props 매핑, 타입 정의하느라 시간을 많이 썼다..
  • vscode에 컴포넌트를 나누면 자동으로 props를 매핑해주는 extension을 써볼걸..!
  • vscode에 기본 내장되어있다고 한다..! Ctrl + Shift + R : 코드를 함수나 변수로 감싸주는 기능 (리팩토링).