수정 작업의 시작
블루라이트 차단 모니터의 오류
그동안 로그인 로직만 계속 붙들고 있었어도, 수정해야 하는 요소들이 쏟아졌다.
특히, 블루라이트가 차단된 모니터로 볼때는 분명 없던 border가 화면 공유하면서 노트북 모니터화면으로 띄웠을때 선명한 것을 보고 혼자 소름 돋아했다며...
이걸 3주동안 모르고 있었다는게 충격이었다.
팀원들도 별말 없었던거 보면, 각자 자기 부분을 보느라 미처 몰랐을수도 있고, 회원가입 로그인 로직이 정말 그리 중요한 부분은 아니어서 그럴수도 있겠다.
어쨌든 이제 제대로 보이니 피그마는 무조건 노트북 화면으로 재확인을 하면서 수정을 하고 있다. 수정할때도 뷰는 노트북 화면에 띄우고, 코드를 모니터에서 보는 방식으로 바꿔야 했다.
에러 메시지는 토스트 대신 인풋
디자인 수정은 그렇다쳐도, 지금까지 에러메시지는 전부 토스트 메시지로 처리를 했었는데, 이것을 전부 인풋메시지로 전환해 달라는 디자이너님의 수정요청을 받았다.
여기서 한가지 문제가 생겼는데, 지금까지 잘 받아오던 에러메시지들이 출력되지 않는 것이었다. 백엔드에서는 분명 메시지를 제대로 보내주고 있었고, 코드수정도 없었다.
나 역시도 크게 코드가 바뀐 것이 없었는데, 도저히 콘솔에서 메시지 확인이 안되는 오류로 하루를 소비했다.
알고 봤더니 자동로그인 로직에서 오류가 있었던 것 같다. 쿠키가 자동으로 쌓이면서 생기는 오류로 종종 버그가 생겨서 결국 자동로그인 로직은 배포 과정에서 잠시 가려두기로 했다.
자동로그인쪽 에러를 수정하니 다시 에러메시지들이 잘 받아지는 것을 확인했다.
토스트 메시지를 띄우기 위해 받던 state대신, 인풋 메시지를 받기위한 state에 에러 메시지를 전부 싣기 시작했는데,
로직상 유효성 검사를 먼저하고, 그 다음에 중복된 이메일인지를 검사하고 거기까지 다 통과가 되어야 회원가입이 된다.
처음에 수정한 방법은 e.target.value 에 맞춰서 처음부터 에러가 출력되며 맞는 형식이 입력되었을때 에러가 멈추고 알맞은 형식이라는 메시지가 출력되었다.
하지만,유저가 처음부터 에러를 만나는 것이 미관상 좋아보이지 않아서 수정이 필요했다.
그래서 메일쪽은 onblur 속성을 활용해서 에러를 만나지 않고도 유효성검사를 할 수 있게 했는데, 비밀번호는 onblur로 처리하기에는 애매한 상황이었다.
유효성 검사 후 중복확인 검사
유효성 검사가 진행중임을 알리지 않고도 시작하기 버튼을 누른뒤 형식에 맞지 않았을때만 에러를 띄워야 한다는 미션이었다.
그래서 고민을 해본 결과,
유효성 검사 로직 안에 if문으로 조건을 달아서 유효성에 이상이 없을 때만 회원가입 함수가 작동되게 만들었다.
어떻게 풀어나가야 할지 막막했는데, 팀원분의 도움으로 의외로 쉽게 회원가입 mutation을 이메일 중복확인 mutation 안에 넣었고 새로운 함수안에 넣어서 그걸 유효성 검사로직 안에 심는 방식이었다.
로그인, 일반회원 회원가입, 공인중개사 회원가입에서 각각 버튼이 하는 기능이 조금씩 달라 혼란스러웠지만, 기본적으로는 유효성검사를 먼저하고 그 다음에 다음 로직을 실행하는 식으로 정리를 해서 수정했더니 에러없이 잘 고쳐졌다.
부족하다 느껴지는 부분
모션이 자연스럽지 못하다. 미디어 쿼리로 반응형이 구현되었을때 모바일에서 어떻게 보여질지 궁금했는데, 확실히 그냥 웹버젼을 모바일에서 볼때보다 뷰가 편하다. 하지만 스무스하다는 느낌이 들진 않는다. 어떻게 더 매끄럽게 처리를 할 수 있을지 고민을 해봐야 하지만, 지금까지 코드를 짜오면서 혹은 다른 팀원의 코드를 보면서 기본적인 부분이 부족하다고 느껴졌다. useeffect를 거의 쓰지 않았던 이유는 의존성 배열을 심어서 한번만 실행되게 하면 되는 로직이 회원가입 로그인에서는 필요하지 않다 판단해서 였는데, 그럼에도 사용할 줄은 알아야 하지 않을까 해서 다른 페이지 코드를 살펴보고 있다.
mutation을 새로운 함수에 집어 넣는 것도 충분히 생각할수 있었던 방식인데 떠올리지 못했고, 집어 넣을때도 화살표 함수를 잘 이용하면 되는 것을 적용하지 못한채 어버버 거렸다. 물론 그 다음부터는 생각의 전환이 빨라져서 수정작업을 하는데 어려움이 없었지만, 이렇게 간단한 로직은 빨리 처리를 해야 하지 않나 반성하게 되었다.
자동로그인... 분명 refresh토큰을 쿠키로 담아서 기존 토큰들이 만료될때마다 새로운 access 토큰을 요청하면 된다는 과정은 이해가 되지만 도대체 어떻게 구현을 해야할지 ... 어렵다..
