1. interceptor를 컴포넌트로 만들기
✅ 문제
처음엔 api에러시 공통 에러메세지를 팝업으로 띄우기 위한 interceptor를 js파일로 만들었다.
그랬더니 공통 에러 메세지는 자동으로 관리되지만, 팝업을 띄우기 위한 UI는 컴포넌트에서 별도로 구현해야했다.
✅ 해결
이러한 번거로움을 해결하기 위해 interceptor도 컴포넌트로 만들어 사용했다.
✅ 결과
→ 에러메세지 팝업창을 interceptor에서 한번만 관리하면 된다.
→ 단순히 로직만 공통하는게 아니라 UI까지 공통화 할 수 있어 더 편하다
→ 앞으로 확장성을 고려해 js가 아닌 컴포넌트로 만들어 놓는게 좋겠다고 생각됐다.
2. 인터셉터 관리하기 - eject
✅ eject메서드
: 여러개 인터셉터를 설정한 후, 특정 인터셉터가 더 이상 필요하지 않거나 조건에 따라 동적으로 제거해야 할때 사용한다.
✅ fake store에서 사용한 예

나는 인터셉터를 컴포넌트로 만들었기 때문에 컴포넌트가 destory 될 때 eject메서드가 실행되어
인터셉터가 제거되도록 처리했다.
그러나 인터셉터를 전역에 설정해줬기 때문에, 앱이 꺼지지 않는한 인터셉터가 계속 살아있다.
💡 이 상황에서도 eject메서드를 써야할까?
cleanup funtion 처럼 인터셉터를 설정을 해줬으면 혹시나 뺄 것도 고려하여 미리 eject를 달아줬다.
최근 회사에서 destory 될 때 이벤트 버스 off하는 로직을 신경쓰지 않아 난 버그 때문에 고생한 기억이 있다.
설정에 따른 제거의 중요성을 느꼈다.
✅ 특정 상황에서만 인터셉터를 설정하고,제거하는 법
나의 경우처럼 전역에 설정하는게 아니라, 필요한 때에 직접 인터셉터 설정하고 제거하는 법


출처 : https://github.com/axios/axios/issues/6219
3. interceptor Promise Chaining
return Promise.reject(error) 를 빼먹어서 난 문제!
프로미스 체이닝이 안되서, 컴포넌트까지 에러가 전파되지 않는다.
그래서 interceptor 내에서의 공통 에러처리 말고, 해당 컴포넌트에서 catch로 받아 별도 에러 처리가 필요한 경우
catch로 떨어지는게 없게된다.
공식문서의 예를 깊게 생각해보지 않았는데, 이번 기회를 통해 알게되었다.

4. interceptor의 프로미스가 컴포넌트까지 전달되지 않도록 하는 법
좋은 방법은 아닌 것 같은데, 이렇게도 할 수 있구나 싶었다.
컴포넌트에서 에러처리하는 로직이 없더라도, 확장성을 고려해 일단 모두 에러 객체를 반환해놔야 하지 않을까 싶다.
모든 인터셉터의 구조를 통일화 하기 위해서도 그게 낫다고 생각된다.
Axios interceptor로 API 응답 에러 처리하기
Axios interceptor로 API 응답 에러 처리하기 (feat. Promise Chaining)
velog.io
#fake-store
'프론트엔드' 카테고리의 다른 글
FTP와 SFTP에 대해, RSA에 대해 (0) | 2024.10.04 |
---|---|
css scope, scope 무시하기 (0) | 2024.09.22 |
📍피그마와 브라우저간 폰트 차이나는 현상 (0) | 2024.05.20 |
외부 CDN의 위험성 (0) | 2024.05.02 |
cors와 options메서드 (0) | 2024.04.28 |
1. interceptor를 컴포넌트로 만들기
✅ 문제
처음엔 api에러시 공통 에러메세지를 팝업으로 띄우기 위한 interceptor를 js파일로 만들었다.
그랬더니 공통 에러 메세지는 자동으로 관리되지만, 팝업을 띄우기 위한 UI는 컴포넌트에서 별도로 구현해야했다.
✅ 해결
이러한 번거로움을 해결하기 위해 interceptor도 컴포넌트로 만들어 사용했다.
✅ 결과
→ 에러메세지 팝업창을 interceptor에서 한번만 관리하면 된다.
→ 단순히 로직만 공통하는게 아니라 UI까지 공통화 할 수 있어 더 편하다
→ 앞으로 확장성을 고려해 js가 아닌 컴포넌트로 만들어 놓는게 좋겠다고 생각됐다.
2. 인터셉터 관리하기 - eject
✅ eject메서드
: 여러개 인터셉터를 설정한 후, 특정 인터셉터가 더 이상 필요하지 않거나 조건에 따라 동적으로 제거해야 할때 사용한다.
✅ fake store에서 사용한 예

나는 인터셉터를 컴포넌트로 만들었기 때문에 컴포넌트가 destory 될 때 eject메서드가 실행되어
인터셉터가 제거되도록 처리했다.
그러나 인터셉터를 전역에 설정해줬기 때문에, 앱이 꺼지지 않는한 인터셉터가 계속 살아있다.
💡 이 상황에서도 eject메서드를 써야할까?
cleanup funtion 처럼 인터셉터를 설정을 해줬으면 혹시나 뺄 것도 고려하여 미리 eject를 달아줬다.
최근 회사에서 destory 될 때 이벤트 버스 off하는 로직을 신경쓰지 않아 난 버그 때문에 고생한 기억이 있다.
설정에 따른 제거의 중요성을 느꼈다.
✅ 특정 상황에서만 인터셉터를 설정하고,제거하는 법
나의 경우처럼 전역에 설정하는게 아니라, 필요한 때에 직접 인터셉터 설정하고 제거하는 법


출처 : https://github.com/axios/axios/issues/6219
3. interceptor Promise Chaining
return Promise.reject(error) 를 빼먹어서 난 문제!
프로미스 체이닝이 안되서, 컴포넌트까지 에러가 전파되지 않는다.
그래서 interceptor 내에서의 공통 에러처리 말고, 해당 컴포넌트에서 catch로 받아 별도 에러 처리가 필요한 경우
catch로 떨어지는게 없게된다.
공식문서의 예를 깊게 생각해보지 않았는데, 이번 기회를 통해 알게되었다.

4. interceptor의 프로미스가 컴포넌트까지 전달되지 않도록 하는 법
좋은 방법은 아닌 것 같은데, 이렇게도 할 수 있구나 싶었다.
컴포넌트에서 에러처리하는 로직이 없더라도, 확장성을 고려해 일단 모두 에러 객체를 반환해놔야 하지 않을까 싶다.
모든 인터셉터의 구조를 통일화 하기 위해서도 그게 낫다고 생각된다.
Axios interceptor로 API 응답 에러 처리하기
Axios interceptor로 API 응답 에러 처리하기 (feat. Promise Chaining)
velog.io
#fake-store
'프론트엔드' 카테고리의 다른 글
FTP와 SFTP에 대해, RSA에 대해 (0) | 2024.10.04 |
---|---|
css scope, scope 무시하기 (0) | 2024.09.22 |
📍피그마와 브라우저간 폰트 차이나는 현상 (0) | 2024.05.20 |
외부 CDN의 위험성 (0) | 2024.05.02 |
cors와 options메서드 (0) | 2024.04.28 |