FrontEngineer JungBam

패칭이 되는동안 로딩화면을 띄우길 원하지 않을 경우 사용하는 방법 : 미리 페이지를 패칭해서 캐싱 + 이전 페이지를 캐싱 1. 페이지네이션에서 미리 페이지를 패칭해서 캐싱하는 방법 : 다음 페이지를 패칭해서 캐싱한다. const queryClient = useQueryClient() useEffect(() => { if(currentPage fetchPosts(nextPage)) } }, [currentPage,queryClient]) 2. 이전 페이지를 캐싱하는 방법 : useQuery의 옵션 중 keepPreviousData를 ..

이번주에 공부한 중점 1. SOCKET.IO 2. peer.js 3. typeScript 적용해본 라이브러리 1. react-dnd 2. frame-motion 3. react-sound node 인프라 구축에 시간이 일주일 이상 소모되면서 시간이 남아 미흡한 공부를 진행하면서 목 데이터를 통한 기능 구현을 각각 진행했다. 이번주에는 webRTC와 SOCKET의 트래픽 이슈들이 많이 생겼다. 1. 화상채팅을 할 때에 피어가 늘어날 수록 스트리밍 화면이 깨지고 화면에 보이는 내가 실시간에서 0.5~1초의 갭이 생기는 문제가 생겼다. 이건 webRTC 공식문서에도 나오는 내용이기는 한데 best practice는 SFU 서버를 통한 스트리밍이지만 지금 가용한 리소스에서는 불가능하기때문에 어느정도 안고가야 될..

useQuery의 첫번째 매개변수 - 기본적으로 리액트 쿼리는 쿼리 키를 기반으로 쿼리 캐싱을 관리함. - 쿼리 키는 고유한 값을 가져야 함.( useQuery 와 useInfiniteQuery간에도 고유해야 함.) - 쿼리 함수가 변수에 의존하는 경우 쿼리 키에 변수를 포함해야 함. => const result = useQuery(['todos',todoId],()=>fetchTodoById(todoId)) 리액트 쿼리에서 캐싱이란? 캐싱이란? - 명령어와 데이터를 디스크 캐시 등에 일시적으로 저장하는 과정 리액트 쿼리에서는 캐싱을 어떻게 관리할까? - staleTime과 cacheTime을 통해 관리함.(useQuery의 세번째 매개변수 옵션 중 일부) - staleTime : 데이터가 오래된 것으로..

socket 프로토콜의 이해 폴링(polling)이란? (comet) 폴링은 리얼타임 웹을 위한 기법으로, 일정한 주기(특정한 시간)을 가지고 서버와 응답을 주고 받는 방식을 말한다. 이렇게 서버와 응답을 주고 받는 이유는 웹이 태생 자체부터 실시간을 위해 etloveguitar.tistory.com 프로토콜(Protocol) 이란 / TCP/IP, HTTP, Web Socket 프로토콜(Protocol) : - 복수의 컴퓨터 사이나 중앙 컴퓨터와 단말기 사이에서 데이터 통신(데이터를 을 원활하게 하기 위해 필요한 통신 규약 - 사람과 사람이 통신할 때 서로 이해할 수 있는 언어, itstart-190126.tistory.com SOCKET.IO webRTC의 필요성 WebRTC An open frame..

1. websocket부터 SOCKET.IO, webRTC 2. API layer, 인터섹션 옵저버 3. nginx request와 response가 있는 http 통신 프로토콜에서 실시간 통신을 위해 connect와 disconnect를 통해 연결되는 socket 통신을 공부하고 이를 통해 채팅을 구현해봤다. SOCKET.IO라는 websocket을 좀 더 쉽게 접근할 수 있는 방법에 대해서 공부하고 이를 통한 채팅을 구현해봄으로써 실시간으로 진행되어야 하는 방식에서 socket이라는 달콤함을 느낄 수 있었다. webRTC를 구현하는 것 자체는 아래의 레퍼런스를 통해 줌 클론코딩을 진행하며 어렵지 않았지만 이를 통한 실시간 스트리밍을 구현하는 것은 어려움이 있었다. 줌 클론코딩 – 노마드 코더 Noma..

1. 쿼리 키는 배열로 사용(기존 문자열, 배열에서) 2. devtools를 별도 설치 - npm i @tanstack/react-query-devtools 3. setLogger 대신 QueryClient 옵션으로 로거 추가

조회수를 구현하고 나니까 조회수를 정신없게 올리는 것에 대한 처리가 필요하다는 생각이 들어서 이것저것 해보면서 느낀점이 있다. 예전 사이드 프로젝트에서 빽분이 말씀하셨던 게 생각났다. '아~ 무조건 빽에서 해야지. 그걸 왜 프론트에서 만져. 그거 냅둬' 그때는 뭣도 몰랐으니까 아네 하고 말았지만, 이번에 프로젝트하면서 똑같은 주제가 나왔을 때 그 때 그분이 한 이야기를 하나씩 팀원들한테 하다보니까 찾아보게 되었고 왜 그렇게 말씀하셨는지 알게 되었다. 생각해보면 당연한 것을.. 프론트에서 쿠키에서 작업을 하면 결국 클라이언트가 쿠키에 접근해서 조작할 수 있다는 가장 큰 단점을 갖고 있기 때문. 작업하는 건 어렵지 않고 오히려 지금은 코드짜는 것이 좋지만 보안에 있어서는 빽이 하는 것이 맞는 것 같다. 아래..

미니프로젝트 : https://github.com/Jungbam/randomItem GitHub - Jungbam/randomItem Contribute to Jungbam/randomItem development by creating an account on GitHub. github.com 가장 좋았던 것은 B.E. 분들이 이미 경력이 있으시고 프로젝트 경험이 다수인 분들이셔서 B.E.와의 협업은 매우 순조로웠다. API구성 / 와이어프레임 도 서로 소통하며 작성하고 스코프 또한 프론트쪽의 진행도에 맞춰 적절했다. 이번 프로젝트 목표는 기능적인 부분보다 협업과 팀 문화에 신경을 많이 썼다. 1. 깃 플로우 관리 2. 컴포넌트 추상화 3. 프로젝트 임무분담에 따른 협업 여기서 생각하지 못한 부분은 같은..