[이슈트래커] 개발일지2

🎈2주차 PR

• 0614(mon)
  -React.lazy 적용해보았다. lazy를 적용하면 컴포넌트들을 미리 import해오는것이 아니라 필요한 시점에 import해와서 요청의 시간과 횟수를 더 최적화시킨다고 생각해서 적용했다. 그런데 이게 잘 적용된건지, 효과가 있는지는 어떻게 확인해봐야할지 네트워크 탭을 확인해봤지만 아직 잘 모르겠다.

  -material UI에 있는 아이콘들을 사용하다가, 마음에 들지않아 react icon에서 마음에 드는 아이콘을 사용하게 되었다. 그런데 네트워크 탭을 보니
  

  겨우 하나 쓸건데 이렇게 많은 아이콘들을 불러와야하는건 좀 아닌듯해서 스택오버프로우행~ 임포트 주소를 다양하게 써봣지만 아직 해결을 못했다. 웹팩설정까지 내용이 이어지는 것 같은데 이번주 내 꼭 해결해야겠다.
  React Icons Imports everything even when included 2 or 3 icons

• 0615(tue)

  • 스타일 위치지정에 애를 먹었다.
    형태가 동일한 컴포넌트들을 별도의 컴포넌트 단위 파일로 분리하지 않기 위해 렌더링할 값들을 배열에 집어넣고 map을 통해 렌더하고 있었는데, 미처 종속적으로 따라 붙어야 하는 컴포넌트에 대해 고민하지 못했기 때문에 이슈생성 페이지의 디자인이 불가피하게 달라지게 됬다. (차선책으로 다른 위치에 모달을 보여주게 했다)

    ( 구체적으로는 '필터 탭'과 '탭 모달'이다. -> 현재는 형제요소 처럼 나열되고 있어 클릭한 탭의 위치에 맞춰 탭 모달의 position이 달라지도록 하드코딩 되어있다. 만약 탭과 모달을 부모-자식 관계로 구성했다면, 부모요소 바로 밑에 모달이 열리도록 relative, absolute, bottom 속성만 지정하면 문제를 해결 할 수 있었을 것이다.)

    '고치면 되는거 아냐?🤷‍♀️'
    ⇒ useToggle커스텀 훅을 적용했는데 모달창의 컨트롤이 어려워져 모달창을 각각 하나씩 총 4개의 컴포넌트생성이 더 필요하게 된다. 이와 같이 반복적인 컴포넌트, 반복적인 로직을 쓰지 않기 위해 고치지 않기를 선택했다.

    ⇒✨오늘(06/18) 새로운 방법을 고안함! 위에서 얘기한 대로 탭/모달을 부모자식 관계로 컴포넌트를 만들고 공통된 포지션 위치(스타일링)를 지정해준다.
    커스텀 useToggle을 사용하지 않고 이 기능을 recoil을 활용한 상태관리로 구현하자! 특정 탭 컴포넌트가 클릭되면 setClick(true) 나머지 탭 컴포넌트들은 setClick(false), click상태가 true이면 해당 모달만 보여주도록 한다.✨: 리팩토 요소

• 0616(Wed)

  • 폴더구조 변경
  • 고차함수 적용할 부분 생각하면서 코딩하기.
  • 최적화작업 따로 이슈빼기 -> LAZY/MEMO/CALLBACK

• 0617(Thu)

  • selectorFamily로 fetchData를 반환하도록 설계를 했고, skip이라는 변수명이 true일 때 반환된 함수를 재실행하게 구성해봤다. 그런데 결국은 버튼을 클릭했을 때 data를 fech하는 상황이라 결국은 직접 fetch하는 상황과 동일해졌다. 그래서 일반 fetch로 수정했지만, 생각해보니 suspense나 error boundary를 적용해보려면 selector recoil을 사용하는게 맞을 것 같다는 판단으로 재수정했다.~~
    아니래 ..... 일반 fetch도 suspense 된데 ㅠㅠ....... 꼭 확인해봐야지..

    (근데 지금껏 함수를 반환하는 설계는 여러번 해당 컴포넌트가 재사용 요청이 필요할때 유용하겠구나...라는걸 이제 이해했다.)
    

  • 어려웠던 점: 로그인 구현 userAgent

    백엔드에서 앱에서의 로그인 요청인지 프론트에서의 로그인 요청인지를 구분하기 위해 User-Agent: IssueTrackerFE/1.0 를 헤더에 넣어 보내주기로 했다.
    그런데 응답이 제대로 오지 않았는데(bad user info..? 대략 이런느낌의 에러 발생)

    그 이유는 브라우저의 user-agent를 수정할 수 없기 때문이라고 한다. 기본적으로 user-agent는 network탭에서 requestHeader에서 확인할 수 있는데 아래값을 갖는다.
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.106 Safari/537.36

    직접 개발자도구에서 User-Agent: IssueTrackerFE/1.0 으로 수정할 수는 있지만 api요청때 헤더에 작성하는 방식으로는 user-agent는 변경할수가 없다고 한다. 때문에 기본값으로 서버에 로그인 요청을 보냈고 그 조건으로 브라우져인지 앱인지의 판단을 서버에서 하도록 해 로그인이 가능해졌다 ㅎ_ㅎ

  • 변경할 사항:
    로그인후 토큰을 로컬스토리지에 저장을 할 예정이다. 그리고 보여져야할 페이지는 이슈리스트 페이지인데, api요청을 할 때 토큰값을 api에 담아 접속자인지를 체크하며 응답을 받을 예정이다.

• 0618(Fri)

  • 오프라인 미션활동 진행!

  • 어려웠던 점(삽질)
    잘되던 로그인이 갑자기 500에러를 내뿜으며 오류가 발생했다. 당연히 500번대 에러이기 때문에 서버에서 문제가 생긴 줄 알고 백엔드에 문제확인을 요청했는데, 백엔드도 건드린적이 없고 포스트맨으로 요청해볼 때 에러없이 응답을 잘 주고있다고 했다. 좀 더 살펴보고는 요청이 2번씩 오는 것 같다고 하셨는데, 네트워크 탭을 쓰윽보고 아마 preflight와 본 요청이 2번으로 인식되는 것 같다고 답변했다.

    하지만. 너무 너무 죄송하게도 클라이언트에서 본요청이 실제 2번가고있었다. 서버문제가 아니었다.

    깃헙로그인 버튼을 누르게 되면 주소창에 로그인 요청 api에 필요한 code를 받게 되는데, 이 코드는 단 1번만 사용되고 재 요청할 수 없는 값이다. 근데 이 code가 담긴 요청이 2번 보내져서 서버에서는 오류를 반환하는 것이었다.

    > 왜 2번 요청이 갔을까?

    recoil상태관리를 하면서 문제가 있었다.
    단계별로 코드 구현을 정리하면 아래와 같다.

  • step1: 로그인) 로그인을 클릭하면 바로 redirect-url로 설정했던 이슈리스트 페이지로 자동으로 이동한다. 이슈리스트 화면의 주소창에는 로그인을 요청할 수 있는 code가 담겨져 온다. (깃헙 Oauth에서 해주는 기능)

    이 코드를 기반으로 서버에 유저정보를 받을 수 있도록 post요청을 보내게 되고 서버는 유저정보와 token을 응답으로 준다. 이 토큰을 로컬스토리지에 저장하며 로그인은 완료된다. 이 때 로그인 상태임을 앱에 알려주기 위해 setRecoilState를 통해 false->true, 깃헙으로 부터 받은 token과 user정보를 저장한다.

  • step2:로그인여부 확인) 앱을 재 접속했을 시에 기존 로그인되어있던 유저라면 로그인페이지가 아닌 이슈리스트 페이지로 이동 시켜야 한다. 이를 위해 앱의 최 상단에서 리코일 로그인 상태(useRecoilValue)값에 따라 페이지 라우팅을 설정했다. (리코일 상태값이 선언됨)

    문제는 step1 이후에 발생했다. 로그인 되었음 true를 설정하자 마자 앱의 최상단에 선언했던 리코일이 상태변화를 감지해서 앱의 엔트리 파일이 리렌더되며, 로그인상태가 true이니 이슈페이지를 보여주는데 주소창에 떠있던 아까와 같은 코드를 담아 다시 서버에 로그인 요청을 보내는 것이었다.

    > 해결방안은?
    - 임시방편) 앱의 최상단이 리렌더링 되어 생기는 문제로 보고, 엔트리 파일이 아닌 헤더에서 로그인 유무를 판단하기로 했다. 로그인 2번 요청의 에러는 해결됬다. 하지만 이미 로그인을 했던 사용자라면 localhost:3000으로 접속을 해도 로그인화면이 아닌 이슈리스트 페이지를 보여줘야 하므로 기획내용과 다르다. 그리고 로그인의 유무를 파일 구조상 최 상단에서 하는 것이 맞지, 어느 작은 컴포넌트에서 판단하는 것은 흐름상 옳지않다고도 보인다.

    - 수정할 방법1)
    위에서 설계한 step대로 최상단 파일이 리렌더링되도록 냅둔다. 대신에 code를 담아 로그인 요청을 보내는 부분에서 로그인 상태가 true이면 fetch하지 않도록 막는 조건이 필요할 것이다.

    - 수정할 방법2)
    깃헙로그인 버튼을 누르면 이슈리스트 페이지로 리다이렉팅 시켜놨는데 이 부분을 고친다. 리다이렉트 없이 해당 페이지에서 로그인 로직을 처리한다. (서버에 로그인 요청) 로그인이 되면 로그인 상태를 recoil로 true설정을해 최상단에서 recoil이 상태변화를 감지하게 하고 다시 앱 파일의 최상단이 리렌더되게 한다. 그럼 이제 라우터 조건에의해 로그인 true이니 이제 이슈리스트로 넘어가게 한다. 로그인 로직 처리를 이슈 페이지가 아닌 로그인페이지에서 완료했기 때문에 주소창은 코드쿼리 없이 깔끔! 같은 요청이 2번 갈리 없다.

    +) 아마..2번방법으로 고치지 않을까? 왜냐하면 코드를 메인 주소창에 노출시키는 것도 좋지않다고 생각하고, 모든 요청에 user token을 헤더에 담아 이슈리스트를 보여달라고 fetch하게 되는데, 리다이렉팅 주소가 이슈리스트가 되버리면, 헤더의 토큰값이 제대로 반영되지 않은 상태에서 fetch를 보낼 것 같기 때문이다. 또한 페이지와 로직내용이 일치한 점에서 그러하다.

    ---

    지금 이렇게 글로 정리한 것 처럼 코드를 고치면 될 것 같고 이렇게 글로 쓰는 것보다 훨씬 빠르게 수정하고 이미 자고 있을 것이다. 근데 글로 쓰면서 느낀 점이 2가지가 있는데 ...

    우선, 생각하는 힘을 길러야겠다는 점이다. 아깐 서버에러를 보면서 빨리 문제를 해결하자는 생각에 정신없이 고치는데 집중한 것 같다. (백엔드에 미안하기도해서 급한 불을 끄자는 생각도...🔥) 문제가 터지더라도 원인과 해결법을 차분히 생각하고 코딩을 하는 습관을 기르자. (지금은 순서가 좀 바뀐 듯하다.)

    또한 생각을 설득력있게 얘기하는 것도 능력이라는 것.
    (물론 이번엔 내 생각이 깊지 못해 설득할 시도를 못했지만) 내가 생각한 것을 차분히 말로 전달할 수 있도록 노력해야겠다.