상태 관리는 라이브러리 선택이 아니라 소유권, 렌더링 위치, 생명주기 설계다React 프로젝트를 시작하면 상태 관리는 대체로 단순하다. const [isOpen, setIsOpen] = useState(false);const [keyword, setKeyword] = useState("");const [selectedId, setSelectedId] = useState(null); 하지만 프로젝트가 커지면 질문이 달라진다.이 상태를 useState에 둘까?Context에 둘까?Zustand에 둘까?TanStack Query에 둘까?URL에 둘까?Server Component에서 가져올까?Server Action으로 바꿀까?localStorage에 저장할까? 상태 관리가 어려워지는 이유는 상태가 많아져서만..

상태 관리는 “어디에 저장할까”가 아니라 “누가 소유하는가”의 문제다프론트엔드 애플리케이션이 작을 때 상태 관리는 단순해 보인다. const [user, setUser] = useState(null);const [isModalOpen, setIsModalOpen] = useState(false);const [keyword, setKeyword] = useState(""); 하지만 기능이 늘어나면 상태는 빠르게 복잡해진다.사용자 정보, 권한, 상품 목록, 검색 필터, 페이지 번호, 모달 열림 여부, 폼 입력값, 선택된 행, 정렬 조건, 알림 배지, 로딩 상태, 에러 상태, 캐시, WebSocket 메시지, optimistic update까지 모두 “상태”라는 이름으로 섞이기 시작한다.이때 많은 팀이 다음 ..

React를 처음 배울 때 우리는 보통 컴포넌트 생명주기를 다음 세 단계로 이해한다.Mount → Update → Unmount컴포넌트가 화면에 처음 나타나고, 상태나 props가 바뀌면서 다시 렌더링되고, 더 이상 필요 없어지면 화면에서 제거된다. 이 설명은 틀리지 않다. 하지만 현대 React를 실무에서 제대로 사용하려면 이 정도 이해만으로는 부족하다.특히 함수 컴포넌트와 Hooks 중심의 React에서는 생명주기를 단순히 componentDidMount, componentDidUpdate, componentWillUnmount에 대응시키는 방식으로 이해하면 오히려 코드를 잘못 설계하기 쉽다.React의 생명주기를 제대로 이해하려면 다음 질문으로 접근해야 한다.컴포넌트는 언제 다시 실행되는가?렌더링은..

Next.js는 React를 기반으로 구축되고 서버에서 렌더링되는 React 애플리케이션용으로 설계된 인기 있는 오픈 소스 JavaScript 프레임워크이다. 간단하고 직관적인 개발자 경험을 제공하여 빠르고 확장 가능한 웹 애플리케이션을 쉽게 만들 수 있다. 이 글에서는 Next.js가 서버에서 렌더링되는 React 애플리케이션의 미래인 5가지 이유를 정리해보았다. 자동 코드 분할 (Automatic Code Splitting) Next.js는 요청 시 로드할 수 있는 작은 청크로 코드를 자동으로 분할하므로 로드 시간이 단축되고 사용자 경험이 향상된다. 서버 사이드 렌더링 (Server-Rendering) Next.js를 사용하면 서버에서 React 컴포넌트를 렌더링할 수 있으므로 웹 애플리케이션의 성능..

React 16.8 버전에서 Hook이 발표되고 난 후 React에서 컴포넌트를 선언하는 방법의 대세는 클래스 컴포넌트에서 함수 컴포넌트로 옮겨왔다. 많은 사람들이 익숙하고 이미 기존에 많은 코드들이 작성된 방법인 클래스 컴포넌트에서 함수 컴포넌트로 옮겨온 이유 중에는 함수 컴포넌트의 문법이 더 단순하고 교착상태로 인한 버그가 발생하지 않는다는 장점도 있지만, Custom Hook의 편리함과 유용성도 큰 비중을 차지하고 있다. 리액트는 UI를 구축하기 위한 라이브러리로 리액트가 가진 핵심적인 관심사는 UI와 UI를 변경시키는 로직이다. 이 중 UI는 실제 코드상에서는 JSX라는 형태로 표현되고, UI 변경 로직은 유저의 입력에 반응하거나 API를 호출하고 스크린의 변화에 반응하는 등 여러 동작들을 통해서..

Context API란? React에서 제공하는 내장 API로서 컴포넌트들에게 동일한 Context(맥락)을 전달하는 데 사용할 수 있다. 일반적으로 리액트에서 데이터를 전달하는 기본 원칙은 단방향성으로 부모 컴포넌트에서 자식 컴포넌트 방향으로만 데이터를 전달할 수 있다. 단방향성은 애플리케이션의 안전성을 높이고 흐름을 단순화하는데 유용하지만 때때로 너무 많은 단계를 거쳐서 자식 컴포넌트에 데이터를 전달해야 한다는 문제점을 야기하기도 한다. 예를 들어 5단계 아래에 위치한 자식 컴포넌트에게 데이터를 넘겨야 한다면, 중간에 4개의 컴포넌트는 해당 데이터를 사용하지 않을지라도 props를 계속해서 넘겨줘야 하는 문제가 발생하고, 형제 관계나 특정 범위 안에 있는 컴포넌트들에게 데이터를 넘기기 위해서는 더 복..

7주 차에는 실제 서비스하는 앱을 보고 따라 만드는 클론 코딩 프로젝트를 진행했다. 물론 모든 걸 따라 만들 수는 없으니 일주일 안에 가능한 최소 스코프를 정하고 개발을 시작했다. 우리 팀은 트위터를 주제로 정했고 팀원은 총 7명으로 프론트엔드 4명은 백엔드는 3명이었다. 나는 이번 부트캠프에서 팀장을 세번 맡았었는데, 이번 클론 코딩에서도 팀장을 맡았다. 처음에는 팀장이라는 자리가 부담스러웠는데, 계속 팀장을 하다 보니 팀의 리더로서 팀원을 챙기고 이끌어나가는 게 재밌어졌다. 어쩌면 나도 몰랐던 적성을 찾은 것 같다. 우리 팀의 개발 스코프는 아래와 같이 잡았다. User 로그인 회원가입 로그아웃 소셜 로그인 Profile 사용자 프로필 조회, 수정 팔로우, 언팔로우 조회, 추가, 취소 Tweet 작성..