week8_2일차_PR

주요 작업

• 서버
  • 서버 데이터 구조 NOSQL에 맞도록 재설계
  • article 제작
  • 라우터 설정
  • 헤드라인 get api 설계 및 구현
• 클라이언트
  • 프로그레스바가 끝날 때 두번 함수 호출되는 문제 해결
  • Press → Publisher로 도메인 이름 변경
  • props drilling이 넓게 퍼지는 컴포넌트를 context 사용하여 리팩토링
  • rollingnews 부분을 데이터 fetching해서 가져올 수 있도록 리팩토링

학습 키워드

정리

• setTimeout과 setInterval의 지연 간격
• react portal

학습중…

• Suspense와 Error Boundary
• firebase functions
• firestore data structure

고민 및 해결과정

서버 데이터 구조 설계

firebase firestore에서는 document, collection의 개념을 가진 NOSQL(Document Database)로 세 가지의 데이터 구조화 방법을 제시한다.

1. 문서의 중첩 데이터
   • 문서 내에 배열 또는 지도 등 복합 객체를 중첩
   • 하나의 문서 안에 통으로 데이터를 넣는 스타일
2. 하위 컬렉션
   • 문서 내에 다시급 하위 컬렉션을 주고, 컬렉션 별로 관리할 수 있도록 하는 스타일
3. 루트 수준 컬렉션
   • 데이터베이스 루트 수준에 컬렉션을 만들고, 각 컬렉션 내에서 쿼리하여 사용하는 스타일 나와 같은 경우 category, article, publisher,user 네 가지 데이터들을 만들어 놨었는데, 이러한 데이터에 대해서 카테고리에도 해당 카테고리를 가지고 있는 기사들에 대한 정보를 가지고 있어야 했고, 만약 하나의 정보에 갱신이 일어나게 된다면 다른 도메인 또한 함께 갱신이 이루어졌어야 했다.

예를 들어, 기사가 새롭게 하나가 추가된다면, 해당 기사에 선택된 카테고리에도 카테고리 도메인이 관리하는 기사에 대해서 추가하는 갱신 작업이 이루어져야 했고, 언론사인 publisher에서도 언론사별 기사가 추가됐어야 했기 때문에 이렇게 하나의 데이터 갱신이 연쇄적인 갱신으로 가는 경우 각각의 도메인을 루트 수준 컬렉션으로 하는 것이 낫겠다고 생각했다.

루트 수준에서 각 도메인을 관리하면서 하나가 추가되면 추가된 문서에 대해서 갱신을 하기 위해서는 문서의 아이디 자체만을 다른 도메인에 갱신하고, 데이터 조회가 필요할 때면 필요한 아이디를 가져다 그때마다 아이디 값을 통해 탐색 없이 바로 접근이 가능하기 때문에 해당 방법이 가장 합리적이라고 생각했다.

멘토 리뷰 요청

안녕하세요 멘토님! 오늘도 고생 많으십니다ㅎㅎ 어제 오늘 계속 nosql 공부를 하고 데이터 구조를 짜느라 많이 진전도가 없긴 하지만 질문이라도 드리고 싶었습니다..ㅎ

ui와 비즈니스 로직의 분리

저번 리뷰에서도 언급해주셨던 부분인데, 컴포넌트의 관심사 분리에 대하여 여쭤보고 싶습니다 사실 이번에 처음 관심사 분리를 해보다보니까 많이 헷갈리더라고요😅

저는 하나의 작은 컴포넌트에서도 관심사 분리를 더 해보고자 각자 맡는 역할을 분리하려고 했었습니다. 제가 컴포넌트에서 관심사를 분리한 기준은

• ui : 오로지 렌더링만을 담당하는 부분, 필요한 경우 동적으로 바뀌는 값을 가질 수 있음
• 비즈니스 로직: 사용자의 모든 경험에 직간접적으로 관여하는 데이터 관리 로직들. 훅이나 ui 조작 함수 등 같이 상태값이 바뀌는 것 자체가 상태값을 통해서 사용자가 보이는 것들이 바뀌게 되는 모든 것들 을 나누어야 한다고 대부분의 컴포넌트들을 위와 같이 나누었던 상태였습니다.

저번에 피드백 주신 부분의 경우 프로그레스바를 컴포넌트화시키게 되면 사실 이 컴포넌트 자체가 프로그레스바만의 역할을 지닌다고 생각하기 때문에 안의 로직과 ui등에 대해서 굳이 분리할 필요가 있냐는 말씀을 해주셔서 저 또한 분리할 필요가 없다고 생각했습니다.

그래서 현재 제가 다시금 생각한 구조는 보다 큰 컴포넌트의 경우, 즉 재사용이 불가능한 정도의 컴포넌트에 대해서는 모두 ui와 비즈니스 로직 등을 커스텀 훅과 같은 형태로 분리하였습니다. 하지만 말씀해주신 프로그레스바와 같이 재사용이 가능한 정도의 컴포넌트의 경우에는 가장 작은 역할 하나만을 담당하기 때문에 굳이 나눌 필요가 없다고 생각하여 분리하지 않는 구조를 생각해보았습니다.

이를 통해 질문드리고 싶었던 것이 두 가지가 있는데,

• ui/비즈니스 로직 분리에 대한 저의 방식에 대한 멘토님의 고견
• 재사용 가능한 컴포넌트와 불가능한 컴포넌트가 어찌보면 보다 세부적인 관심사를 나눈/나누지 않은 구조로 되어있는데 이러한 구조들이 통일성을 해치는 느낌이 있어서 구조에 대한 멘토님의 고견 을 여쭙고 싶었습니다!

나머지는 편하게 봐주시고 피드백 주실 부분 말씀해주시면 반영해보겠습니다! 항상 리뷰 정성들여 해주셔서 감사합니다. 좋은 저녁 되세요!🙇‍♂️