기술 블로그

인프라에 관심이 생겨 GCP 배포를 경험해보고자한다. 구글 클라우드에 가입 후 원할한 진행을 위해 카드 등록도 해준 후 배포하기 위한 프로젝트를 만들어 선택한다. 옆의 id를 잘 기억해준다 추후 사용한다. 우리가 주로 참고해야할 레퍼런스는 아래 두개다. https://nextjs.org/docs/pages/building-your-application/deploying#docker-image Building Your Application: Deploying | Next.js Congratulations! You're here because you are ready to deploy your Next.js application. This page will show how to deploy either ma..

일반적으로 재귀함수는 프로그래밍에서 아주 중요한 요소이며 알고리즘으로도 자주 활용되는 기법이다. 그러나 프론트엔드 환경에서는 어떨까? 이전 게시글에서 봤던 것 처럼 프론트엔드 개발자는 콜스택의 부하를 경계해야하고 여러 문제를 야기한다. 1. 잘못 사용하면 재귀는 스택 오버플로우를 일으키기 좋은 기법이다. 2. 각 함수 호출마다 실행컨텍스트가 생성되기 때문에 메모리 측면에서 좋지 않다. 3. DOM 조작시 성능 저하가 발생할 수 있다.( 매 함수마다 리플로우 리페인팅) 이를 방지하기위해 꼬리 재귀라는 기법을 사용할 수 있다. //일반 재귀 function factorial(n) { if (n === 1) { return 1; } return n * factorial(n-1); } //꼬리 재귀 functi..

동기: 이전 작업이 끝날때 까지 기다렸다가 끝난 이후 다음 작업을 실행하는것 비동기: 이전 작업의 완료여부와 관계 없이 다음 작업을 실행하는 것 자바스크립트에서 비동기는 아래와 같은 상황에서 발생한다. 👉 DOM Element 의 이벤트 이벤트 핸들러 - 마우스, 키보드 입력 (click, keydown 등), 페이지 로딩 (DOMContentLoaded 등) 👉 타이머 - 타이머 API (setTimeout 등), 애니메이션 API (requestAnimationFrame) 👉 서버에 자원 요청 및 응답 - fetch API, AJAX (XHR) 사실 위 사진이 자바스크립트 비동기 작업의 전부이다. 추가 할 점이 있다면 콜스택 옆에 메모리힙이 있다. 콜스텍과 실행컨텍스트 그리고 메모리힙 실행컨텍스트는 ..

React.memo export default React.memo(Category); //videos 내려오는 props가 자주 동일할 때 사용된다. props가 변경될 때만 리렌더링하게 개별 컴포넌트를 설정할 수 있어서 렌더링 최적화에 도움이 된다. 그러나 오버헤드 우려가 있어 필요한 컴포넌트에만 적용하도록 한다. react-window npm install react-window 외부 라이브러리이나 화면에 보이는 부분만 렌더링하도록 한다 몇만개의 데이터가 배열 되어있을때 사용한다. useCallback 함수 재사용 useMemo 값 재사용

getServerSideProps (서버 사이드 렌더링) 페이지에서 getServerSideProps라는 함수를 내보낼 때, Next.js는 이 함수로 반환된 데이터를 사용하여 각 요청에 대해 이 페이지를 사전 렌더링합니다. 주로 자주 변경되는 데이터를 최신으로 업데이트 하는 경우 유용하고 클라이언트 측에 번들되지 않는다. context매개변수는 params,req,res,query를 포함한다. 이 함수는 이중 하나를 포함하는 객체를 반환해야한다 - props라고 명명된 객체 속성 - notfound(bool)로 명명된 속성 - redirect 문제 getServerSideProps내의 기능은 클라이언트 렌더링 이전에 수행된다. 즉 클라이언트 단에서 서버단의 데이터를 받을 순 있지만 일반적인 방법(nex..

// src/_app.js import { RecoilEnv } from 'recoil'; RecoilEnv.RECOIL_DUPLICATE_ATOM_KEY_CHECKING_ENABLED = false

문제 Next.js의 router-query를 이용해 객체 데이터를 전달하려 했으나 수신페이지에서 특정 객체만 수신할 수 없었다. 원인 router-query는 url 쿼리 파라미터로 전달되고 다음과 같은 문제가 발생할 수 있다. 인코딩 문제: 객체는 URL 안전한 문자열로 인코딩되어야 합니다. 이를 위해 encodeURIComponent와 같은 함수를 사용하여 객체를 문자열로 변환하고 인코딩해야 합니다. 그렇지 않으면 URL이 유효하지 않을 수 있습니다. 길이 제한: URL에는 길이 제한이 있습니다. 대부분의 웹 브라우저와 서버는 URL의 길이를 제한합니다. 큰 객체를 쿼리 파라미터로 전달하려고 하면 이 제한을 초과할 수 있습니다. 읽기 어려움: 복잡한 객체를 URL에 포함시키면 URL이 읽기 어려워집..

문제 타입 스크립트를 사용할 때 금기시 되는 것들이 있다. 타입 단언 as any 사용 Typescript에서 as 키워드는 타입 단언(type assertion)을 사용하여 특정 변수 또는 객체가 특정 타입임을 명시적으로 지정할 때 사용됩니다. 그러나 이를 남용하면 런타임 오류를 초래할 수 있으므로 권장되지 않습니다. 어떠한 런타임 오류를 발생할 수 있을까? 주로 발생하는 에러는 개발자가 타입을 잘못 단언하여 발생한다. 이에 런타임에는 js로 변환되어 타입 정보가 없어지고 예기치 않은 오류가 발생한다. 1.프로퍼티 접근 오류 const obj: any = { name: "Alice" }; const age: number = (obj as { age: number }).age; console.log(ag..

.작성중 map의 key 속성을 사용하는 것이 비권장인 주된 이유들은 다음과 같습니다: 성능 이슈: 매번 렌더링할 때마다 변경되는 key를 사용하면, React는 해당 요소와 그 자식들을 매번 새로 생성하고 파괴해야 합니다. 이로 인해 불필요한 리렌더링이 발생하며 성능 저하를 초래할 수 있습니다. 컴포넌트 상태 유지 문제: key가 변경되면, React는 해당 컴포넌트의 상태를 잃어버립니다. 따라서 상태를 유지하려면 안정적인 key를 사용해야 합니다. 인덱스 사용 문제: 배열의 인덱스를 key로 사용하는 것은 안티패턴으로 간주됩니다. 배열에 항목이 추가되거나 제거될 때 인덱스가 변경되므로, 이러한 변경이 컴포넌트의 상태와 관련된 버그를 유발할 수 있습니다. 키 충돌: 유니크하지 않은 key를 사용하면 키..

문제 getServerSideProps를 이용하여 api를 요청했을 때 페이지 요청이 너무 오래 걸리는 문제(4~10s) 가 발생했다. 정확히는 api 요청이 아니라 페이지의 로드 자체가 오래 걸렸다. 일반적으로는 api 최적화, 로딩스피너 추가, 이미지 최적화 등을 고려해 볼 수 있으나 내 페이지에 이미지는 없었고 api 요청만 존재 했다. 그러나 비제한적인 호출을 위해 크롤링 api 를 활용했고 고질적인 시간 지연 문제가 발생했다. api를 최적화 할 순 없나? 유투브 써드파티 라이브러리를 사용하기로 한 이상 속도는 타협해야 했다. 크롤링 후 재가공 결과를 반환하는 api임을 감안하면 현실적인 속도이다. 로딩 스피너를 달거나 UI만 미리 불러올 순 없나? 가장 큰 문제는 써드파티 유투브 api는 클라..