Facts
- 지하철 노선도 미션 피드백을 반영했다.
Feelings & Findings
지하철 노선도 미션 피드백을 반영했다.
11개의 피드백을 받았고, 가장 오래걸릴 것 같은 피드백부터 반영을 시작했다.
- HTTP Client로 request를 하는 것들의 중복을 없애기
- 라우트를 이동할 때마다 api요청을 하지 않도록 구현하기 - api 요청 최소화
- try-catch로 에러 처리하기
HTTP Client로 중복 없애기
처음에 피드백을 받고 HTTP Client 클래스를 만들어야겠다는 생각을 했다.
fetch(`${API_END_POINT}/login/token`, {
method: METHOD.POST,
body: JSON.stringify({
email,
password,
}),
headers: {
'Content-Type': 'application/json; charset=UTF-8',
},
});uri, headers, body, method 등이 중복되어 사용된 코드가 많았다.
하지만 어떤식으로 묶어야 할 지 감이 잡히질 않았다. 고민하던 끝에 다른 크루들의 pr을 봤는데, httpClient라는 객체를 만든 크루가 있었다.
fetchOptions 함수에 위에서 중복되어 사용되던 코드를 모두 옮겨놨다.
그러고 httpClient는 get과 post 메서드를 가지고 있는데, fetch(uri, fetchOptions())처럼 사용되고 있었다.
코드를 보고 이렇게까지 할 수 있다는 것에 놀랐다. 그래서 허락을 받고 따라했다.(ㅋㅋ)
중복 제거를 위해 더 많은 신경을 써야겠다고 느꼈다.
라우트를 이동할 때마다 api요청을 하지 않도록 구현하기 - api 요청 최소화
이건 구현을 하면서도 계속 고민을 했던 부분이었다. 아무래도 라우트를 이동할 때마다 api 요청을 하면 성능에 좋지 않을 것이다. 게다가 라우트를 할 때 렌더도 같이 하고 있는데, 결국 렌더가 비동기가 된다.
그래서 어떻게든 api 요청을 최소화하기 위해서 메인 화면을 클릭했을 때만 api 요청을 하도록 했는데, 이것도 좋은 방법은 아니었다.
그러다가 리뷰어님의 피드백을 받고 api 요청이 필요한 때에 로그인이 풀려있으면 로그인 페이지로 이동시키는 것이 좋다는 것을 알게 되었다.
지하철 노선도 미션 같은 경우에는 노선을 추가하거나 제거할 때 서버에도 저장되어야 하기 때문에 api 요청이 반드시 필요하고, 이때 로그인이 풀려있으면 로그인을 요청하면 된다.
굳이 라우팅 할 때마다 api 요청을 할 필요가 없었던 것이다.
하지만 메인페이지에서 로그인 상태에서는 메뉴바가 모두 보이고, 로그인이 되지 않은 상태에서는 로그인 메뉴만 보여야 하기 때문에 메인페이지를 클릭했을 때 어떻게 api 요청을 하지 않고 로그인이 되었는지 알 수 있을까? 에 대해서 많은 고민을 했다.
우리는 토큰을 사용하기로 했다. 토큰은 만료 기간을 정할 수 있어서 서버의 로그인 유지 기간인 1시간을 만료 기간으로 정해서 토큰이 존재하면 로그인이 된 상태라고 판단하기로 했다.
토큰이 존재하는지 여부도 js가 로드될 때 처음 한번만 확인하고, 상태로 저장해서 관리하도록 했다. 아직 세션스토리지에 저장되어 있고, 토큰을 사용하지는 않았지만 충분히 가능할 것이라고 생각한다.
토큰으로 구현해보고 내일 결과를 작성해보겠다.
try-catch로 에러 처리하기
하루종일 try-catch로 에러 처리하기를 공부한 것 같다.
try-catch는 사용해본 적도 없고, 잘 사용하지 않는줄 알았는데 엄청 유용하다는 것을 깨달았다.
우선, 에러가 발생하면 무조건 catch에서 잡힌다. try에서 throw로 던져주는 것도 catch로 잡힌다.
그래서 try-catch를 사용하면 if문을 사용하지 않을 수 있게 된다.
fetch 요청을 하는 함수에서 response.ok가 false일 경우 throw new Error()로 catch로 전달하고, catch에서는 또 throw new Error()로 error를 전달해준다고 생각해보자.
이 경우에 fetch 요청을 하는 함수를 사용하는 곳에서 또한 try catch로 사용할 수 있다.
fetch를 사용하는 함수 실행 => fetch 요청 => response.ok === false => throw new Error() => catch에서 잡힘 => throw new Error() => fetch를 사용하는 함수의 catch에 error가 잡힘
이 순서대로 진행되게 된다.
즉, fetch를 사용하는 함수에서 if문으로 error가 발생한 경우~~ 이런식으로 하지 않고
try{
await requestFetch();
console.log('success');
} catch(error) {
console.log(error.message, 'error')이렇게 사용할 수 있다.
가독성이 매우 좋아진다는 것을 알게 되었다.
그리고 비동기 상황에서는 항상 에러가 발생할 수 있기 때문에 async await을 사용하는 모든 곳에서는 try-catch로 에러 처리를 해주는 것이 맞다고 생각이 되었다.
많이 연습한 것 같다. 6시간 이상은 try-catch만 공부했다.
이렇게 3개를 구현하고, 완벽하게 하지도 못했지만 10시간 이상은 했다.
페어가 7시에 스터디가 있어서 스터디 끝난 후인 10시부터 11시까지 간단하게 1시간만 더하고 끝내려고 했는데, 하다보니 재밌기도 하고 오기가 생겨서 2시가 넘어서 끝이 났다.
해결하지 못할 것을 3개나 해결한 것 같은 기분이라서 뿌듯하지만 내일 일어날 수 있을지가 걱정된다.
Plans
- 지하철 노선도 미션 피드백 모두 반영하기
- 지하철 노선도 미션 pr 보내기
