Error Boundary

Error Boundary는 클래스형 컴포넌트로,라이프사이클 메서드를 사용하여 리액트 컴포넌트 트리에서 자식 컴포넌트의 에러를 잡아내고, 내부 state가 변하여 대체 UI를 렌더링하는 역할을 합니다. 이를 통해 애플리케이션이 전체적으로 중단되는 것을 방지할 수 있습니다.

저는 이미지 처럼 에러의 경우에 따라서 component level , page level, global level 까지만 에러가 전파되어야 한다고 생각했습니다. 그리고 그 에러는 해당 레벨의 Error Boundary에서 잡혀, 적절한 대체 UI를 렌더링해야 한다고 생각했습니다.

그럼 어떤 에러가 어떤 에러 바운더리까지 전파되어야 하는 걸까요? 저는해당 에러로 인해 사용자가 어느 부분까지 사용을 못하는 상황일지를 유추하여 판단해야 한다고 생각했습니다.

예를들어, 저는 아래 예시에서 에러 바운더리가 동작하는 레벨을 상태코드를 기준으로 구분했습니다. 400번 에러는 컴포넌트 레벨, 401번 에러는 페이지 레벨, 500번대 에러는 글로벌 레벨에서 처리되도록 설계했습니다.
400번 에러는 주로 클라이언트 측 문제로, 특정 컴포넌트에 국한된 경우가 많아 해당 컴포넌트를 사용하지 못하는 상황이라고 생각했습니다.
반면에 401번 에러는 인증 문제로 인해 페이지 전체에 영향을 미칠 수 있으므로 해당 페이지의 다른 부분도 사용하지 못할 가능성이 높은 상황일 것이라고 생각하고 페이지 레벨에서 처리하는 것이 타당하다고 생각했습니다.
마지막으로 500번대 에러는 서버 측 문제로, 애플리케이션 전체에 영향을 줄 수 있어 글로벌 레벨에서 처리하는 것이 가장 효과적이라고 보았습니다.

이 구분은 절대적인 것은 아니며, 실제 서비스에서는 에러 상태에 따른 전파 레벨을 컨벤션화 하여 체계적으로 설정하고, 그에 따른 커스텀 에러를 발생하거나 백엔드 측에서 적절한 response를 전달하여, 클라이언트에서는 그에 맞는 레벨까지 에러를 전파시키면 될 것 입니다.

아래의 네모 박스 컴포넌트는 component level error boundary로 감싸져 있습니다 , 박스 아래의 버튼을 클릭하면, 해당 레벨 까지 에러가 전파되고 적절한 Fallback UI를 보실수 있습니다.

아래 버튼을 누르시면 좀더 자세한 설명과 함께 예시 컴포넌트를 동작시킬 수 있습니다.