week8_4일차_PR

주요 작업

• 서버
  • GET : 헤드라인 가져오기
  • GET: 구독한 언론사 가져오기
  • GET: 모든 언론사 가져오기
  • GET: 카테고리 데이터 (카테고리 → 내부 언론사 → 내부 기사) 가져오기
  • POST: 더미 데이터들 추가(폐기)

학습 키워드

• suspense와 concurrent mode
• firebase functions

고민 및 해결과정

fetching 로직의 고민

Error boundary와 Suspense를 합쳐놓은 AsyncBoundary는 이제까지 바운더리 안에 요소들을 넣어 놓고, 안쪽 컴포넌트에서 렌더링 하는 방식으로 했었다. 하지만 이런 경우, 컴포넌트 안에서 fetch를 하게 되면, 계속해서 리액트가 리렌더링을 실행하게 되고, 이 과정에서 반복적으로 같은 http 요청이 날라가는 문제가 있었다. 이러한 문제는 계속해서 렌더링이 실행될 때, 안에서 state로 관리하고 있지 않기 때문에 컴포넌트가 실행되는 과정에서 계속해서 초기화되는 문제가 원인이었다. 이를 해결하기 위해서, 맨 처음에는 cache라는 객체를 fetching하는 함수의 바깥에 두고 key값을 엔드포인트로 하여 관리하고자 했다. 하지만 이러한 경우는 임시방편에 불과하기 떄문에 어떻게 하면 더 Suspense와 Fetching 로직을 잘 이용할 수 있을까를 고민하였다.

export default function getHeadlines() {
 
return fetchData<Article[]>(fetcher.get(HEADLINE_URI));
 
}
...
 
const response = getHeadlines();
export default function ShortNews() {
  const headlines = response.read();
 
  return (
    <div className="flex gap-4">
      <AutoRollingNews
        newsList={headlines?.slice(0, Math.floor(headlines.length / 2))}
        direction="LEFT"
      />
      <AutoRollingNews
        newsList={headlines?.slice(0, Math.floor(headlines.length / 2))}
        direction="RIGHT"
      />
    </div>
  );
}
 

따라서 fetch하는 함수 자체를 컴포넌트의 바깥에서 실행하고, 데이터 페칭이 비동기적으로 작동함과 동시에 컴포넌트를 보다 선언적으로 관리하기 위한 리팩토링을 진행했다.

리뷰 요청

안녕하세요 멘토님! 항상 고생 많으십니다🙇‍♂️ 벌써 마지막 리뷰네요 🥲 멘토님 피드백을 듣고 새롭게 배운 것들이 정말 많았는데 많이 아쉽습니다ㅠㅠ

NOSQL의 활용

이번에 firestore을 조금씩 알아가면서 NOSQL이 재밌기도 하면서 생각보다 더 설계가 어려웠습니다.. 관계형 데이터베이스에서 설계하는 것과는 다르게 각각의 collection에 대해서 어떻게 관리해야 할 지에 대해서 고민이 많이 되더라고요.. 저같은 경우는 이번에 category, article, publisher등의 도메인을 각각 루트 수준의 컬렉션으로 관리했는데, 이럴 경우에 만약 publisher(언론사)에서 작성한 기사의 경우에 대해서 각 기사 document의 id만을 담아놓을 수 있도록 하였고, 이를 순회하면서 그때마다 db에 접근하여 바로 데이터를 가져올 수 있게 하였습니다. 하지만 이런 경우 한번에 가져오지 않고 하나의 데이터를 가져오기 위해서 수차례 데이터베이스에 접근하는 것이 과연 괜찮은 방법일지 갑자기 궁금해져서 질문드립니다!

폴더구조 피드백 요청

entities : 도메인별 컴포넌트와 하위 디렉토리들

• widget: entities들이 모여 하나의 섹션, 즉 페이지에서 활용하는 큰 단위의 독립적 컴포넌트들. entities들을 묶고 하위 entites로 필요한 state를 내려주는 역할
• app : 엔트리 포인트이자 전역 스타일, 현재는 단일 페이지므로 해당 app에 안쪽 요소를 채워넣을 예정
• shared: 공통적으로 어디서나 쓰일 수 있고 데이터를 담고 있지 않는 컴포넌트들

하위 디렉토리로는

• ui: 기본적인 디자인 요소

• api: 필요한 api fetching하는 함수들
• lib: 컴포넌트에서 필요한 유틸함수들이나 재사용 불가능한 컴포넌트
• model: 비즈니스 로직(훅)이나 데이터 구조를 정의한 타입

이제까지 계속해서 조금씩 고치면서 폴더 구조를 이런 식으로 나누어 보았습니다. 첫 주에 말씀드렸던 부분에서 조금씩 고쳐진 버전이 있습니다. 저는 model에서 훅과 타입, 상수가 따로 분리되어 있었다면 좋겠다는 생각을 하긴 했지만 전체적인 구조는 불편한 점이 많지는 않았는데, 혹시 생각하시는 개선 방안이 있으시다면 조금 더 말씀해주시면 감사하겠습니다!

그 외에..

그 외에는 전체적으로 피드백을 해주시면 감사하겠습니다! 이번주 스터디 그룹에서 저는 가장 만족스럽게 느꼈던 부분이 아마 제가 몰랐던 학습 키워드를 많이 얻었던 부분 같습니다! 멘토님 뿐만 아니라 그룹원분들이 던져주시는 키워드들도 모르는게 많아서 성장하는 느낌이 많이 들더라구요ㅎㅎ 그래서 추가적으로 요청드리고 싶었던 것이 혹시 제가 보다 학습했으면 좋겠다고 생각하시는 키워드가 있으시다면 말씀해주시면 감사하겠습니다ㅎㅎ 2주일동안 정말 감사했습니다!!