TIL

npm은 사람들이 만들어 놓은 코드들을 패키지별로 묶어서 마치 "상품을 구매하듯" 모듈형태로 가져올 수 있는 시스템이다.이 npm의 문제는, 서로의 의존성이 엮여있는 dependency tree의 특성상 버전을 하나하나 다 맞춰주기가 어렵다는 점이다.예를 들어, 어떤

프로그램 => 운영체제로부터 자원을 할당을 받으며 실행이 가능한 논리 단위이다프로세스 => 운영체제로부터 자원을 할당받은 후실제 메모리에 탑재되어 운영되고 있는 프로그램의 단위이다.스레드 => 프로세스 안에서 작업을 실행할 수 있는 실행단위를 뜻한다.스레드들은 프로세스

우선 유저가 브라우저의 url 입력창에 주소를 입력하고 엔터를 누른다브라우저는 해당 url을 파싱하여 의미별로 분리한다http = hyper text transfer protocol, html 와 같은 문서를 서버에 요청할때 쓰는 통신규약이다. 이 외에도 FTP,SSL

위의 내용을 간단히 정리한다1\. 크게 3개의 페이즈로 구분해서 생각한다 ( mount, update, unmount)2\. 마운트, 업데이트때 해당 컴포넌트의 업데이트 기준을 찾기 위한 props 혹은 state을 구한다 ( getDerivedStateFromProp

서버사이드 랜더링이란 서버에서 랜더링의 책임을 지는 방식을 말한다보내지는 html의 내용에 초기랜더링에 필요한 정보가 충분히 존재하는지 안하는지가 SSR과 CSR의 차이를 만들어낸다SSR은 초기에 서버로부터 필요한 페이지의 내용이 다 담긴 html을 받게된다. ( 다

url을 기반으로 통신하여 html 문서를 출력하거나 그래픽을 표현하는 "응용 소프트웨어" 이다.사용자 인터페이스 => 주소 표시줄, 북마크 등과 같은 렌더링 창을 제외한 부분(상단)브라우저 엔진 => 해당 사용자 인터페이스의 요청을 처리하는 엔진렌더링 엔진 => 콘텐

useEffect는 비동기 함수이다 (충격... 나는 그냥 비동기를 디자인을 흉내낸 일반함수인줄 알았다)따라서, setTimeOut처럼, React DOM을 계산하여 형성하고, 페인트가 마무리가 되는(return부) 시점에 내부에 들어가있는 함수를 실행시킨다이 말인 즉

컴포넌트 제작 중, 이미지의 내용물을 변경하는 과정에서 리랜더링을 기대하였으나 의도대로 변경되지 않았다알기로는, 리엑트에서 리랜더링이 되기 위한 가장 큰 베이스조건은부모 컴포넌트가 리랜더링 된다prop의 내용물이 변경된다내부의 상태가 변경된다현재 aws의 데이터베이스

간단하게 말해 OAuth는 구글과 같이 안정적이고 대중적인 서비스 업체에서 사용되는 기능을,다른 서버의 사이트에서 이용하고 싶을 때 필요한 인증과정이다단순하게 다른 사이트의 서비스를 이용하기 위해 클라이언트가 타 사이트에 자신의 구글아이디와 비밀번호를 전달해주고, 그

웹 개발을 진행하다 보면 브라우저의 호완성과 자신이 쓴 코드를 비교를 할 수밖에 없게 된다.예를들어, 모듈 시스템인 ESM은 ES6부터 지원이 가능하다. 대부분의 모던 브라우저는 이를 지원하지만 구식 IE와 같은 환경에서는 해당 시스템이 지원이 되질 않는다. 그렇다고

우선 기본 베이스로 정리해두고 갈 내용은 이렇다async : 함수 내에서 무엇이 리턴되든, 해당 내용을 promise 객체로 변환시켜 리턴한다.await : 함수 내에서 해당 코드의 마이크로테스크 큐가 완료될때까지 모든 함수블록 내의 코드는 스탑된다.try...catc

기본적으로 프로미스 에러를 처리하는 방법은저렇게 잘못된 주소에서 거부되면 catch를 통해 받는다는 것을 기억하고 있다.여기서 fetch 역시 프로미스 객체이다.프로미스 객체를 만들기 위해 사용되는 Promise 빌트인 생성자 함수는 암묵적으로 new를 통해 객체를 생

ES6 에서 정의하는 메소드 형태로 정의한 함수는 그 내부에 \[HomeObject]라는 내부슬롯을 가진다.이 내부슬롯이 칭하는 대상은 자신을 바인딩하는 객체를 지칭한다.이때, super 키워드는 자신을 바인딩하는 객체의 prototye에 접근하기 위한 식별자이다.예를

자바스크립트엔 타입이 존재한다.자바스크립트에 타입이 존재해야 하는 이유는 크게 3가지가 있다식별자에 할당하는 값, 즉 메모리에 저장해야 하는 값이 어느정도 크기여야하는지에 따라 메모리 공간 크기를 결정하기 때문이다 (저장성)메모리에 저장된 값을 불러들일 때 어느정도만큼

Singleton이라는 의미는 전체 앱에서 해당 객체는 유일해야 함을 보장하고 싶을 때 만드는 패턴이다.클래스는 다른 클래스를 상속할 수 있는 기능인 extends라는 문을 가지고 있다. 이 extends의 기능을 정확하게 알아야만 싱글톤이 어떤 장점을 가지고 있는지를

이벤트 처리에 있어서 만약 스크롤을 했을 떄에 모든 스크롤의 움직임에 대하여 이벤트가 걸린다면 웹의 부하가 막중할 뿐더러 그 이벤트마다 서버에 요청을 보낸다면 서버에도 영향을 준다. 따라서 해당 이벤트를 적절하게 처리하는 방법이 필요한데, 그 방법중 2가지가 스로틀링과

IP 패킷의 구성요소의 가장 핵심적인 부분은 역시 ip 어드레스 즉, 상대방 공공ip 주소일것이다.단순하게 상대 컴퓨터의 주소인 IP를 가지고 전송하던 IP 패킷만으로는 문제점이 있었다.비연결성 => 해당 응답서버의 ip 대상이 없는데도 불구하고 클라이언트는 모르기에

Document type의 약자로, 받아온 html 문서의 버전을 표시하여 브라우저가 표현해야 될 내용을 정확하게 표현하도록 선언하는 역할만약 선언하지 않을 경우 Quirk mode라는 구형 브라우저 지원용 호환 타입으로 document를 표현하기때문에 원치않게 표현될

브라우저는 처리해야 할 특정 사건을 감지하여 이벤트를 발생시킬 수 있다. 이때 호출되야 할 함수를 이벤트 헨들러 라고 한다개발자 입장에선 함수가 언제 호출되야할지 알 수 없으므로, 마치 aws의 람다에게 함수호출을 위임하는것처럼 브라우저에게 이벤트에 대하여 함수호출을

웹팩과 같은 모듈 번들러가 없던 시절, 항상 서버로부터 html 문서를 받아오면 파싱을 시작하고, script 태그를 만나게 되면 진행과정이 정지하면서 스크립트파일요청 및 처리를 진행하게 된다.http1.1 버전일 때에는 연결을 지속적으로 유지시킬 수 없었기 때문에 파

for of가 작동하기 위해서는 객체 내부적으로 Symbol.iterator 특수 내장 프로퍼티가 존재해야 한다.Symbol.iterator은 함수로, 호출하는 순간 이터레이터를 리턴한다.이터레이터란 상태와, 그 상태를 변경할 수 있는 next 라는 함수명을 가진 메서

예전에 react-native에서 스타일링과 관련한 객체를 컴포넌트보다 아래에다가 정의하는 것을 적극 반영하여 이를 활용중이었었다그런데 비슷한 형태로 createGlobalStyle인 템플릿 리터럴에다가 css 메서드의 스타일링 도출값을 바닥에다가 적용했더니 이번에는

객체 지향적 관점에서 특정 메서드가 상태를 변경시켜야 할 때에 그 상태를 보유한 객체 스스로를 언급해야 할 필요성이 있다.또한 생성자 함수에서도 초기화되기 전 암묵적으로 생성되는 더미 객체를 지칭할 키워드가 필요한데 그때 쓰이는 것이 this다.하지만 this의 특성상

일반적으로 브라우저가 웹페이지를 화면에 보일 때에는 크게 2가지의 경우의 수가 존재한다.1\. html 문서를 파싱하여 DOM 트리를 만든다2\. 그 후, DOM의 요소가 변경될 때마다 Reflow, Repaint를 진행한다.이게 단순히 한두가지의 컴포넌트가 변경되는

공식문서에 따르면, 리엑트의 훅이란 기존 클래스 컴포넌트에서 사용하던 생명주기와 관련된 상태와 함수들을 함수 컴포넌트에서도 사용이 가능하도록 연동시킨 함수이다.기존에는 이 생명주기와 관련된 함수들을 사용할 때 몹시 리펙토링과 디버깅에 어려움을 많이 겪었는데, 역시나 공

솔직히 말하면 나는 구글이 제일 Oauth의 문서가 어렵다고 생각했는데, 그 상상을 뛰어넘는게 바로 네이버 Oauth임을 밝히고싶다.아니, 정확히 말하면 문서 자체는 어려운건 아니다 (한국어고) 근데 가장 큰 문제는, 정식 문서에 있는 내용이 구식 버전이라는 점이다 (

자바스크립트 코드는 우선 V8과 같은 자바스크립트 엔진의 안에 있는 어휘분석기(scanner)을 통해 토크나이징이 이루어지고, 분류된 토큰들에 문제가 없다면 구문분석기(parser)에 전달되어 AST를 형성한다AST는 기계가 이해할 수 있는 바이트 코드로 전환되고(v8

과거에는 컴포넌트가 마운트되는 과정에서 그 내부에 자바스크립트의 코드들이 발생하는 에러를 핸들링할 방법이 존재하지 않았다. 따라서, 일부 UI의 자바스크립트가 에러를 발생시킬 경우 전체 어플리케이션이 중단되는 불편함이 존재하였다.물론, 모든 컴포넌트에서 에러를 잡기 위

개발을 하다보면 상태관리가 필요해지는 경우가 많다. 상태란, 동적으로 변경되는 데이터를 의미한다. 이때 변경될 상태는 크게 두가지로 분류할 수 있다.1\. 로컬 상태상태값이 특정 컴포넌트 내에서 귀속되는 데이터를 의미한다. 해당 데이터는 오롯이 컴포넌트 내부에만 영향을

주소의 형태는 크게 URI 와 URL로 구분할 수 있다.이때, 캐싱 기록을 찾는 순서는 브라우저 -> OS -> Router -> ISP 순으로 이루어진다.캐싱을 사용하는 이유는 DB에 지속적으로 I/O가 발생하는 경우 너무 비싼 비용이 들기 때문에 순수하게 정적 데이

최적화는 성능을 저해하거나 불필요한 코드들을 줄여 퍼포먼스를 극대화하는 과정을 말한다.보통 브라우저의 로딩이 1초 느려질 때마다 고객들이 떠나가는 비율은 7% 이상이 된다고 하니, 브라우저의 화면에 필요한 정보가 빠르게 나오도록 만드는 과정은 몹시 중요하다.E comm

REST API란, representational state transfer 의 약자로, 웹에서 사용될 데이터나 자원의 요청경로를 URI 형태로 정의하고,Http method( GET, POST, PATCH, DELETE... 등) 을 통해 어떤 형태로 작업하길 원하는

Next.js는 서버사이드 랜더링을 손쉽게 가능하게 하는 프레임워크이다리엑트는 라이브러리이다. 즉, 개발자에게 유저 인터페이스를 만들기 위한 플랫폼을 만들어 주고 필요한 라이브러리를 가져다가 쓰게 하는 패키지이다하지만 Next.js는 프레임워크로, 필요한 기능이나 내용

Next.js는 서버사이드와 클라이언트 사이드가 공존하기 때문에, env파일을 사용할 때에 서로 다른 형태를 취한다우선 서버사이드 렌더링에서 env파일을 사용하려면, node.js에서 하던것처럼 process.env로 접근하면 된다단, 서버사이드 랜더링과 관련된 곳에서

React는 그 자체로도 훌륭하지만, CSR에 의한 몇가지 한계점이 존재한다초기 랜더링 후, 서버로부터 데이터를 패칭받기 전까지의 시간이 걸린다pure React는 서버로부터 html을 받은 후, JS를 파싱하여 DOM을 조작함으로써 (혹은 요소들을 채워넣음으로써) 브

보통, react component에서 useRouter을 이용하여 path와 param 정보를 얻어냈을 것이다.그리고나서 해당 데이터를 이용해서 useEffect를 통해 서버에 자원을 요청하고 하는 방식이 가능하다.그러나 해당 방식은 클라이언트 사이드에서 데이터를 패

일반적으로, http 통신의 가장 큰 특징은 "무상태성" 이라는 것이다.무상태성이란, 통신 이후 상대방의 정보를 기억하지 않는다는 점이다. 즉, 일반적인 요청 <-> 응답의 관계인 http 프로토콜에서 상대방이 누구인지를 기억하지 않으므로, 확장성에 용이하다. 또

Cross site scripting의 약자로, 웹 어플리케이션의 취약점을 이용해 여러가지 코드를 이용하여 자바스크립트를 실행하게 만들어 타격하는 공격방식이다. 공격에 성공하면, 사용자의 브라우저는 의도치않게 삽입된 코드를 실행하여 의도치 않은 행위가 발생하거나 쿠키,

Next.js의 SSR은 미리 pre-rendering을 해놓고 유저가 해당 경로로 접근을 할 때 그 페이지를 제공해 주는 형태이다.이때, 주목해야 할 점은, Next.js는 빌드 과정에서 이미 어떤것을 server폴더에 있는 html을 전달해줘야할지(SSR) 아니면

브라우저는 chrome, safari, firefox등 다양한 종류가 있다. 그리고 그 다양한 종류만큼 서로간에 다른 내부적인 렌더링 엔진이 서로 다르다.렌더링 엔진이 다르다는 것은 어떤 곳에서는 사용 가능한 css 옵션이 어디에서는 사용될 수 없거나, 어느 브라우저에

가볍게 테스팅할거라 express로 만들지 않고 firebase의 realtime DB를 임시 endPoint를 만들어줬다.(요즘 Sanity.io도 그렇고 이렇게 가볍게 테스팅할 임시 DB가 인기가 많은거같다)index.d.ts를 살펴보니, 멋대로 추론하여 any를

크로스 브라우징에서도 언급됬던 내용처럼, 세상엔 다양한 브라우저가 있고 브라우저마다 랜더링 엔진이 서로 다르기때문에 발생하는 문제점들이 있다.1\. css 호환성이 서로 다르다. (즉 css 옵션을 쓸 수 있는 환경이 서로 다르다. Can I Use를 통해 확인해야 한

Next.js는 html에서 부분을 컴포넌트를 통해 설정할 수 있다이때 헤드부분에는 일반적인 html의 헤드에 들어갈 수 있는 부분이 다 들어올 수 있다.Next.js는 우선적으로 app을 확인하기때문에, 만약 index인 메인페이지에 헤드 컴포넌트를 설정하면 그것은

javascript에 타입중 하나인 Symbol은 특수하게 작성되는 데이터값을 생성할 수 있는 생성자 함수이다.기본적으로 웹 브라우저가 실행되면서 전역객체가 만들어질 때, 빌트인 생성자 함수로 제공되는 객체이다.Symbol을 대표적으로 활용할만한 상황은 enum이다.예

브라우저가 HTML을 파싱하면 DOM 트리가 만들어진다.이때, 만들어지는 DOM 객체는 스타일링이 적용이 되지 않은 모든 태그들이 반영된 객체이다. (즉, css적으로 display:none와 같은 것이 적용되지 않은 상태다)이 후에 브라우저는 이 DOM과, CSS를

브라우저와 서버는 기본적으로 무상태성과 비 연결성을 가진다.그러나 경우에 따라 실시간으로 업데이트가 이루어져야 할 경우, 서로의 통신이 주기적으로 이루어져야 할 떄가 있다. (ex, 실시간 채팅)그런 경우, 주기적인 통신의 방법으로 크게 4가지가 존재한다.클라이언트가

리엑트 개발을 하다보면 map을 이용하여 element들의 배열을 만들어낸 후 이것을 트리에 삽입하려고 하면 이러한 문구를 마주하게 된다.공식문서상 리엑트가 말하는 key의 의미는 아래와 같다.즉, 키를 사용하는 이유는 리스트들의 각각에게 의미있는 증표를 부여하여어떤

최근 ContextAPI를 억지로(?) 사용해보면서 Redux를 사용했을 때와 차이점을 확인하고 싶었다.contextAPI는 React가 기본적으로 제공해주고 있는 의존성 데이터 주입 도구이다. 엄연하게 말하자면 상태 관리 도구라는 명칭보다는 데이터 주입 도구라는 의미

공식문서에 따르면 제어컴포넌트의 설명은 아래와 같다변경 가능한 값을 상태로 관리하는데, 리엑트 컴포넌트는 폼에 입력되는 사용자값을 제어한다고 한다.이 말만 봐서는 도대체 무슨소린가 싶을것이다. 아래의 예시를 보면아하! 하고 위의 내용을 보면 이해가 된다. 클래스 컴포넌

상태는 크게 Client State와 Server State로 나눌 수 있다Client State은 브라우저에 의해 나타내지는 최신 데이터로, ajax 요청에 의해 서버로부터 받아온 그 당시의 최신 snapshot을 나타낸다Server State은 서버에서 관리되고 있

useMutation은 그 이름대로 mutation을 위한 패칭 메서드로, react-query에서는 일반적인 get요청에 대해서는 useQuery를 사용하라고 권하지만 CUD(create, update, delete) 와 같이 서버의 데이터값을 변경시킬 수 있는 사이

전적으로 레퍼런스를 참조한 내용입니다"현재 사이트에는 Hero가 있고""아래에는 각종 이미지들이 있습니다""Lighthouse 95점 이상""Hero 이미지크기 120kb 미만""script resource 크기 60kb 미만""fast 3g 환경일 시, Home 첫

프로세스란 컴퓨터가 OS로부터 실행명령어, 변수, 함수 등을 할당받아 메모리에 탑재되어 실행되는 단위를 뜻한다.일반적으로 브라우저마다 다르지만, 크롬 브라우저가 켜지는 순간 여러개의 프로세스들이 동시적으로 실행이 된다.대표적인 프로세스들은 다음과 같다 Browser P

리엑트에서 SSR을 한다고 생각하면 이런 방향으로 진행될 것이다 (next.js를 다시 떠올리며)서버사이드에서 필요한 데이터를 fetching한다 서버사이드에서 처리한 html을 response로 전달한다.클라이언트 사이드에서 브라우저는 html의 스크립트 태그를 파싱

중복되어도, 복습의 개념 및 설명할 수 있는 정도로의 개념으로 재학습해서 정리한다사용 이모지 리스트 : ⌚️ 📱 📲 💻 ⌨️ 🖥 🖨 🖱 🖲 🕹🚲 🛵 🏍 🛺 🚨 🚔 🚍비동기 작업은 콜스텍이 아닌 브라우저 기준 web API에 의해 캐치되어 콜백

React에서 virtual Dom을 통해 생명주기라는 단어를 들어본 적이 있지만 HTML의 생명주기라는 것은 몹시 생소했다이에 따라 내용을 정리한다복습과 설명수준의 지식을 위해 다시금 복습하자면, React의 생명주기는 크게 Mount, Update, Unmount의

공부를 하던 도중, 아주 근원적인 부분에서 착각하고 있었던 것을 책을 보고 깨달아서 정리를 한다위의 두 문(명령문) 은 변수의 선언과, 값의 할당이라고 하는 실행적인 의미를 지닌다.이때, 리터럴 값인 80은 평가가 되어 2진수가 되며 타입과 함께 메모리 공간에 저장되고

요 근래 나만의 프로젝트를 만들면서 코드를 제작하다 보니 점점 너저분해지는 감각을 버릴 수가 없었다.심지어 원래 import되어서 오는 컴포넌트와 내부 컴포넌트를 구분하고 Media query를 컴포넌트별로 독립적으로 관리하도록 만드려고 했던 구조가 점점 값을 참조하기

위에서 Component 클래스의 타입정의를 살펴보면 이렇게 React Element 객체를 만들기 위해 필요한 각종 프로퍼티와 메서드들이 정의되어 있다.new를 통해 생성한 객체의 내부사항은 위와 같다.참고로 재미있는점은, 상속받는 Component 클래스에는 이미

일반적으로 무한스크롤과 같이 lazy-loading 을 통해서 데이터를 특정 조건적으로 호출해야 할 경우가 존재한다.scroll 이벤트로도 할 수 있겠지만, scroll을 사용하게 된다면 매 스크롤마다 이벤트가 발생하므로 성능저하에 영향을 준다.이럴때 사용할 수 있는

현대에 들어와서 모듈 개념으로 파일별로 구분하여 작업하고 import를 통해 가져와 의존성 트리를 만드는 것은 일반적이 되어가고 있다.하지만, 이렇게 나누어진 모듈들을 만약 아무런 체계 없이 전부 다 분리된 상태로 배포하고 그것을 브라우저가 특정 작업마다 매번 요청해야

그림을 그릴 때 도화지 역할을 하는 캔버스의 의미처럼, Canvas태그는 그 내부에서 도형, 데이터, 애니메이션 등 다양한 내용들을 그릴 수 있는 태그이다주의! canvas를 css로 width와 height을 설정할 경우, 내부에 있는 옵션들이 제대로 작동하지 않는다

이름에서도 볼 수 있듯이, mouseover event는 타겟에 마우스 포인터가 올라갈 때, 그리고 mouseout은 타겟에 마우스 포인터가 떠날 때 일어난다.이때 이벤트 객체에는 1. target, 2. relatedTarget 이렇게 두가지가 존재한다. target

저 간단한 것을 위해 얼마나 많은 시간이 걸렸는가...내가 담당했던 부분은 초기 API 데이터 요청 10개 단위로 한 후에, 이것을 리스트로 나타내고 무한스크롤 로직도 살짝 발을 담가보는(?) 일이었다.우선 첫날 팀장님의 권고하에 next.JS를 실제적으로 사용해보게

중복되어도, 복습의 개념 및 설명할 수 있는 정도로의 개념으로 재학습해서 정리한다리엑트가 만들어진 이유를 알기 위해서는 우선 브라우저의 랜더링 과정과 이의 비효율성을 알아야 한다.브라우저는 1\. html을 파싱하여 DOM트리를 만든다2\. 비동기적으로 CSS 파일을

웹개발을 하다보면 필연적으로 드래그와 드롭을 사용하게 된다. 해당 옵션에 대해서 명확하게 알고 있어야 사용할 수 있으리라는 생각이 들었으므로 정리를 한다.이번 내용에서는 기본적인 옵션을 살펴보고, 마우스이벤트 (2)에서는 타입스크립트 + 리엑트를 적용한 드래그 앤 드랍

Next.js로 개발을 하다보면, 초기 설정을 할 때 각 페이지에 위치시킬 수 있는 특별한 컴포넌트 "next/head"와 \_document 파일에 위치하고 있는 "next/document" 의 Document 컴포넌트가 따로 존재한다는 사실을 알 수 있다.나는

lo1depth만으로도 이렇게 힘들줄이야...이번 기업과제에서 담당했던 내용은 댓글 파트 구현 부분이었다.그냥 평범하게 생각하면 댓글만 적용하면 된다고 생각했는데, 해당 내용에 대댓글을 위한 파트가 존재했어서 상당히 많은 고민을 하게 만들었다. 우선 발란에서 제공하는

자바스크립트를 처리하는 엔진은 싱글 쓰레드로, 하나의 일처리밖에 처리를하지 못한다.이것을 보완하기 위해 비동기적인 처리를 담당하는 event loop를 설정하여 해당 스레드가 처리가 완료되면 순차적으로 이벤트를 처리하는 개념이다.컴파일러가 js 파일을 파싱하기 시작하면

block별거 아니라고 생각했던 너, 너는 나에게 모욕감을 줬어처음에 아주 간단하리라고 생각했던 파인더 폴더블록구조였으나 상당히 많은 로직이 존재하는 것에 고통을 느끼며 만들었다.가장 어렵게 되는 부분이 클릭, ctrl+클릭, shift+클릭 의 과정이 모두 연동이 되

콘솔상으로 데이터는 업데이트가 되고 있다. 그러나 요청은 날리지 않는다! 이것이 바로 캐싱!asdfasdf사실 나는 이제까지 리엑트 쿼리를 내가 잘 이해하고 있었다고 생각했고, 이번에 기업과제 제작을 하면서 팀원들이 react-query를 사용해보자는 요청에 혼쾌하게

브라우저의 랜더링 과정UI 프로세스에서 해당 URI를 분석해 이것이 검색어인지 아니면 DNS 주소인지 파악한 후, 검색요청이라면 해당 서버의 검색쿼리를, DNS 주소라면 브라우저캐시 -> 라우터 캐시 -> IP CDN 서버 캐시 등을 타고올라가 해당 DNS 네임과 연동

CORS에 대해서 다루려면, 우선적으로 SOP에 대해서 먼저 이해를 해야 한다.SOP는 Same-Origin-Policy의 약자로, 브라우저에 로드되어 있는 document나 script가 다른 origin의 리소스와 상호작용을 하는 것을 막는 정책이다.이것이 가능한

이전에 이미 REST API에 대해서 공부하여 정리했었고, 사용을 많이 해봤으므로 완전히 안다고 생각했으나 면접질문에 답변을 할 때에 정확하게 무엇인지 설명을 못하는 내 자신을 바라보며 재정리를 하자는 마음으로 쓰는 글이다.그리고 나중에 블로그를 볼 때에 여러번 노출되

cal달력이 쉬워보이니?솔직하게 말하자면 이 프로젝트를 마주하기 전까지 library를 쓰는 것은 내 스스로에게 패배(?) 하는 것이라고 생각하고 있었다. 그래서 남이 만들어 놓은 것을 가져다 쓰기보다 내가 직접 구현해야겠다! 라고 일정을 고려하지 않은 말도안되는 자신

중복되어도, 복습의 개념 및 설명할 수 있는 정도로의 개념으로 재학습해서 정리한다주기적으로 블로그에 내용이 노출되면 나중에 볼 때에도 반복학습을 할 수 있는 계기가 된다.항상 재정리를 하는 근본적인 이유는 하나다. 기억을 못해서이다.블로깅에 정리를 했다고 한들, 인간인

항상 레이아웃을 짤 때 어떤 방식으로 할지 항상 고민을 하는데, 의도치 않은 css가 나오는 것 만큼 스트레스가 받는 일이 있지는 않은것같다.이번에 레이아웃을 짜면서 처음으로 의도한 대로 완벽하게 공간을 메꾸는 것을 보고 앞으로는 이런 식으로 계속 해봐야겠다는 생각을

개발을 하면서 여러가지 요소들을 고려해야 하지만 그중에 단연코 노하우가 필요하면서도 섬세하게 다뤄저야 할 부분이 바로 에러처리라고 생각한다. 일반적으로 아무런 생각없이 단순 기능구현을 목적으로 하는 개발은 1차적인 개발이라고 생각한다. 물론 그 자체도 훌륭하지만 완벽하

B이 외에도 이것저것 많이 들어갔는데 돌이켜보니 너무 힘들었다...이번에 제작하게 된 개인과제에서는 데이터를 조회하여 카드형태로 나타내기만 하면 어떻게 보면 가벼운 과제라고 생각했으나 그 내부에서 이것저것 추가하다보니 여러모로 너.... 무 고생하고 힘들었던 순간이 많

예전, React가 DOM을 업데이트하는 과정을 정리했을 때에 나는 무언가 react에 대해서 다 깨달은 것이라고 스스로 과신하고 있었다.그런데, 요 근래 깨달은 것은 나는 그냥 수박 겉핥기 식으로 react를 알고 있었다는 점을 알게 된 것이다.그것은 최근 작성한 r

아마 중복되었을 수 있는데, 복습의 개념 및 설명할 수 있는 정도로의 개념으로 재학습한다는 느낌에서 정리해본다무상태성 : 클라이언트를 서버가 기억하지 않는다. 서버는 요청에 응답만 하는 구조이다. 즉, 어떤 서버 컴퓨터가 응답을 하더라도 동일한 결과를 가져오기 때문에

웹개발을 하다보면 네트워크를 통해 파일을 받게 되는데, 이때 파일은 주로 2진 데이터로 이루어진 것이 일반적이다. (0과 1로 이루어진 세계) 다만, 가끔 보면 이 2진데이터에 대해서 상당히, 혼란스러울정도로 다채로운 분류가 있음을 알 수 있는데 예를들어 ArrayBu

에전 블로깅 내용에서 뒤로가기, 앞으로가기에 대해 막는 방법에 대해서 회고를 남긴 적이 있었다. 페이지 라우팅 에러처리그 때에 여러가지 검색 결과, 보안 상 어쩔 수 없이 history를 비우는 행위를 하지 못하도록 막아놨기 때문에 결국 조건부로 어떤 데이터가 존재하는

사실상, 함수형 프로그래밍에 익숙하고 리엑트의 함수 컴포넌트가 점차 일반화되는 시점에서 This를 보게되는 상황은 매우 드물다고 할 수 있다.하지만, 그렇다고 하여 객체 지향적 개발이 레거시가 된 것도 아닐 뿐더러 angular나 일부 객체지향적 데이터베이스(ex, t

사실 클로져는 이제까지 쓴 블로그 내용 가운데 한번이라도 언급이 됬을 가능성이 높다. (그만큼 워낙 중요한 특성이니)근데, 다른 사람에게 해당 내용을 설명하려는 상황이 있었는데 명확하게 용어로 설명하지 못하는 나를 바라보며 반성하고,남에게 설명할 수 없다면 그것은 알지

요즘 면접준비를 하면서 react 관련 내용을 살펴보다가 hook 에 대해서 설명해야 하는 부분이 있었다.일전 공식사이트에서 내용을 살펴본 기억은 있었다.뭐라 내용이 많다만나는 해당 내용을 이렇게 이해했다 (우선 우리는 hook 이 없는 세계의 함수 컴포넌트를 사용한다

최근 react 18 관련 자료들과 블로깅을 보면서, 나는 hydration이라는 개념이 아예 리엑트에 내장된... 무언가 랜더링 프로세스중에 한가지가 새로 추가된 것이라고 착각하고 있었다만, 그런게 전혀 아니었고 리엑트가 제공하는 기능중에 하나였었는데 혼자 오해해서

이번에 redux-saga와 관련된 개념을 공부하기 위해 미리 선 지식으로 필수적으로 알아야 할 제네레이터의 개념을 공부하여 정리하는 글이다.현재 redux-toolkit으로 상태관리툴이 전환되는 시기점이기도 하지만, 아직 기업에서 redux-saga를 쓰는 기업들이

결론적으로 말하자면, 요새는 redux가 store 역할만 하는 것이 아니라 비동기 처리의 역할까지 담당하게 되면서 너무 비대해진다는 점을 지적하는 사람들이 많아지는 것 같다. 나 역시도 개발을 할 때에 비동기 관련 작업을 삽입하다 보면 "pending", "rejec

이전 비슷한 주제로 신나게 공부하다가 블로그에 똥(?) 글을 작성한 적이 있다. 그때 당시에 정확하지도 않은 정보를 그냥 해외자료라는 이유 하나만으로 신뢰하고 읽고 작성했었는데 그 내용 자체가 완전히 틀렸다는 것을 깨닫고 부끄러워서 다 삭제하고 다시 쓴다.우선 너무나도

이번에 일이 있어서 맥북을 한번 초기화시키는 일이 있었다. 그러면서 자연스럽게 vscode의 기존 설정들도 다 날아갔었는데, 개발을 하던 도중에 아주 많이 쓰던 커스텀 키보드 단축키도 다 날아갔다는 사실을 깨닫고 부랴부랴 인터넷 검색을 하였다.그런데, 이게 참 우연인지

일전 "useEffect 디펜던시 무시하지 마라" 라는 주제로 글을 길게 썼던 게 있었는데, 그때의 내용은 대략 요약하자면 이런거였다useEffect는 비동기적으로 작업하기 때문에, 서로간에 어떤 요청이 먼저 들어올지 모르므로 만약 useEffect끼리 서로간의 작업이

최근 아는 지인으로부터 typescript의 interface는 어떤 작동을 하느냐는 물음에 이것저것 찾아보다가 알게 된 내용을 정리해본다.Javascript 코드는 Scanner에 의해 분해되어 가장 작은 의미론적 단위인 "Token" 의 모음이 된 후, Parse

항상 나는 복습을 하는 것을 좋아한다. 이 블로그를 쓰는 이유도 내 스스로 복습하고 정리하기 위한 목적이 아주 크다.누군가는 왜 아는것을 또 보고 있냐고 말할 수 있고, 나 역시도 이제는 너무 많이 봐서 당연스럽게 안다고 생각했던 내용들인데다시금 복습하면 새롭게 깨닫는

pdf를 생성한 Buffer 데이터를 클라이언트에게 보내는 과정 중에 문제가 발생했는데, 이 원인을 분석하기 위해 수많은 지식들을 받아들어야 했으므로 정리를 할 필요가 있어서 쓰는 글이다.컴퓨터는 기본적으로 전기적 신호로 통신을 한다. 전기가 흐른다면 1, 전기가 흐르

토이 프로젝트에서 쿠키를 교환하는 일을 하던 도중, XSS 공격에 대한 염려로 쿠키와 보안관련한 내용들을 쭉 공부하다가 다시 정리를 해둘 필요가 생겼다고 생각하여 쓴다. 항상 안다고 생각했어도 다시 보면 까먹고 있는 나지만 이렇게 적다보면 언젠가 암기하는 날이.. 오겠

DBeaver에서 테이블을 import하려고 시도하던 도중, 힙 스페이스가 부족하다는 문구와 함께 가져오는 것이 실패하였다.말 그대로, 연산 처리를 위한 heap 영역이 부족하다는 소리이므로, 해당 설정을 변경하여야 하였다.우선, 실질적인 공간 자체부터 키워줘야 한다.

현재 react-native로 작성되었던 앱을 리펙토링하는 과정을 거치고 있다.그 중에서 좀 많이 도전적이 되었던 기존 코드가 있었는데, 그 줄수만 장장 1191줄에 달하는 내용이었다.해당 내용을 쭉 살펴보면, 분명 필요에 의해서 존재하는 코드들이지만 정리를 해야 가독

UI 작업을 하다 보면, 언제나 문제가 되는 것은 이미지를 화면에 반영하는 것이라고 생각한다.이미지가 잘 나오면 문제가 전혀 없다.항상 문제는, 이미지가 나오지 않을 때 (즉, 에러) 어떻게 이미지를 UI적으로 나타내야 하는가에 대한 고민을 해봐야 하는 것이다.위와 같

면접을 다니다 보면 상당히 많은 분들이 pdf로 된 이력서에 아이패드로 메모를 하시면서 진행하셨던걸로 기억한다.최근 이력서를 홈페이지로 직접 꾸며 배포를 하려는 도중에 위의 기억들이 떠올라서 (그리고 마침 쉽고 재밌을 것 같아서)메모하는 기능을 직접 만들어보면 좋겠다는

최근 개발을 진행하면서 React-Query를 사용하던 중, Refetch와 InvalidateQueries의 비교에 대한 레퍼런스를 동료 개발자분께 전달받아보게 되었다. 작성자는 심플하게 invalidateQueries 를 더 선호한다는 이야기를 해주고 있었다.사실

최근 프로젝트를 다시 재구성하게 되는 상황을 마주하게 되었다. 그 과정 가운데 새로운 레포지토리를 기반으로 프로젝트를 재구축하는 작업을

지난 글이었던 자동화 배포 프로세스의 글에 이어서 이번에는 PM2와 Nginx를 이용한 자동화 프로세스를 구축하려고 한다.