|
| 1 | +# REACT ERROR BOUNDARIES |
| 2 | + |
| 3 | +### Why? |
| 4 | + |
| 5 | +과거에는 애플리케이션 코드의 이전 단계에서 발생한 자바스크립트 에러를 React 컴포넌트 내에서 정상적으로 처리할 수 있는 방법을 제공하지 않아서 복구할 수가 없었다. |
| 6 | + |
| 7 | +UI의 일부분에 존재하는 자바스크립트 에러가 전체 애플리케이션을 중단시켜서는 안된다. 이를 해결하기 위해 에러 경계라는 새로운 개념이 도입되었다. |
| 8 | + |
| 9 | + |
| 10 | + |
| 11 | +## 에러 경계 |
| 12 | + |
| 13 | +> 하위 컴포넌트 트리의 어디에서든 자바스크립트 에러를 기록하며 깨진 컴포넌트 트리 대신 폴백 UI를 보여주는 React 컴포넌트이다. |
| 14 | +
|
| 15 | +다음과 같은 생명주기 메서드를 사용해서 에러 핸들링이 가능하다. |
| 16 | + |
| 17 | +#### getDerivedStateFromError() |
| 18 | + |
| 19 | +에러 발생 후 폴백 UI 렌더링할때 사용 |
| 20 | + |
| 21 | +#### componentDidCatch() |
| 22 | + |
| 23 | +에러 정보 기록할때 사용 |
| 24 | + |
| 25 | + |
| 26 | + |
| 27 | +### 에러 경계가 포착하지 않는 에러 |
| 28 | + |
| 29 | +#### 이벤트 핸들러 |
| 30 | + |
| 31 | +* 이벤트 핸들러는 렌더링중에 발생하지 않으므로 렌더링과 관련 없다. |
| 32 | + |
| 33 | +* `try`/`catch` 구문을 사용해서 에러 핸들링 할 수 있다. |
| 34 | + |
| 35 | +* [예제] |
| 36 | + |
| 37 | + ```react |
| 38 | + class MyComponent extends React.Component { |
| 39 | + constructor(props) { |
| 40 | + super(props); |
| 41 | + this.state = { error: null }; |
| 42 | + this.handleClick = this.handleClick.bind(this); |
| 43 | + } |
| 44 | + |
| 45 | + handleClick() { |
| 46 | + try { |
| 47 | + // 에러를 던질 수 있는 무언가를 해야합니다. |
| 48 | + } catch (error) { |
| 49 | + this.setState({ error }); |
| 50 | + } } |
| 51 | + |
| 52 | + render() { |
| 53 | + if (this.state.error) { |
| 54 | + return <h1>Caught an error.</h1> |
| 55 | + } |
| 56 | + return <button onClick={this.handleClick}>Click Me</button> |
| 57 | + } |
| 58 | + } |
| 59 | + ``` |
| 60 | + |
| 61 | +#### 비동기적 코드 |
| 62 | + |
| 63 | +* `setTimeout` |
| 64 | +* `requestAnimationFrame` 콜백 |
| 65 | + |
| 66 | +#### 서버 사이드 렌더링 |
| 67 | + |
| 68 | +#### 자식에서가 아닌 에러 경계 자체에서 발생하는 에러 |
| 69 | + |
| 70 | +--- |
| 71 | + |
| 72 | +[예시] |
| 73 | + |
| 74 | +```react |
| 75 | +class ErrorBoundary extends React.Component { |
| 76 | + constructor(props) { |
| 77 | + super(props); |
| 78 | + this.state = { hasError: false }; |
| 79 | + } |
| 80 | +
|
| 81 | + static getDerivedStateFromError(error) { |
| 82 | + // 다음 렌더링에서 폴백 UI가 보이도록 상태를 업데이트 합니다. |
| 83 | + return { hasError: true }; } |
| 84 | + componentDidCatch(error, errorInfo) { |
| 85 | + // 에러 리포팅 서비스에 에러를 기록할 수도 있습니다. |
| 86 | + logErrorToMyService(error, errorInfo); |
| 87 | + } |
| 88 | + render() { |
| 89 | + if (this.state.hasError) { |
| 90 | + // 폴백 UI를 커스텀하여 렌더링할 수 있습니다. |
| 91 | + return <h1>Something went wrong.</h1>; |
| 92 | + } |
| 93 | + return this.props.children; |
| 94 | + } |
| 95 | +} |
| 96 | +``` |
| 97 | + |
| 98 | +트리 내에서 하위에 존재하는 컴포넌트의 에러만을 포착한다. |
| 99 | + |
| 100 | +```react |
| 101 | +<ErrorBoundary> |
| 102 | + <MyWidget /> |
| 103 | +</ErrorBoundary> |
| 104 | +``` |
| 105 | + |
| 106 | + |
| 107 | + |
| 108 | +## 에러 경계 위치 |
| 109 | + |
| 110 | +### 최상위 |
| 111 | + |
| 112 | +서버 사이드 프레임워크가 충돌을 해결하는 것처럼 에러 메시지를 보여줄 수 있다. |
| 113 | + |
| 114 | +### 각 위젯 감싸기 |
| 115 | + |
| 116 | +에러 경계의 각 위젯을 여러 경계로 감싸서 애플리케이션의 나머지 부분이 충돌하지 않도록 보호할 수 있다. |
| 117 | + |
| 118 | + |
| 119 | + |
| 120 | +## 포착되지 않는 에러 동작 |
| 121 | + |
| 122 | +에러가 발생한 UI는 잘못된 동작을 발생시키거나 잘못된 데이터를 노출할 수 있기 때문에 남겨두는 것보다는 제거하는 것이 낫다. |
| 123 | + |
| 124 | +React 16 이후에는 포착되지 않는 에러로 인한 충돌을 발견할 수 있다. |
| 125 | + |
| 126 | +각 UI 영역을 나누어서 에러 경계를 추가함으로써 하나의 컴포넌트에서 충돌이 발생했을 때 나머지 컴포넌트는 유지될 수 있다. |
| 127 | + |
| 128 | + |
| 129 | + |
| 130 | +## 컴포넌트 스택 추적 |
| 131 | + |
| 132 | +React 16은 에러가 발생한 경우에도 렌더링하는 동안 발생한 모든 에러를 콘솔에 출력한다. |
| 133 | + |
| 134 | +Babel 설정을 통해 플러그인을 추가하는 경우 프로덕션 환경에서 비활성화 해야한다. |
| 135 | + |
| 136 | + |
| 137 | + |
| 138 | +## try/catch와 차이 |
| 139 | + |
| 140 | +에러 경계 컴포넌트는 어디서 에러가 발생하든지 가장 가까운 에러 경계에 전달된다. |
| 141 | + |
| 142 | +이처럼 에러 경계 컴포넌트는 무엇을 렌더링할지 구체화하지만, `try` /`catch`는 명령형 코드에서만 동작한다. |
0 commit comments