Growth Log : by dpwls

Appearance

0724 ​

Clone Coding ​

issue to project workflow ​

  • 매번 이슈에다가 프로젝트 추가하는게 귀찮아서 워크플로 파일 하나 추가함
  • add-to-project 라는 액션 라이브러리가 있어서 project-url과 github-token 만 설정하면 됨
yml
name: 이슈에 자동으로 프로젝트 추가  
on:  
  issues:  
    types: [opened]

jobs:  
  add-to-project:  
    runs-on: ubuntu-latest  
    steps:  
      - name: Add to project  
        uses: actions/add-to-project@v1.0.2  
        with:  
          project-url: https://github.com/users/dpwls02142/projects/3  
          github-token: ${{ secrets.PERSONAL_TOKEN }}

named export VS default export ​

  • named export는 import할 때 이름을 변경할 수 없음. 여러개를 export 할 수 있음.
  • default는 한 파일당 하나만 export 할 수 있고, export defualt 형태로 사용됨.
  • 해당 방식들은 es6 문법에서 새로 등장함
    • es6가 뭔데?
      • js의 역사에서 가장 큰 변화가 있던 6번째 버전
      • let, const와 import/export 모듈, 화살표 함수, class, promise, 템플릿 리터럴 등이 등장함
    • 그 전엔 어떻게 썼는데?
      • require와 module.export 방식으로
    • 지금은 왜 그 방식(require)을 안 쓰는데?
      • 코드가 실행되기 전까지 오류를 못 잡고 (ide에서 코드를 작성할 때 오류를 못 잡음. 무조건 pnpm run이든, build든 해야 오류를 잡을 수 있음.)
      • 트리 셰이킹이 안 돼서 불필요한 코드까지 번들에 포함됨
      • 그리고 require는 동기식 로딩이라 주로 서버 환경에서 쓰임. 브라우저 환경에 적합하지 못함
    • 그래서 등장한게 import/export임.
  • 그래서 named랑 default 둘 중엔 뭘 쓰는게 좋음?
    • 컴포넌트나 훅에는 named export,
    • 페이지에는 default export.
    • 왜 컴포넌트나 훅에는 named export?
      • 에디터에서 자동 완성 기능이 잘 동작함.
      • default로 export하면 협업시에 컴포넌트명을 지멋대로 바꿔서 쓸 수 있기에 헷갈릴 수 있음. 이를 방지해줌.
    • 왜 페이지에는 default export?
      • next.js는 page 파일을 자동으로 라우트로 매핑함. 근데 이 때
        1. named export 방식을 사용하고 있으며
        2. 여러개의 컴포넌트가 한 파일에 있다면
      • next.js 입장에선 어떤걸 써야 할 지 명확하지 않기에
      • 보통 page에선 default export를 쓰는게 권장됨.
  • 참고 자료

named export로 통일하며 생긴 고민 ​

  • gemini가 AddToCartQuantity를 cart 페이지에서도 사용하고 있다보니 해당 이름은 적절치 않아서 _shared 폴더로 이동하는게 더 나을 것 같다고 리뷰를 달아줌.
  • 근데 내 생각에 _shared 폴더에는 좀 더 범용적인, 정말 모든 컴포넌트에서 공유되는게 들어가는게 맞다고 생각했음. 확장가능성을 고려하더라도 어쨌든 option과 quanity는 product라는 도메인에 종속적인 컴포넌트라고 생각했음.
  • 그래서 더 생각해보니 애초에 product components로 옮기는게 좋을 것 같다고 판단해서 위치를 거기로 수정함.
  • 관련 PR: https://github.com/dpwls02142/shopping-app/pull/66

Git branch 오류 ​

bash
error: cannot lock ref 'refs/remotes/origin/refactor/directory/product-quantity':  
'refs/remotes/origin/refactor/directory' exists; cannot create 'refs/remotes/origin/refactor/directory/product-quantity'
  • 내 로컬 .git 폴더 안에 refactor/directory라는 파일이 존재해서 발생한 오류임
  • Git은 브랜치를 디렉토리 구조처럼 관리하기 때문에, 내가 현재 사용하고 있는 브랜치 컨벤션 (기능/단위/범위)의 형태를 사용하면 git에선 이미 있는 브랜치라고 인식해버림. 왜냐면 이미 같은 이름의 파일이 존재하고 있으니까.
  • 근데 내가 원격에선 메인에 병합되는 즉시 브랜치를 지우고 있었으니까 purne 으로 리모트에 존재하지 않는 브랜치를 로컬에서도 삭제하고
  • 다시 git fetch 하면 브랜치 구조가 정상화됨
bash
git remote prune origin  
git fetch

AddToCartForm의 책임 ​

  1. AddToCart라고 적혀있지만 product의 purchase까지 담당하고 있음. 장바구니에 담기만 있으면 모를까..
  2. 그래서 컴포넌트와 훅명을 ProductAction으로 수정함. add to cart랑 purchase 둘 다 담당한다는 의미에서.
  3. 근데 gemini 리뷰를 받아보니까 action에서는 purchase와 add to cart에 대한 입력과 선택만 담당하고 실제 action은 부모 컴포넌트에 위임하는게 좋을 것 같다는 리뷰를 받음
  4. 이건 좀 더 생각해봐야될 듯

그 외 ​

  • 그리고 가만 생각하니까 치명적인 로직 오류가 있음.
  • 유저가 장바구니에 max purchase quantity만큼 상품을 담았는데, 해당 옵션과 같은걸 구매하면 지금은 그냥 넘어가진단말임?
  • 근데 이게 말이됨? 이러면 장바구니에 최대 구매 가능 수량 담아놓고, 최대 구매 가능 수량까지 구매 한 다음에 다시 장바구니 가서 결제를 할 수 있잖음.
  • 이러면 안되니까 구매했는데 이미 그 상품이 장바구니에 존재한다면 장바구니에서 max purhcase quantity를 구매한 수량만큼 삭감하는 형태를 해야될 것 같음
  • 관련 이슈: https://github.com/dpwls02142/shopping-app/issues/68