밝을희 클태

pongGame에서 requestAnimationFrame() 를 사용해서 탁구채를 움직이는데 문제가 있다 사용자의 모니터 환경에 따라 탁구채의 움직이는 속도가 달라진다. https://gaebarsaebal.tistory.com/58 탁구채 속도가 환경에 따라 다르게 움직임(requestAnimationFrame) 지금 Pong 게임의 탁구채 움직임을 구현 중인데 내 노트북에서 게임을 할 때랑 팀원의 노트북으로 게임을 할 때 탁구채의 움직이는 속도가 달랐다. 처음에는 setInterval() 로 60 fps으로 구현을 하다 gaebarsaebal.tistory.com 그래서 다양한 모니터 환경에서 공평함을 유지하기 위해 60FPS로 고정을 시켜줄려고 한다. 이렇게 되면 requestAnimationFr..

문제- 게임 플레이시 프레임 드랍이 일어남원인- setInterval() 사용 : 기존에 아래와 같이 60FPS설정을 setInterval()로 구현을 했다. 이 방법은 JavaScript 이벤트 루프 내에서 비동기적으로 실행되며 정확한 타이머주기를 보장하지 않는다. 지연이 누적되다 보면 프레임 드랍이 생긴다. setInterval(() => { if (isMovingUp) { coor = Math.max( parseInt(style.top) - 30, this.myPingpongStick.offsetHeight / 2, ); this.update(coor); } else if (isMovingDown) { coor = Math.m..

인증되지 않은 유저가 URL을 통해 직접 페이지로 접근하는 걸 막아보자. 아이디어 : 로그인된 유저는 메모리에 accessToekn 을 가지고 있다. url 로 직접적으로 접근을 할 때 메모리에 accessToken 이 없다면 loginPage 로 리다이렉션 시켜준다. 어디서 할까 고민을 했는데 모든 페이지에서 공통적으로 제일 처음 connetionWebScoket 의 연결 상태를 확인하는데 이때 accessToken 이 사용되므로 이 과정에서 정상적인 유저인지 판단을 할 것이다. 구현 : 기존의 accessToken 을 재발급받는 함수가 있는데 기존의 로직에서 token 재발급에 실패를 하면 loginPage 로 리다이렉션을 시켜준다. export const refreshAccessToken = asy..

문제 : 웹소켓 연결이 끊겨 버리고 서버가 터져버림 사실 수집 : 게임을 하다가 뒤로 가기 동작을 하면 가끔씩 웹소켓 연결이 끊기고 서버가 터져버리는 현상이 발생 서버 로그를 확인해보니 같은 에러 로그가 반복적으로 발생 게임 페이지에서 뒤로가기를 통해 다른 페이지로 이동한 후 방향키를 누르면, 이전에 등록된 이벤트 리스너가 계속 실행되는 현상이 발생 원인 추론 : VanillaJS로 SPA 방식의 게임을 구현했는데, SPA는 페이지가 새로고침되지 않기 때문에, 기존에 등록된 이벤트가 따로 제거되지 않으면 그대로 남아있게 된다. 방향키로 탁구채를 움직이는 동작을 할 때, 이 이벤트 리스너가 실행되면서 서버로 현재 탁구채의 좌표(int 형)를 웹소켓을 통해 보내는데, 여기서 뒤로 가기 동작을 할 경우 게임 ..

지금 Pong 게임의 탁구채 움직임을 구현 중인데 내 노트북에서 게임을 할 때랑 팀원의 노트북으로 게임을 할 때 탁구채의 움직이는 속도가 달랐다. 처음에는 setInterval() 로 60 fps으로 구현을 하다가 프레임 드랍이 있어서 requestAnimationFrame() 함수를 사용해서 탁구채의 움직임을 구현했는데 당시 구현을 할 때 대충 다른 사람의 블로그를 보고 구현을 해서 환경에 따라 탁구채의 속도가 다른 이유를 한참 찾아 헤맸다.. 이유는 모니터의 hz 차이였다. - MacBook pro 16 - MacBook air 15 이렇게 두 대의 노트북으로 테스트를 했는데 일단 pro의 경우 모니터 hz(재생율) 을 ProMotion 을 사용하고 있었고 팀원은 60hz 를 사용하고 있었다. Pro..

지금 SPA 방식으로 프로젝트를 구현 중에 있는데 같은 경로를 클릭 시 해당 컴포넌트가 리렌더링이 일어난다. 단점이 너무 많다 성능 저하: 페이지의 내용이 변하지 않음에도 불구하고, 렌더링 과정을 다시 수행해야 하므로 추가적인 자원을 소모함. 이는 특히 리소스가 제한적인 모바일 기기에서 더 큰 문제가 될 수 있다 사용자 경험 저하: 불필요한 페이지 로딩으로 인해 사용자는 같은 내용을 보기 위해 더 많은 시간을 기다려야 할 수 있다. 이는 사용자 경험을 저하시킴 서버 부담 증가: 클라이언트 측에서만 처리할 수 있는 렌더링을 서버에 요청함으로써, 서버에 불필요한 부담을 줄 수 있다. 정적 리소스나 API 호출이 많은 웹 애플리케이션의 경우, 이러한 요청이 누적되어 서버 성능에 부정적인 영향을 줄 수 있다. ..

환경 : 바닐라JS SPA 방식 문제 : 안 읽은 메세지 카운터 기능을 구현중에 메세지를 읽지 않았는데 안 읽은 메시지 갯수가 뜨지 않음 사실 수집: A 채팅방에 들어갔다가 다른 컴포넌트로 이동해서 A가 메세지를 보내면 안 읽은 메세지 갯수가 떠야하는데 뜨지 않음을 확인 원인 추론: 1 :1 채팅방에 들어갈때 WebSocket send를 날리고 다른 컴포넌트로 이동을 할때 Webscoket 에 나갔다고 다시 send를 날려야하는데 하지 않아서 이런 버그가 난걸로 예상 조치 방안 및 구현: document.querySelectorAll('a[data-spa]').forEach(link => { link.addEventListener('click', () => { this.leaveWebSocket(); }..

프로젝트를 진행 중 WebSocket이 닫히는 현상이 생겼다. 채팅을 구현하는데 채팅방에 들어가지 않고 메세지를 입력해서 WebSocket에 Send 를 하면 오류가 나서 웹소켓이 닫혀버린다. 이거는 채팅방에 들어가지 않았을 때 그냥 채팅을 입력하지 못하게 하면 그만이지만 이 외에도 WebSocket이 닫혀버린 채로 있다면 싱글톤 패턴으로 WebSocket을 사용하고 있기 때문에 나중에 큰 문제가 될 수 있기 때문에 닫히면 다시 연결하는 로직을 구현을 하기로 했다. 첫 번째 방식 import BaseWebSocket from './BaseWebSocket.js'; import {getToken, refreshAccessToken} from '../tokenManager.js'; import {checkC..

프로젝트를 진행하면서 하나의 WebSocket으로 여러 컴포넌트에서 각기 다른 onmessage 이벤트를 등록해야 하는 일이 생겼다. 그래서 어떻게 로직을 작성할지 고민하다가 싱글톤 패턴의 중앙 집중식 WebSocket을 구현하기로 했다. 일단 위처럼 구현을 하게 되면 장점은 트래픽과 서버 부하를 줄일 수 있다 구현이 단순해진다 단점은 하나의 웹소켓에 의존을 하면 해당 WebSocket에 문제가 생기면 프로젝트 전체에 문제가 생길 수 있다 사용자가 많거나 데이터가 많아지면 병목 현상이 생길 수 있다 등이 있다. 그런데 일단 우리는 WebSocket으로 큰 데이터를 다룰 일이 없을 거 같아서 구현이 단순한 싱글톤 패턴의 WebSocket 방식을 택했다. 일단 BaseWebSocket Class를 만들어준다..

문제 : 전체채팅 페이지에서 한 유저를 골라서 1 : 1 채팅으로 넘어가서 새로고침시 대화방의 내용이 다시 렌더링이 안된다. 다른 페이지에서 웹소켓을 연결을 하고 채팅방 페이지로 오면 문제가 없지만 채팅방 페이지에서 새로고침해서 최초로 웹소켓 연결시 문제가 발생 사실 수집: 문제 재현 과정에서 WebSocket 연결 후 메시지 송수신 과정에서 비동기 처리의 순서 문제를 확인. 새로고침 시 웹소켓 재연결 과정에서 이전 채팅 내용을 fetch하기 전에 웹소켓으로 메시지를 보내려 하였으나, 웹소켓 연결이 완료되지 않은 상태였음. 원인 추론: await checkConnectionSocket(this.socketEventHendler.bind(this)); const $chatRoom = document.que..