[7주차 실습] 6주차 뉴스API ReactJS/Axios로 리팩토링하기

[Seok93]

📚 개요

6주차 Vanilla JS와 Fetch로 구현한 뉴스 API 를 ReactJS와 Axios로 리팩토링하기

📚 작업사항 (기능추가/수정/삭제 등)

• CRA를 이용한 기본 환경 구축
• ReactJS로 리팩토링하기
• Fetch를 Axios로 변경하기

📚 배운점

1) *.module.css를 이용하면 class명 중복 문제가 없어짐을 알게 되었고, 처음 적용하게 되었습니다.
2) *.module.css를 import로 추가하면, 컴포넌트에 완벽하게 종속되므로 variables.css와 common.css와 같은 공통값들은 *.module.css로 추가하면 안된다는 점을 알게 되었습니다. (하위 컴포넌트에 적용되지 않았습니다.)
3) fetch가 있는데, 왜 굳이 axios를 사용하는지 궁금하여 찾아 보았습니다. 이를 통해 fetch보다 지원되는 기능도 많고, 기존에 fetch에 첨부하던 body 데이터(문자열)와 다르게 data속성과 객체를 이용하여 정보를 전달할 수 있으며, json으로 데이터를 자동 변경해주어 사용이 간편하다는 점을 알게 되었습니다. 별도의 설치 등를 진행해야하는 점을 제외한다면 fetch의 상위 호환이라고 생각합니다.

※ 참고자료 모음
CSS Module
axios vs fetch

📚 궁금한 점

1) variables.css와 common.css 같이 공통값들은 *.module.css를 사용하면 안된다는 점을 깨달았지만, *.css파일과 *.module.css 파일이 공존하게 되었습니다. CSS Module을 통해 작성할 때에는 css파일과 module.css 파일이 공존하는게 자연스러운건가요? 아니면 제가 모르는 공용값들을 사용할 수 있는 CSS Module 사용법이 있나요?

2) 컴포넌트를 나눌 때에는 재사용성 이외에 무엇을 더 고려해야할까요?
프로젝트를 진행하면서 컴포넌트를 어떤 기준을 가지고 나누는게 좋을까 고민하게 되었습니다. 컴포넌트로 나누지 않아도 , DOM 요소들을 하나의 컴포넌트에 다 넣어서 표현할 수도 있고, 필요에 따라서는 일부 DOM요소를 뜯어서 컴포넌트 나눌 수도 있었습니다. 그런데 무분별하게 컴포넌트로 나누면 파일이 많아져 복잡성이 늘어날 것 같기도 하고, 그렇다고 너무 코드를 한 곳에 모아두어도 읽어내야할 코드량이 많아지는 등의 문제가 생길 것 같았습니다. 멘토님은 컴포넌트를 나눌 때 어떤 점을 고민하시나요?

추기) EmptyNew와 News를 컴포넌트로 나누었는데, 의미상으로는 한 번에 와닿아 가독성을 올라갔어도, 실질적으로 코드량이 얼마 되지 않은 부분을 컴포넌트로 분리한 것 같아 좋아보이지는 않았습니다.

3) 라이브러리 학습 방향성의 가이드라인을 제시해주실 수 있나요?
온라인 강의에서 다양한 라이브러리를 맛보기식으로, 각 라이브러리 튜토리얼 부분을 따라하며 소개를 받았습니다. 그런데 어떤 라이브러리가 현재 기본적으로 많이 사용되는지, 혹은 기존에 많이 사용하던 A라이브러리에서 B라이브러리로 많이 옮겨가는 추세라던지 등의 상세한 정보가 없어서, 어떤 라이브러리를 선택하여 먼저 익히는게 좋은지 몰라 조금 답답한 면이 있습니다. 현업에서 자주 사용되는 라이브러리나 먼저 공부하면 좋은 라이브러리 등에 대해 알고 싶습니다.

스타일 라이브러리: styled component, emotion, sass/scss etc
상태관리 라이브러리: redux, mobx, react-query, recoil etc

📚 실수한 점

1) CRA를 이용한 기본 환경 구축 부분을 저장하여, 리뷰에 불필요한 파일들을 제거했어야 했다. (멘토님 죄송합니다😥)
2) 컴포넌트가 하나씩 완성될 때마다 commit을 분할했으면 좋았을텐데... 다 만들고 뒤늦게 깨달았습니다. 다음엔 좀 더 컴포넌트와 기능 단위로 쪼개서 commit을 작성해야겠다.

[danbileemrt]

수고 많으셨습니다!
궁금한 점으로 적어주신 부분에 대해서 제가 생각한 내용 정리해보았는데, 참고 부탁드립니다🙇‍♀️

1. css module이 결국 컴포넌트 단위로 네임스페이스에 대한 고민 없이 스타일을 나누겠다라는 의미에서 사용하는 것이라고 생각해서, 공용 css와는 의미와 목적이 다른 것 같아요! 말그대로 공용 != 모듈 이랄까요? 따라서 현재 상태가 자연스러운 상태라고 보입니다.
2. 사실 무분별하게 컴포넌트를 나누었다는 경우는 거의 없다고 볼 수 있을 정도로 저는 컴포넌트 하나가 비대해지는 것을 지양해야 한다고 생각하는 편입니다! 지금 컴포넌트를 나누었을 때 코드량이 많지 않다 하더라도, 유지보수 과정에서 얼마든지 컴포넌트별로 피처가 추가될 수 있어서요. 그렇게 되면 또 언젠가는 해당 컴포넌트를 쪼개야 할 때가 올 수도 있습니다. 다만 컴포넌트 내부로 숨겨야 할 것과 드러내야 할 것에 대해서는 고민되는 부분인데, 현재는 News 컴포넌트가 뉴스 카드들을 모두 감추고 있는데 이것이 바깥으로 나올 필요는 없을지 고민해봐도 좋을 것 같습니다. 예를 들어서 검색 결과가 존재할 때 표시되는 컴포넌트에서 현재는 개별 뉴스 카드를 렌더링만 해주고, 이외의 News 만의 역할은 없는 상태입니다. 따라서 NewsCard 컴포넌트를 새로 만들고, 이를 NewsContainer에서 직접 검색결과를 순회하여 렌더링해주도록 바꿀 수도 있을 것 같습니다. 만약에 나중에 News라는 상위 컴포넌트가 필요해지는 경우에는 필요한 처리를 한 후 children을 렌더링 해주는 형식으로 News 컴포넌트를 구현한 후 NewsCard들을 감쌀 수 있을 것 같아요. 그렇게 되면 News와 NewsCard가 각각 담당하는 역할이 명확해지고, 컴포넌트 단위도 보다 작아지면서 폐쇄적이지 않은 형태가 될 것 같습니다.
3. 라이브러리는 사실 필요에 따라 선택하시면 될 것 같아요! 많이 쓰여지는 것들이 있지만, 그렇다고 그게 정답은 아니고 프로젝트의 규모나 성격에 따라 항상 더 적합한 라이브러리가 있는 것 같습니다. 다만 기존에 많이 쓰여지는 것들이 많이 쓰이는 이유 또한 분명히 있긴 해서요, 예를 들어 현재 운영중인 서비스라 안정성을 중요시한다면 아무리 새롭고 혁신적인 라이브러리라 하더라도 바로 도입할 수는 없을 것 같습니다. 같은 기능을 제공하는 여러 라이브러리를 비교하는 방법은 우선 공식 문서를 통해 직접 파악하시는 방법과 구글 검색을 통해 다른 사람들이 정리한 내용을 참고하시는 것, 그리고 npm trends 등에서 절대적인 사용량을 비교해보시는 것 등이 있습니다. 예로 들어주신 스타일과 상태관리에 있어서도 프로젝트의 성격과 사용하려는 목적에 따라 선택하실 수 있는 것들이라서 모든 내용을 코멘트로 정리하기에는 조금 방대할 것 같긴 합니다! 현업에서 제가 사용하고 있는 조합은 emotion styled + react-query + recoil 인데요, 가독성과 유지보수성 측면에서 만족하고 있긴 하지만 이 조합으로도 코드 패턴은 굉장히 많이 달라질 수 있고, 경우에 따라 코드가 지저분해지는 경우도 많이 보아서 여러 프로젝트에 도입해 보시면서 best practice를 찾는 과정이 필요할 것 같습니다.

[danbileemrt]

컴포넌트 라이프사이클에 영향을 받지 않는 상수이므로 컴포넌트 바깥으로 빼주시면 좋을 것 같습니다!
또한 현재는 내비게이션 클릭시 페이지 이동 등이 구현되지 않는 스펙이라서 괜찮지만,
나중에 페이지 이동을 구현해야 하는 상황에는 데이터구조의 변경이 필요할 것 같아서 변경점을 최소화하려면 객체의 배열로 데이터를 구성해보시면 어떨까 싶습니다!
(지금 프로젝트에서 필요하다기보다는 추후 다른 프로젝트를 진행하실 때 고려해보시면 좋을 것 같습니다.)
예)

const navigation = [
  {
    id: 'home',
    text: 'Home'
  },
  // 나머지 메뉴들
]