Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
✨ 구현 기능 명세
생각과제
🐵 개인적으로 프론트엔드 개발자에게 가장 중요한 능력 중 하나가 컴포넌트 분리, 모듈화 라고 생각한다!
컴포넌트는 리액트 웹을 구성하는 단위인 만큼 한가지의 역할만 해야한다
그러나 그렇다고 해서 최대한 쪼개서 컴포넌트를 생성하는 것은 성능상 바람직하지 않다.
모듈화의 핵심은 재사용성이기 때문이다.
🙋♀️ 그렇다면 왜 재사용할 내용을 컴포넌트화 해주어야 할까?
가장 단적인 예시로 하나의 웹앱 내에 동일한 디자인의 버튼이 이곳 저곳에서 텍스트만 달리하여 사용될 것이다.
그런데, 해당 서비스가 브랜딩을 다시하게 되면서 디자인 시스템도 달라지게 될 경우, 웹 앱 내의 모든 버튼의 디자인도 변경될 것이다.
이때 버튼을 컴포넌트화하지 않고 매번 각기 다른 element로 생성해두었다면, 그 모든 버튼을 찾아다니며 각각 디자인을 변경해주어야 할 것이다.
그러나, 만약 하나의 버튼 컴포넌트를 만들고 이를 이곳 저곳에서 재사용하고 있었다면,
그 하나의 컴포넌트의 스타일만 변경해주면 동시에 웹앱 내의 모든 버튼의 스타일을 깔끔히 업데이트시켜줄 수 있다.
정리하자면, 컴포넌트는 한가지의 일을 반복적으로 하는 친구를 재사용하기 위해 묶어둔 모듈이다 !
이러한 방식을 Computer Science 에서는 ‘관심사의 분리’, Separation of Concerns (SoC) 디자인 원칙이라고 한다.
위의 내용에서 이야기한 것에 따라,
결국 컴포넌트 분리의 기준은 다음과 같다.
✔️ 한가지의 역할을 하는가?
✔️ 반복 사용되고 있거나, 반복 사용될 가능성이 있는가?
✔️
UI
와 관련된 일을 하는가?기능(로직)
과 관련된 일을 하는가?위의 기준에 따라 나의 컴포넌트가 더 분리될 수 있는 길이 있는지 끊임없이 고민하며
모듈화하고자 노력해보자 ! !
🙋♀️ React에서 상태란?
props
와 달리 컴포넌트 내부에서 관리되는 자바스크립트 객체🐵 상태의 종류
🐵 클라이언트 상태 vs 서버 상태
관리
(Redux, Recoil 등 상태관리 라이브러리 사용)
(데이터베이스 사용)
요청
🐵 Props Drilliing
🐵 상태를 관리해주자
서로 다른 컴포넌트에서 동일한 데이터를 다룰 때! 해당 상태를 관리해주어야 한다.
🙋♀️ 왜?
서로 다른 컴포넌트에서 동일한 데이터를 다룰 땐, 해당 데이터의 출처가 동일해야 한다. 그래야 서로의 변화에 동적으로 반응할 수 있기 때문이다.
즉
상태의 일관성 (=데이터의 무결성)
을 잘 지켜야 한다.Single Source of Truth
이라는 방법론이 이러한 상태의 일관성을 유지하기 위해 등장한 방법론인데, 말그대로 신뢰할 수 있는 단일 출처를 말한다.이 방법론이 React가 택한 방법론으로, 결국 React에서 상태관리가 필요한 이유는 데이터의 무결성을 위해서, 서로 다른 컴포넌트에 분포되어있는 하나의 데이터가 서로 일치할 수 있도록 관리해주기 위함이다.
🐵 상태 관리 라이브러리
Props Driling이 일어나지 않도록, 상태가 효과적으로 사용될 수 있도록 효율적인 설계를 하는 것이 가장 중요하지만,
만약 최선을 다해 설계해도 어쩔 수 없이 불필요한 Props Drilling이 많이 발생할 경우 상태 관리 라이브러리를 잘 활용하는 것도 좋다.
상태관리 라이브러리는 Client State / Server State에 따라 분류할 수 있다.
대표적인 몇가지의 라이브러리에 대해 알아보자.
💡 Client State Library - Context API
💡 Client State Library - Redux
💡 Client State Library - Recoil
💡 Client State Library - MobX
💡 Server State Library - React Query
React에서
데이터 fetching
과캐싱 프로세스
를 간소화해주는 라이브러리Client에서 API와 통신을 하기 위해서는
추가적으로 useEffect, useState를 함께 쓰면서 데이터를 fetching 해왔다.
하지만 React Query를 사용하면 이러한 훅들의 필요성이 사라진다.
React Query에 대해 자세히 알아보자 !
✔️ React Query 주요 개념
Query
Mutation
Query Caching
Query Invalidation
✔️ useQuery 훅
API 엔드포인트나 DB에서 데이터를 비동기적으로 가져오도록 서버에 요청하는 것
useQuery는 기본적으로
✔️ useMutation 훅
API 엔드포인트나 DB에 데이터를 새로 생성, 수정, 삭제
✔️ Query Caching
원격 서버와 통신하는데에 걸리는 시간을 단축하고자,
여러번 불러올 데이터는 캐시에 저장하여 반복해서 필요로 할 경우 원격 서버가 아닌 캐시에서 빠르게 가져올 수 있는 방식
useQuery 훅 사용 시, 지정했던
고유 키
밑에 반환된 데이터가 캐싱된다.기본적으로는 캐시 데이터는 오래된(stale) 상태로 기록된다.
✔️ Query Invalidation
지정해준
staleTime
과 무관하게 즉시 데이터를 stale 상태로 처리해야하는 경우가 있다.예를 들어, API에 POST 요청을 보내 데이터 값을 업데이트할 때엔, API 엔드포인트에 있는 데이터의 값이 캐시에 저장되어있는 값보다 더 최신 상태가 되고, 캐시에 저장되어있는 데이터는 곧바로 outdated한 값이 되어버린다. 이럴 때엔 즉시 캐시 데이터를 stale 상태로 처리해줘야 한다.
렌더링을 효과적으로 관리함은 결국 성능 최적화에 직결되기 때문에 반드시 필요하다.
다음과 같은 방법들을 고려하여 우리의 프로젝트를 지끈지끈하지 않도록 만들어주자!
✔️ useMemo
✔️ React.memo 컴포넌트 메모이제이션
✔️ useCallback
✔️ 자식 컴포넌트의 props로 객체를 넘겨줄 경우 변형하지말고 넘겨주기
✔️ 컴포넌트를 매핑할 때에는 key값으로 index를 사용하지 않는다.
✔️ useState의 함수형 업데이트
setState를 사용할 때 새로운 상태를 파라미터로 넣는 대신, 상태 업데이트를 어떻게 할지 정의해 주는 업데이트 함수를 넣을 수도 있는데,
이렇게 하면 useCallback을 사용할 때 두 번째 파라미터로 넣는 배열에 값을 넣어주지 않아도 된다.
✔️ Input에 onChange 최적화