에러는 피하는 것이 아니라 설계하는 것이다 React 애플리케이션을 운영하다 보면 반드시 마주치는 순간이 있습니다. 서드파티 API가 갑자기 응답을 거부하고, 예상치 못한 형태의 데이터가 렌더 함수 안으로 흘러들어 오고, 네트워크가 불안정한 모바일 환경에서 Suspense로 감싼 컴포넌트가 영영 해소되지 않는 상황입니다.
카테고리
React
총 5편의 글
React의 렌더링, 상태 관리, 에러 처리, Suspense 패턴을 제품 코드에서 안정적으로 운영하는 방법을 다룹니다.
- 적용 대상
- 복잡한 React 애플리케이션을 운영하는 프론트엔드 개발자
- 주요 초점
- 렌더링 제어상태 관리에러 UX
메인 스레드가 막히는 순간, UI는 사용자를 배신한다 React 애플리케이션에서 "왜 필터를 클릭했는데 선택이 늦게 반영되지?"라는 질문을 받아본 적이 있을 것입니다. 필자가 속한 팀에서는 수십만 건의 거래 내역을 보여주는 어드민 대시보드를 운영하면서 정확히 이 문제를 마주했습니다.
서버 상태는 클라이언트 상태와 다르다 React 애플리케이션에서 상태 관리를 이야기하면 전역 store부터 떠올리기 쉽습니다. 하지만 화면에 보이는 데이터 중 상당수는 클라이언트가 소유한 상태가 아닙니다. 사용자 목록, 주문 상태, 알림 개수, 결제 내역은 서버가 진짜 소스입니다. 클라이언트는 그 시점의 스냅샷을 잠시 들고 있을 뿐입니다.
모던 React 상태 관리: Redux의 시대를 넘어선 새로운 패러다임 React 개발에서 "상태 관리(State Management)"는 영원한 화두입니다. 2015년 Dan Abramov가 Redux를 세상에 내놓은 이후, 프론트엔드 생태계는 사실상 Redux의 독주 체제였습니다.
React Server Components(RSC) 아키텍처: 단순한 기능 추가를 넘어서는 웹 렌더링의 패러다임 시프트 2024년 이후 프론트엔드 개발 생태계에서 가장 자주 논쟁이 오간 주제는 단연 React Server Components(RSC) 와 Next.js App Router 입니다.