2단계 회고
이번 미션을 통해서 처음으로 json-server-auth를 사용하여 로그인 기능을 구현해보았다!
인터넷 프로그래밍이라는 전공과목 시간에 로그인 기능을 구현해본 적은 있지만, json-server-auth라는 건 처음 써봤기에, 걱정이 좀 됐었다.
그렇지만 준이 준비한 인증과 인가 미니 실습을 통해서, 미션에 들어가기에 앞서 크루들과 연습을 해볼 수 있었다. 덕분에 홀로 미션을 진행할 때에, 빠르게 적용해 볼 수 있었다.
1단계의 구조를 그대로 가져왔기 때문에, 기능 요구사항들을 구현하는데에 생각보다 오랜시간이 걸리지는 않았다. heroku가 어려웠을 뿐...
heroku를 사용하게 된 이유는 다음과 같다. json-server-auth를 사용해서 구현한 것은 로컬 백엔드 서버로, 프로그램의 원할한 작동을 시키기 위해서는, 로컬에서 백엔드 서버를 따로 열어야 하는 작업이 필요하다.
그런데 깃허브 페이지를 통해서 배포를 했을때, 해당 작업을 할 수 없다. 그래서 heroku라는 클라우딩 컴퓨팅 서비스를 활용하여, 로컬 백엔드 서버의 역할을 원격으로 통신할 수 있는 heroku에 넣어줘서, 그곳과 통신을 하도록 바꾼다. 이렇게 되면, 깃허브 페이지를 통해서 배포를 했을 때에도 프로그램이 원할하게 작동 할 수 있게 한다.
초반에는 조금은 삽질을 했었다. 간단히 heroku에 올릴 레포지터리를 따로 파서 서버로 연동하면 됐었는데(=기버 크루들 덕분에 쉽게 방법을 알 수 있었다!👍), 왠지 한 저장소에서 해결하고 싶어! 라는 마음 때문에 여러가지로 시도를 해보다가 결국 gg를 선언하고 새롭게 저장소를 파서 heroku서버를 연동했다.
그런데 그 과정속에서도 계속 json-server패키지를 찾을 수 없다는 에러가 발생하였다. 결론적으로는 package.json의 devDpendencies에 나열되어 있는 패키지들을 depencies에 옮긴뒤 다시 npm install을 하니 에러가 최종적으로는 해결되었다.
이유를 추정하자면, heroku가 json-server등의 패키지들을 설치를 한 뒤에 실행이 되어야 한다. 그런데 devDpendencies는 로컬 개발에 필요한 패키지들을 두는 곳이고 dependencies는 프로덕션 환경에서 응용 프로그램에 개발한 패키지들을 두는 곳이여서 heroku 가 인식을 못한 것 같다.
(사실, 이것 저것 많이 건들이면서 된거라 정확한 이유인지는 모른다...😢)
구조도
저번 단계에 이어 구조도를 작성했다.
구조도를 그리는 것이 귀찮고 은근 시간도 많이 드는 일이긴 하지만, 다른 사람들에게 나의 코드를 설명할 때에 더 편하고 다시 한번 코드를 어떻게 짰는지 정리해 볼 수 있는 기회가 되어서 장점이 더 많다.
앞으로도 구조도를 그려 볼 생각이다.
질문에 대한 답변들
Q1
이번 미션에서는 step1에서 자판기의 데이터가 바뀌면, store에서 render를 직접적으로 요청하는 것과 달리, 유저의 인증과 관련된 활동(로그인, 회원가입 등등) 을 처리하고 나면 location href를 변경하는 방식으로 render를 진행하였습니다. 이런 식으로 처리한 이유는, 저의 지금 코드에서는 로그인, 회원가입등의 활동을 처리한 후에는 모두 홈 화면 (=상품구매화면)으로 이동하게 됩니다. 이 때에 주소 변경을 감지하여 component 폴더 내의 index.js의 showSectionByRoute를 통해서 조건에 맞게 새롭게 렌더링이 됩니다. 그래서 굳이 authStore에서 렌더링 요청을 하지 않아도 주소를 변경함으로서 렌더링 요청을 하게 된 것이라고 생각하여 해당 방식으로 진행하였습니다. 해당 구조에 대한 리뷰어님의 의견이 궁금합니다. 3번에서도 질문하는 사항이 있지만 약간의 문제상황이 발생하여서 해당 방식대로 진행하는 것에 대해서 추가적인 잠재적인 오류들이 있는지 궁금합니다.
A1
authStore에서 렌더링을 하지 않을 경우 auth 상태가 바뀔 때 무조건 주소를 변경하는 게 직관적이지 않다고 생각합니다. 권한이 있어야 접근할 수 있는 private 경로와 모두 접근할 수 있는 public 경로가 있습니다. public 경로임에도 불구하고 로그아웃 시 무조건 home경로로 이동하는 건 유저 경험에 좋지 않을 거 같습니다.
=> 현재 나의 프로그램 구조 상 모든 인증과 인가 관련된 활동이 끝나고 모두 ,home인 상품 구매 탭으로 이동한다.
이 부분에 대해서 리뷰어 분이 지적해주셨는데, 현재 로그 아웃시에는 상품관리, 잔돈 충전 등에 접근하지 못하고 상품 구매 탭에만 접근이 가능하기 때문에 그런식으로 처리를 했던 것인데 아직 감이 잘 안잡힌다.
Q2
현재 회원정보 수정과 유저 프로필 렌더링에서 userInfor과 활용되고 있습니다. userInfo의 경우(email과 name이 저장되는 곳) 서버에 localStorage에 저장된 userId를 활용하여 정보를 요청하고, 응답 값을 localStorage에 저장하는 방식으로 처리하고 있습니다. 이 부분의 처리 방식을 두고 고민을 하였는데요. 서버에 값을 요청할 필요 없이 localStorage에 유저의 정보와 관련된 값이 mutate를 통해서 들어왔을 때에 바로 userInfo에 저장을 하면 더 간편하고 서버와의 통신에 의해 발생하는 비용도 절약 할 수 있다는 생각이 들었습니다. 그런데 '서버와의 통신한다는 개념에 있어서 유저의 정보를 서버를 통해서 받아오는 것이 맞지 않을까? '라는 생각으로 위의 방식으로 처리하게 되었는데요. YAGNI를 한건가 라는 생각도 들어서 해당 부분에 대해서 의견을 들어보고 싶습니다.
A2
실제 서비스라고 생각하면 유저 정보는 서버를 통해서 받아오는 것이 맞습니다 :) 최소 기능 구현이라도 서버 통신이 들어가기 때문에 고려하고 작업하는 게 좋다고 생각합니다.
=> 이 부분에 대해서는 프로그래밍을 하면서도, 로컬스토리지에 유저 정보를 저장해 두고 사용하면 훨씬 편한데, 쓸데없이 요청을 두번하고 있나 라는 고민이 들었는데 괜찮다고 하시니 안심이 되었다.
Q3
logout처리와 관련해서 궁금한점이 있습니다! 현재, 저의 코드에서는 페이지가 reload가 되면 자판기에 저장된 상품, 잔돈 관련 정보들이 모두 날아가기 때문에 새로고침을 해서는 안되는 상황입니다. 다른 기능들의 경우 처리 완료후 자신이 있는 페이지에서 다른 페이지로 이동하기 때문에 render를 쉽게 할 수 있었습니다. 그런데, 상품 구매 탭에서 로그아웃을 할 경우 로그 아웃 후 가는 주소와 로그아웃 하는 주소가 모두 #로 같아 바로 로그 아웃 된 화면으로 렌더링 되지 않는 문제가 발생하였습니다 . 주소가 변할때만을 감지하여 렌더링을 진행하였기에 발생하는 문제였습니다. 그래서 현재 꼼수로 로그아웃을 할 경우 다른 주소로 이동을 한 뒤에 #으로 이동하는 식으로 문제를 처리 하였습니다. 현재 이를 해결하는 방식으로 자판기의 아이템들을 모두 localStorage에서 관리하거나, 정보가 변할 때마다 렌더링을 요청하는 구조로 다시 바꾸는 방법 2가지를 생각하고 있습니다. 혹시 더 좋은 처리 방법이 있을지 아니면 현재 방식대로 진행해도 괜찮을지 의견이 궁금합니다!
A3
새로고침 한 상황이라면 서버에 데이터를 요청해서 상태를 다시 받아오면 될 거 같습니다. 지금은 서버가 없으니까 로컬스토리지에 요청해서 상태를 갱신하면 되겠군요. 기대 상황: 로그아웃 할 경우 로그아웃 상황에 맞는 화면으로 렌더링 돼야 함 문제 상황: 상품 구매 탭 주소와 로그아웃 주소가 모두 # 이라서 라우터가 동작하지 않음 해결 방법: 다른 주소로 보냈다가 다시 #으로 보냄 -> 다른 주소를 바꾸는 것도 해결방법이군요. 제가 제안드리고 싶은 방법은 샐리님이 말씀하신대로 상태가 바뀔 때 렌더링 요청입니다. (현재 구조상 파악하기 더 쉬울 거 같습니다) 로그아웃 되면서 auth 상태가 바뀌니까 그때 자연스럽게 렌더링 요청하면 될 거 같네요.
=> 로그 아웃에 대한 처리의 경우 마지막까지 고민을 하였다. 왜냐하면 상품 구매 탭이 기본 탭으로 설정이 되어 있고, 로그 아웃 시에도 가야할 곳에 상품 구매 탭이다. 그래서 다른 페이지에서 로그아웃을 처리할 경우 아무런 문제가 발 생하지 않지만, 상품구매 페이지에서 로그아웃을 할 경우 같은 페이지로 이동하도록 되기 때문에 자동으로 화면이 렌더링 되지 않는다.
하지만 그렇다고 새로고침을 하게 되면, 자판기에 저장된 상품 정보들이 모두 날아가 버린다. 그래서 임시로 로그아웃의 작업의 경우, 다른 페이지로 이동을 시키고 홈 화면으로 다시 이동 하는 방식으로 했었다.
snackbar 구현하기
피드백을 반영하는 과정에서 기존에 snackbar가 존재하면, snackbar가 더 이상 보이지 않도록 처리하였다.
이는 snackbar을 호출하는 버튼등을 유저가 연속적으로 클릭하였을때에 보일 수 있는 UX적 에러를 잡기 위함이였다.
예를 들어, 연속적으로 클릭되었을때 해당 snackbar의 멘트와 이후의 snackbar 멘트가 제대로 보이지 않는 등의 문제가 있다.
그런데 리뷰어님께서 debounce를 활용하여 기존에 snackbar가 존재하더라도 새롭게 호출하는 방식으로 개선한다면 더 나을 것 같다는 의견을 주셨다.
