Codeit FE Sprint 4기 - 1팀
 김동현 |
 김영은 |
 노은수 |
 🐶박기범 |
개별 역할☝️
- 김동현
- 컴포넌트 : FeedCard, Modal(Question, Answer), Skeleton
- 페이지 : AnswerPage (CardPage의 조건부 랜더링으로 구현)
- git flow 초기 설정, 레포지토리 관리
- 무중단 배포 및 도메인 연결
- 다크모드
- 김영은
- 컴포넌트: buttons,input
- 페이지 : MainPage
- 에러 객체
- 로컬 스토리지 객체 선언 및 관리
- svg 파일 전역으로 관리
- global style
- constant 전역으로 관리
- 노은수
- 컴포넌트 : floatingButton, dropdown, reactions(좋아요, 싫어요), toast, avator
- 페이지 : CardPage
- date utils 함수
- 커스텀 훅 : 무한 스크롤, mutation(api 최신 업데이트), Query
- facebook, 카카오 공유 기능
- api 연결 리팩토링 → react Query 적용
- 라우터 연결
- 컴포넌트 성능 개선
- 박기범
- 컴포넌트 : Badge, Pagination, User card
- 페이지 : ListPage
- 버튼 컴포넌트 css 수정
- 추가 모달 구현
- 페이지네이션 기능 개선
- 메타태그 수정
2024.02.26(월) ~ 03.12(화)
질문과 답변을 통해 의미 있는 대화를 할 수 있는 독특한 커뮤니케이션 플랫폼
https://www.openmind-coreact.store/
git clone https://github.com/co-react/openMind.git
cd openMindnpm installnpm run start- 이름을 입력해서 질문을 받을 수 있는 피드 생성
- 질문을 위한 질문 목록 페이지로 이동
- 생성된 피드들을 카드 형태로 페이지별로 표시
- 피드들을 ‘이름순’ , ’최신순’ 기준으로 선택해서 정렬
- 원하는 피드를 선택하여 질문 피드 페이지로 이동
- 질문할 피드를 랜덤으로 골라주는 랜덤선택 기능
- 질문 생성
- 질문에 대한 답변 여부, 답변 표시
- 질문에 대한 좋아요, 싫어요 버튼, 수치 표시
- 링크 복사, 카카오, 페이스북 공유
- 무한 스크롤 방식
- 피드 삭제
- 답변하기 및 수정하기
- 개별 질문 삭제하기
- 답변 거절하기
- 질문에 대한 좋아요, 싫어요 버튼, 수치 표시
- 링크 복사, 카카오, 페이스북 공유
- 무한 스크롤 방식
https://whispering-sassafras-4ac.notion.site/3e52bc153e4d4955962d907802f163ae?pvs=4
✅ develop에서 메인 브랜치로 바로 pr을 진행해, 하나의 pr에 너무 많은 커밋이 누적.
해결 방안
- feature 단위로 pr 단위를 나눔.
- 다만, 초반부터 적용하지 않아 커밋, pr을 유연하게 적용하기 어려움
✅ git config core.ignorecase false를 적용하지 않고, push 했을 때, 다른 팀원들에게 문제가 발생. ✅ 로컬환경에서 develop 브랜치에서 pull 했을 때, feature 브랜치로 이동하지 못하는 현상.
해결 방안
- 먼저 git 설정 점검.
- 원격 저장소에 대, 소문자 2개로 누적된 파일, 폴더는 삭제
- 만약, 개인 feature 브랜치로 이동이 어려운 경우 : 파일을 삭제 후, 이동 -> 이동 후 git flow finish -> 다시 pull
✅ ListPage에서 화면 사이즈마다 화면상에 보이는 카드 수가 다름.
해결 방안
- 원래는 8개를 고정으로 limit값을 지정해주었는데 사이즈 별로 동적으로 limit를 지정.
- limit값이 변함에 따라 전체 페이지 수도 계산해주었고 이를 테블릿 → PC / PC → 테블릿 사이즈로 변경할때 동적으로 페이지 수가 바뀌도록 해주어야하는데 구현하는데 어려움을 겪음.
- 조금 더 효율적인 방법이 있을지 고민.
✅ props의 단방향성으로 인해(부모 -> 자식), 생기는 문제
- 만약 A 컴포넌트에서 상태를 정의하고, A의 자식 컴포넌트인 B 컴토넌트에서 A의 상태를 변경해야 할 때, 문제가 발생한다.
- 상태를 변경할 수 있는 setter 함수 혹은 setter를 포함하는 핸들러 함수를 props로 전달해 상태를 바꿀 수 있다. 이를 drilling이라고 한다.
✅ setter 함수를 넘기는 문제
-
만약 컴포넌트 트리가 깊어지면 어떨까?
- 실제 동작을 수행하는 “아래 트리의 컴포넌트”뿐 만 아니라, 해당 컴포넌트를 건너기 위한 중간 컴포넌트들이 “모두” setter 함수를 접근할 권한을 얻게 된다.
- 또한, 그저 전달을 위한 props를 연쇄적으로 정의하게 되어 번거로움을 유발한다.
-
결정적으로, props로 함수를 전달할 경우, 컴포넌트 렌더링 과정에서 함수가 새로이 정의된다. props가 변경되었다고 인식하여, 실제 변화가 없더라도 함수 props를 전달 받은 컴포넌트는 "무조건" 리렌더링이 발생한다.
- 이를 방지 하기위해 useCallback을 감싸야하는 번거로움이 발생한다.
-
예상 해결 방안: 전역 상태 도입, 전역 상태 라이브러리인 "Redux" 도입
✅ Post 요청 후에 상태 관리 문제
- useEffect를 통해 서버에서 데이터를 받을 경우 : 보통 서버에서 받은 데이터를 useState로 관리할 것이다.
- 만약, 다른 컴포넌트에서 post를 보내면? → 데이터를 받았던 컴포넌트의 상태는 “상한(오래된) 상태”가 된다.
- 이를 해결하기 위해, post를 보냈다는 "또 다른 상태"를 컴포넌트 안에서 선언해, get을 요청하는 컴포넌트에 알려야 한다.
- 이는 "전역 상태" 문제와 동일한 문제를 발생시킨다.
✅ Post 요청의 높은 자유도
- 서버 요청은 컴포넌트, 페이지의 제한 없이 다양한 곳에서 호출이 가능하다. 따라서, 이를 컴포넌트 내부 상태로 관리하려고 하면, 최신 상태를 업데이트 하기 위해, 많은 settter를 props로 전달해야 한다.
✅ 카드 생성 시, 중복 검증을 위해, GET 요청을 반복적으로 하는 문제
- 서버에 존재하는 사용자 이름을 중복되지 않도록 하기 위해 GET 요청, 이때, 중복된 경우, 다음 중복 검사에서 다시 요청. -> 매우 느림
- 만약, 2명의 사용자가 동일한 이름(ex:오스틴)을 요청한 경우: GET 요청을 통해 저장한 내부 상태는 "오스틴"이 없는 상태 -> 2명이 동시에 요청 -> 한 명이 POST 성공하더라도, GET 요청을 다시 하지 않으면, 내부 상태는 여전히 "오스틴"이 없는 상태 -> 결국, 2명 다 "오스틴" 이름을 가지게 됨.
해결 방안
✅ React-Query의 도입
- server state 정의 : 서버 요청의 높은 자유도를 관리하기 위해, 컴포넌트 내부의 상태가 아닌, 컴포넌트 외부, 즉 "server state"를 도입.
- 데이터 캐시 : 서버 요청을 최소화하기 위해, 클라이언트의 자원을 활용. 서버로부터 받은 데이터를 캐싱(일종의 메모이제이션). -> 이를 통해, 중복 검사 시, 서버 재요청의 문제 해결
- Mutation : React-Query는 useMutation 훅으로, 캐시를 통해 관리되는 server state는 post 요청에 대한 후속 처리를 지원. -> 같은 쿼리키를 가지는 쿼리에 post 요청 -> 서버측 데이터로 post 보내는 것 뿐만 아니라, 쿼리 데이터(캐시에 저장된 데이터)도 갱신. -> useQuery를 통해 서버 데이터를 요청하는 쪽으로 데이터가 변경되었다는 것을 자동으로 알려서 새로운 데이터를 보냄.