[4주차] 남기림 과제 제출합니다.

[GirimNam]

🔗배포링크
🗒️정리 링크

느낀 점

• 3주차까지는 타이포그라피나 컬러 팔래트를 잘못된 방식으로 사용했어서, tailwind가 별로 편하다고 생각하지 못했는데, @theme으로 수정한 뒤로는 상당히 편리하게 썼던 것 같습니다.
• Friends.tsx 파일과 ChatList.tsx 파일에서 모두 filter가 적용되게 만들었어야 했습니다. 필터 기능을 구현해본 적이 없어서 처음에는 버튼을 누를 때마다 새로운 페이지에 들어가야하나 생각했었는데 두 경우 모두 부모로부터 props로 건네 받은 함수 등을 사용하는 방식을 이용했습니다.
• 3주차의 채팅방을 다른 채팅방으로도 확장하기 위해서 props 부분 등 많은 내용을 수정했습니다. 3주차 때는 해당 내용조차 많다고 느껴 확장성은 고려하지 않고 주먹구구식으로 하드코딩한 부분이 많았어서 이번 주차 과제 초반에 수정 사항이 좀 많았습니다. 다음부터는 확장성과 수정의 편리성을 위해 컴포넌트를 세분화하고, 파일 간 유기성을 잘 생각하면서 구현해야겠다고 생각했습니다.
• 사용자를 즐겨찾기하고, 이를 다른 페이지에서도 적용되게 만들기 위해 상태 관리 라이브러리를 사용했습니다. 처음에는 이러한 상태관리 라이브러리를 사용하는 것도 처음이고, 프로젝트의 규모도 크지 않아 context api를 사용했으나, zustand로 바꿔서 사용했습니다. store 파일을 생성하고, 이를 useState처럼 사용하는 것이 생각보다 간단하다고 생각했습니다.
• 프로젝트의 규모가 그렇게 크지 않아 한 파일의 코드가 그렇게 길어지지는 않았지만, 최대한 컴포넌트를 분리하려고 했습니다. 맨 처음에 Chat.tsx 안에 ReadDiver와 DateDivder를 넣었지만, 이를 개별 컴포넌트로 분리 후 import하여 사용했습니다. 또한 프로필 목록에 나타나는 친구 프로필의 경우 공통 컴포넌트로 분리하여 여러 페이지에서 사용할 수 있게 하였습니다.

Review Questions

React Router의 동적 라우팅(Dynamic Routing)이란 무엇이며, 언제 사용하나요?

동적 라우팅이란 URL의 일부를 변수(파라미터) 처럼 다루는 방식입니다. 라우트 경로에 자리표시자를 두면, 실제 요청이 들어올 때 그 자리에 어떤 값이 오든 같은 컴포넌트로 처리합니다. 경로의 형태가 같으면 같은 페이지라는 것이 중요합니다. 예를들어 /products/1과 /products/999는 숫자만 다르고 상세 페이지 컴포넌트를 렌더링합니다. 웹 서비스의 대부분의 페이지는 데이터만 다르고 구조는 동일하기 때문에 이러한 동적 라우팅을 쓰면 효과적입니다. 정적 페이지는 경로를 하나하나 직접 명시하여 유연성이 낮고, 고정된 페이지에 사용하는 반면, 동적 라우팅은 변수 자리를 두고 런타임에 결정하여 유연성이 높고, 상품 상세페이지처럼 데이터 기반 페이지에 사용됩니다. 보통 쿼리 파라미터(useSearchParams)와 함께 사용됩니다. URL 파라미터와 함께 자주 쓰이는 쿼리스트링의 처리로 이루어집니다.

네트워크 속도가 느린 환경에서 사용자 경험을 개선하기 위해 사용할 수 있는 UI/UX 디자인 전략과 기술적 최적화 방법은 무엇인가요?

1. 스켈레톤 UI (Skeleton Screen)
   빈 화면 대신 콘텐츠 형태의 회색 박스를 먼저 보여줘 사용자가 로딩 중임을 인지하게 합니다.
2. Optimistic UI
   서버 응답을 기다리지 않고 UI를 먼저 업데이트한 뒤, 실패 시 롤백합니다. 그 예로 좋아요 버튼이 있습니다.
3. Infinite Scroll vs Pagination
   무한 스크롤은 한 번에 모든 데이터를 불러오지 않고 스크롤 시점에 추가 로딩하여 초기 부하를 줄입니다.

기술적 최적화 방법

1. 이미지 최적화: 네트워크 트래픽을 절감하는 효과가 있습니다.
2. 코드 스플리팅 (Code Splitting): 처음에 모든 JS를 로드하지 않고, 해당 페이지에 진입할 때 필요한 코드만 불러옵니다.
3. 데이터 캐싱 (React Query): 같은 데이터를 반복 요청하지 않도록 캐시하고, 백그라운드에서 자동으로 갱신합니다.

React에서 useState와 useReducer를 활용한 지역 상태 관리와 Context API 및 전역 상태 관리 라이브러리의 차이점을 설명하세요.

<지역 상태 관리>

1. useState: 단순한 지역 상태를 관리합니다. 초기 변수 설정 등 컴포넌트 하나에서만 사용하는 간단한 상태에 적합합니다.
2. useReducer: useState보다 조금 더 복잡한 지역 상태를 관리합니다. 여러 상태가 서로 연관되거나, 상태 변경 로직이 복잡할 때 사용합니다. Redux와 유사한 패턴으로 예측 가능한 상태 관리가 가능합니다.

<전역 상태 관리>

1. Context API: 전역 공유 및 단순 상태 관리에 적합합니다. Prop Drilling(부모→자식→손자로 props를 계속 내려보내는 문제)을 해결합니다. 자주 바뀌지 않는 전역 데이터(테마, 언어, 로그인 유저 정보)에 적합합니다. 그러나 Context 값이 바뀌면 해당 Context를 구독하는 모든 컴포넌트가 리렌더링되기 때문에 자주 변경되는 상태(장바구니, 알림 등)에는 부적합하다는 한계가 있습니다.
2. Zustand: 경량적인 전역 상태 라이브러리로, Context의 리렌더링 문제를 해결하고, 보일러플레이트 없이 간단하게 전역 상태를 관리합니다.

<비교>

• 상태가 단순하고 한 컴포넌트에서만 쓰인다. → useState
• 상태 변경 로직이 복잡하거나 여러 상태가 연관된다. → useReducer
• 여러 컴포넌트가 공유하지만 자주 바뀌지 않는다. (테마, 로그인 정보) → Context API
• 자주 바뀌고 여러 컴포넌트가 독립적으로 구독해야 한다. → Zustand / Jotai / Redux Toolkit