TIL4 | 클래스 컴포넌트 / 패키지 관리

구현 요구 사항

• 조회한 상품 및 관심 없는 상품의 리스트를 관리하고, 조회한 상품 목록을 필터링하여 보여주는 페이지 및 개별 상품 상세 페이지를 작성
  
  

Points

• class component
• localStorage, sessionStorage
• history.push를 활용한 routing
• utils로 재사용 가능한 함수 / 상수 관리
• component별 index.js / css 작성
  
  

Things I learned

• 요구 명세서를 읽었을 때 사이트 구조 파악이 쉽지 않았다. 그래서 명세서에는 없지만 전체 목록을 보여주는 페이지를 (해당 과제를 제출한 기업 서비스 페이지와 비슷한 구조로) 추가 구현하기로. 요구하는 의도를 파악해 보자!

• 함수형 컴포넌트만 작성해봐서 클래스형으로 하라는 과제 제한사항에 동공지진... 다행히 React 공식 문서에서 함수형 컴포넌트를 클래스형으로 변환하는 방법을 친절하게 설명해주고 있다. 함수형 컴포넌트에 작성된 내용을 render 안에 옮기고, state 설정이나 method binding이 필요할 경우 constructor를 작성하면 됨! 아래와 같이 하면 props가 갱신되어도 해당 컴포넌트에 적용이 되지 않는다고 한다. 주의..
  

• utils에 재사용 가능한 함수와 상수를 별도로 정리해놓으니, 여러 명이 기능별로 컴포넌트를 나눠서 구현하고 있을 때 정말 편하다. 수정하기 편한 코드 좋은 코드~

• 컴포넌트 별로 css 파일을 따로 작성하는 것 역시 기능별로 역할을 나눠서 작성할 때 매우 편함. 근데 서로 클래스명이 같아서 오염될 수 있음을 주의해야.

• localStorage, sessionStorage : object 사용할 때 JSON.parse와 stringify 잊지 말자.

• history.push를 활용한 routing : history.push할 때 props를 전달할 수 있다.

• 자료 구조를 결정할 때는 자료의 양이 많다고 상정하고 효율성을 늘 고려하자. 일단 요구 명세서에 주어진 자료는 id값이 없는 단순 배열이었다. 자료가 변경될 가능성을 고려하여 자료에 id 값을 추가했다. 로컬 스토리지에 저장할 productInfo의 자료 구조 부분 논의 중, 내가 구현한 필터링 적용에는 array 형태가 편해서 array로 요청을 했다. 그러나 array는 탐색에 시간이 걸린다는 팀원 분 설명을 듣고 id를 키값으로 한 object로 결정했다.

• 각자 작성한 코드를 합치는 작업에 걸리는 시간을 충분히 할당하며 스케줄을 잡자. 팀원 중 한 명의 git이 터지는(?) 사고가 발생하여 합치는 작업을 시작하는 시간을 미뤘다. 합친 후에 버그 잡고 css도 손 보려고 계획했는데, 버그 잡는 시간이 예상했던 것보다 오래 걸렸다.

• 내 로컬에서 혼자 보는 프로젝트가 아니다. '다른 환경'을 고려하자. 패키지 관리는 중요하다! yarn.lock과 package-lock.json은 배포할 때 서로 충돌한다.

  이하는 나의 삽질을 나 혼자 기념하며 적는 엄청난 구구절절...

  ... 사건은 누군가의 로컬 환경에 설치되어 있던 yarn으로부터 시작되었다. 각자 브랜치를 main에 머지한 후 pull을 했더니 yarn.lock 파일이 내 로컬에 생성되며 conflict가 우수수 쏟아졌다. yarn install을 하면 간단히 해결된다는 구글링 결과를 따라했더니 실제로 conflict는 잘 해결되었다. (근데 옵션을 깜빡해서 node modules가 다시 설치되네? 에이 뭐 괜찮겠지...) 그리고 github pages로 배포하는 작업을 맡아서 늘 하던대로 룰루랄라 package.json을 수정하고 npm run deploy를 했는데

  음...? 뭐야 외 않되...??? 🧐

  이 때 package.json, package-lock.json, yarn.lock이란 파일들이 하는 역할을 제대로 알고 있었더라면 삽질을 하지 않았을 것이다. 하지만 몰랐죠... 그래서 이전에 구글링했던 기억을 더듬어, github pages에서 배포할 브랜치를 main으로 바꾸고 다시 배포를 했다.

  음...? 메인 브랜치 원격 저장소 소스 다 어디 감...??? 왜 빌드 설정 파일만 있는 거지...??? 😱

  이 때부터 등줄기에 식은땀이 흐르기 시작. git log 살펴보고 git reset을 하며 겨우 메인 브랜치를 되살렸다. (깃 선생님 감사합니다... 깃이 없는 세상 상상조차 할 수 없어...ㅜㅜㅜㅜ) node modules를 다시 설치하려고 npm install을 하고, 배포 전에 로컬에서 잘 되는지 돌려보는데 에러가 나며 엥...? react-router-dom을 설치하라고?

  github pages로 배포 시도 했다가 또 팀 메인 브랜치에 문제가 생길까봐, 이번에는 개인 레포지토리를 새로 만들고 소스파일만 가져다가 heroku로 배포를 했다. heroku에서도 빌드 실패를 했지만 빌드 로그 메시지가!! 너무도 명확!! npm으로 빌드하려면 yarn.lock을 지우고 yarn으로 빌드하려면 package-lock.json을 지우라는 것.

  package-lock.json은 어떤 일을 하는가? node-modules라는 의존성 트리 폴더를 설치할 때 기본적으로package.json이 프로젝트에서 필요로 하는 패키지 정보를 담고 있지만, 담고 있는 버전 정보가 범위값이라서 npm 버전이 다르다든가 특정 패키지가 추후 업데이트 되는 등의 이유로 개발자의 의도와 약간 다른 의존성 트리가 생성될 수 있다. 반면 package-lock.json 파일이 있으면 npm install 명령어 실행시 개발자가 의도한 버전대로 의존성 트리를 설치할 수 있다. (yarn.lock도 동일한 역할)

  yarn install을 하며 의존성 트리가 yarn 기준으로 바뀐 상태에서 npm install을 하니, 패키지가 제대로 설치가 되지 않았던 것 같다. package.json에는 npm run build로 작성되어 있으니 빌드도 배포도 제대로 안 되고...

  과제 1에서 "Intersection Observer가 익스플로러만 안 된다고? 이제 익스플로러는 지원도 더 이상 안 한다는데 익스플로러 신경 써야 하나?"라고 안일하게 생각한 적이 있는데.. 서비스를 여러 다른 환경에서 사용한다는 것을 언제나 잊지 말아야겠다.