[Frontend] Troubleshooting 기록 - 회원가입 로직

문제점

임시회원이 회원가입을 하는 요청을 전송할 때 기존 임시회원 id를 보내지 않는 문제가 발생했다

배경

회원가입 페이지의 useEffect에서 auth0 인증의 callback을 탐지해 회원 정보를 생성하는 요청을 보낸다. 그러나 인증정보 컴포넌트의 useEffect가 먼저 실행되어 임시회원의 인증정보를 지운다. 따라서 회원가입 요청을 보내는 시점에서는 임시회원의 id가 이미 지워져 있었다.

기존에는 이를 해결하기 위해 backup을 사용했으나, 백업 시점이 임시회원 id가 이미 지워진 후라 정상 작동하지 않았다.

해결법

그러나 인증정보 삭제 이전에 백업 코드를 넣기보다는, 임시회원 인증정보가 지워지는 시점을 회원가입 요청 성공 callback으로 변경하여 회원가입 요청을 보내는 시점에는 임시회원 인증정보가 남아있게 처리했다. 인증정보 컴포넌트의 useEffect에서 임시회원 인증정보를 지우는 코드를 삭제했다.

왜?

auth0 인증 정보는 있으나 회원 정보가 없는 상태를 회원 가입 중인 상태로 생각했다. 회원 가입 중인 상태에서 입력받은 회원정보를 저장하고 있다가 요청을 보내는 것처럼 임시회원이 회원으로 전환할 때도 임시회원 정보를 저장하고 있는것이 타당하다고 생각했다.

나아진 점은?

같은 데이터를 원본 인증 정보, 백업으로 중복하여 저장하지 않아 관리포인트가 줄었다. 이전에는 특히 백업 데이터를 언제 지워야 할지가 모호했다.

단점은?

인증정보 컴포넌트의 useEffect를 사용하면 회원 타입이 바뀔 때 임시회원 정보가 삭제되는 것을 effect로 보장한다. 그러나 회원가입 요청의 callback으로 처리하는 방법은 만약 다른 방법으로 임시회원이 다른 타입으로 변경된다면 임시회원 정보를 지우는 코드를 다시 작성해야 한다. 그러나 임시회원이 회원 타입을 바꾸는 다른 방법이 없고, 생기지 않을 것 같아서 (슈퍼회원가입 같은게 없다면) 현 상황에서는 적절한 설계이다.

개선할 점은?

현재 회원가입 요청성공 로직이 callback으로 작성되어 있는데, async/await으로 수정하면 가독성이 높아질 것이다. lazyQuery도 아니라서 async/await 쓰면 된다.

쓰다 보니 생각난건데 회원 타입을 auth0 인증 받았는가로만 회원을 구분하지 않고 (auth0 인증 + 회원정보 없음)을 새로운 회원 타입으로 정의해서 effect를 걸어주는 방법도 있을 것 같다