01) 통신의 선택
저번 포스팅에서 언급했듯 아쉬움이 남았던 부분을 해소하기 위해 프론트와 진짜로 백의 통신을 시도했다.
먼저, 어떤 통신을 할 지 고민했다.
기존 백엔드 단에서 포스트맨을 통해 회원가입을 했으니, 이번에는 로그인을 해봣다.
02) 패치 함수?
그런데, 단 2주만에 프론트 단에서 배운 패치 함수 통신 법이 제대로 기억이 안나는 것이었다....(내 머리는 돌인가?ㅋㅋ)
그래서 천천히 일단 로그인 페이지를 살폈다.
그랬다. 이제 기억이 조금씩 나기 시작했다. 해당 로그인 백 함수로 정의된 것 안에 패치함수가 보였다. 패치를 통해 결국 api를 할당 받고 해당 주소로 통신을 하는 것이 생각났다.
그래서 곧장 실행에 옮겼다. 기존 패치함수의 api주소를 필자의 백엔드 서버 로그인 api 주소로 변경했다. 그리고나서 두근반 세근반.
03) 뭐지 이 찝찝함은?
성공적으로 로그인이 된 것처럼 보인다. 허나!
그렇다. 아귀가 그랬다. 약 팔지 말라고...!
끝에 보인는 가? 개발자 도구에 찍힌 버얼건 글씨를!!!
뭔가 잘못 된 것이다. 눈치가 빠른 사람이면 벌써 눈치를 챘을 것이다.
힌트1.
힌트2.
그렇다. 힌트 1과 2를 조합해 보면, 결국 필자는 현재 db에 가입된 가입자가 아닌 이상한 랜덤 이메일과 비번을 적어서 다음 페이지로 인증처리를 해 버린 것이다.
더 자세한 오류는 힌트2의 백엔드 코드를 보면 알 수 있다. 401이 찍혔다. 그건 결국 인벨리드 유저다. 즉, 존재하지 않는 사용자라는 뜻이다.
이러면 굳이 가입과 db가 필요없지 않겠는가?
04) 문제는 코드에 있다!!!
그래서 고민을 좀 해 봤다.
흠... 일단, 백엔드에서 처리는 가는데, 그걸 받아서 프론트에서 다음 이동은 막아야 하지 않을까?...
그때.. 기존 패치 함수를 적어둔 코드가 눈에 들어왔다.
앗! 드디어 눈에 들어온 무언가... .then 이하의 코드가 문제로 보였다. 결국 .then은 프로미스다! 위의 처리가 끝나면 다음 처리로 어떤 것을 할 것인지 프론트 개발자가 정의하는 것이었다. 그런데 지금 코드를 보면....
그렇다. 백엔드로부터 받은 응답을 그냥 받기만하면 바로 네비게이트 시켜주고 있다. 그래서 저런 말도 안 되는 상황이 벌어진 것이다.
05) 코드 추가!!!
그래서 .then이후에 해당 리스폰스에 따른 조건을 세분화 시켜서 분리를 해줬다. 그랬더니... 드디어 원하는 대로 실행이 되기 시작했다. 다만, 여기서도 한 가지 문제가 생기는 데 이부분은 아래에서 후술하겠다.
06) 니가 왜 거기서 나와?
뭔가 이상함을 감지하신 분 계신가?
그렇다. 지금 웰컴 알러트 이후에 뜬금없이 에러 알러트가 추가로 나온다. 이유는 또 당연히 되겠지 하는 섣부른 판단이었다. 필자는 401과 409 에러를 그냥 같은 조건문에서 처리를 해주려고 했었다. 하지만 이렇게 하니... 결국 저렇게 에러 처리가 아닌데도 인식하지 못하고 알러트가 찍혀 나오는 경우가 나왔다.
그래서 그때 느꼈다. 아무리 그래도 다른 조건인데, 다르게 표시해야겠구나...
그러자 이제 모든 조건에 맞게 잘 구현되었다~~
good!😁
이렇게 새로운 통신을 하기 위한 과정이 엄청나게 트러블 슈팅과 맞서 싸워야 한다는 것을 알게된 순간이라 행복하다. 뭔가 재밌기도 하고, 알아가면 알아갈수록 하나씩 채워가는 맛이 있는 것 같다.
또 다시 문제가 생기면 다시 돌아오겠다~ ㅎㅎ
