새로고침 시 404 에러
⇒ 현재 SPA (React) 구조로 동작하고, NginX도 메인 URL만 연결해놓았으므로, 새로고침 시 해당 URL과 연결된 부분이 없는게 당연하다.
404 에러가 뜨지 않도록 모든 경로가 index.html을 전달하도록 해야한다. (내부적인 404 페이지 처리 필요)
env 에러
⇒ CI 과정에서 깃허브에 있는 내용을 기반으로 배포가 진행되므로, 깃허브에 올라가지 않는 env는 어떻게 받을 수 있을 지 고민함.
⇒ CI 과정에서 키를 이용해 env 파일을 새로 만들어 해당 파일을 가지고 배포!
채팅창 중복 출력 문제
⇒ 탭을 이동할 때 새로운 채팅 내역을 한번 더 불러와서 기존에 웹 서버로부터 받은 채팅과 중복됨.
⇒ 문제를 찾던 중 탭을 바꾸거나 브라우저를 내렸다가 올렸을 때마다 렌더링이 한번 더 되는 것을 확인.
⇒ 사용중인 React-Query 라이브러리는 탭을 변경하거나 브라우저를 내렸다가 올릴 때, 데이터를 새로 받아오는데, 이 과정에서 차이가 있으면 렌더링, 없다면 렌더링을 하지 않음.
⇒ 서버에서 이미지를 넘겨줄 때 presigned URL을 거쳐서 넘겨주는데, 이 때 데이터가 바뀌지 않아도 presigned URL을 거치게 되면서 이미지 주소 값이 변경되고, 이로인해 react-query가 렌더링을 진행.
⇒ 서버와 이야기 하기 전 우선 staletime 값을 react-query와 동일하게 5분으로 변경
⇒ 그런데 해당 부분은 유저 정보를 기반으로 한 헤더 부분인데, 유저가 변경을 하지 않는 한 신선한 데이터이므로, staletime을 infinity로 변경 후 유저 정보 변동 시 다시 불러오도록 변경
⇒ 하지만 모든 이미지가 있는 곳에서 이러한 문제가 발생하므로… 서버에 요청은 필요할 듯.
⇒ 그런데 만약 이 문제가 해결되더라도, 결국 이미지가 기간이 만료되면 탭을 이동할 때 동일한 문제가 발생할텐데… 근본적인 문제가 아니라고 생각 (물론 위 과정은 불필요한 렌더링 발생으로 필요한 과정이긴 했음)
⇒ 결과적으로 웹소켓을 통해 받은 데이터와 기존 받아오는 데이터에 대한 연결이나 관리가 필요함…!
- 추가적으로 기존에 있는 query의 대대적인 세션 관리가 필요할 듯…
07/22
⇒ 우선 채팅 중복에 관한 부분은 채팅 내역 데이터가 넘어올 때 상태 관리 중인 실시간 메세지 데이터를 초기화 하는 방향으로 진행.
⇒ 그리고 최종적으로 탭을 이동할 때나 최소화 시킬 때 웹소켓의 연결은 끊기지 않으므로, 굳이 내역을 최신화 하지 않아도 사용자는 항상 신선한 채팅 내역을 확인할 수 있었음..! 채팅 내역 불러오는 쿼리의 refetchOnWindowFocus 설정을 false로 설정하여 탭 변경 시 렌더링을 무시하는 방향으로 문제 해결!
⇒ 처음에는 단순히 이 설정을 끄는게 React Query의 철학과 맞지 않는다고 생각해서.. 최후로 미뤘었는데 특정한 경우 적용하는게 유리한 경우도 있다는 것을 느낌.
배포 환경에서 자기 자신 메세지 인식 못하는 문제
⇒ 동일 서버 사용중인 로컬과 배포 클라이언트에서 채팅이 다르게 출력되는 문제 확인
⇒ 배포 환경에서 새로고침 시 자신의 채팅을 다른 사람의 채팅으로 인식함
⇒ 로컬 환경에서는 새로고침 시 httpOnly 쿠키를 적용 못하므로 토큰 재발급 기능이 없어서 확인이 안됬던 것…
⇒ 배포 환경에서 새로고침 시 accessToken이 휘발되는건 의도한 경우였으나… 나머지 전역 상태들은 의도하지 않게 날아갔던 것.
⇒ redux-persist 사용하여 해결 예정.
⇒ persist로 특정 슬라이스들은 세션에 저장하여 새로고침 이후에도 값이 유지되도록 설정
⇒ 그러나 auth 내에 있는 userId 는 토큰 때문에 세션에 넣을 수 없을 것 같음…
⇒ 그냥 재발급 로직에서 토큰 재발급 받으면서 userId도 같이 넘겨 받아서 바로 저장하는 걸로..!
⇒ 테스트 완료
갑자기 배포 중 터진 도커 권한 에러 문제 (07.28)
Error: buildx failed with: ERROR: denied: requested access to the resource is denied
⇒ 잘 되다가 갑자기 터진 배포 문제…
⇒ 찾아보니 로그인을 하지 않았거나 이미지 태그나, 계정 이름을 잘못 적었을 때 나오는 오류라는데… 확인 다시 해봐도 잘 되어있었고, 기존에는 잘 되다가 안되는게 좀 이상….
⇒ 일단 내일 와서 해야지.. 로컬 환경에서도 테스트 해봤는데 동일한 문제 발생.. 계정에 뭔가 문제가 생긴 것 같음.
07.29
⇒ 기본 비밀번호로 하고 있었는데 도커쪽에서 권한이 바뀌었을 수도 있다고 해서.. Access Token을 새로 만들고, 해당 토큰으로 로그인하여 배포 재시도
⇒ 됨.. 아니 그럼 진짜 기존 비밀번호 사용하여 배포하는게 그 사이에 막힌건가!!??!?
⇒ 기존 깃허브 액션에서 사용하는 비밀번호를 발급받은 토큰을 입력하여 로그인하여 해결하였다.
스케줄 변경 모달 렌더링 문제
개인의 스케줄을 입력하고, 팀원들의 스케줄을 확인할 수 있는 모달.
클릭 이벤트를 통해 스케줄을 변경하는데, 변경할 때마다 모든 셀이 렌더링.
그러다 보니 드래그 시 버벅거리며, 빼먹는 칸이 생겨 사용자 경험 저하.
기존에는 각 칸마다 마우스 이벤트 리스너를 달고 , string 상태가 변경함에 따라 렌더링을 진행하였음.
단순히 메모이제이션을 바로 쓸까 하다가 이 상태에서 사용하게 되면, 이벤트 함수도 매개변수로 넘겨줘야 하고, 메모이제이션을 위해 함수까지 기억을 하게 하면 비효율적이라고 생각.
그래서 함수 자체는 컨테이너(부모)에 이벤트로 넣어주고, 이벤트 객체의 index 값을 이용해 기타 작업들을 수행하도록 변경.
부모에 이벤트를 넣어서 마우스가 해당 칸을 이탈했을 때의 이벤트도 쉽게 처리할 수 있었음.
UI와 관련된 부분(셀)을 따로 컴포넌트로 분리하여 메모이제이션 적용.
전체 컨테이너가 렌더링이 되어도, 자식의 props가 변경되는 부분에 한에서만 렌더링이 된다.
선택된 부분만 렌더링을 시키면서 사용자 경험이 크게 증가하였고, 빼먹는 칸도 현저히 줄어들음.
깃허브 Revert 문제
현재 워크플로우는 다음과 같았다.
메인 (배포중) —- dev —- (브랜치 추가)
실수로 한 브랜치(A)에서 dev를 거치지 않고 main으로 바로 push 해버리는 일 발생..
고민하다가 revert를 사용하기로 결정하고, revert를 이용해 (A)를 (A’)로 덮어 씌웠다.
이후 정상적으로 브랜치(A)에서 dev로 정상적으로 push를 하고,
다른 브랜치(B)의 작업 내용도 완료 후 dev에 정상적으로 push를 진행하였다.
이제 dev에서 테스트를 마치고, 배포를 위해 main에 push를 하려는데…
기존 (A) 작업이 이미 남아있어서 현재 dev (A, B)를 main에 push 해도 B의 내용밖에 들어가지 않았다.
현재 main은 A의 작업 내용이 A’ 로 인해 없는 상태이고…
서칭을 해보니 A’ 내용을 한번 더 revert 하여 A 내용을 복원하는 방법밖에 없다고 한다.
기존 워크 플로우도 깨지고, 기록이 남아서 아예 새로 덮어쓰기에도 좋지 않다고 생각했다.
main에 직접적인 push를 막는 방법이나 만약 이런 경우에 현업에서는 어떻게 처리를 하는지 궁금했다.
우선 dev → main 으로 push를 진행하고, A’를 revert 하는 방향으로 해결했다.
textarea 의 overflow: clip; 문제
useEffect 의존성 문제