호이스팅
코드가 실행되는 맥락(실행 컨텍스트)에서 변수 선언보다 사용을 먼저 했을 때, 변수 선언부를 변수 사용부분보다 상단으로 옮기는 작업.
Javascript의 변수들은 특이하게도 선언보다 사용을 먼저 해도 호이스팅이라는 것 덕분에 문제없이 동작할 수 있었다. 하지만 let과 const가 등장하면서, 사용하기 전에 선언 먼저 하게끔 안전장치가 마련되었다.
let과 const도 호이스팅은 된다고 한다. 하지만 var와 다르게 초기화가 되지 않은 상태로 호이스팅되기 때문에, 변수에 접근하려해도 메모리 주소가 없으므로 Reference Error가 발생한다고 한다.
리터럴(literal)
소스 코드의 고정된 값을 대표하는 용어 - 위키피디아
"", [], {} 등 자료형 마다 리터럴이 존재한다. 리터럴을 이용해 선언하고 초기화 하는 경우가 많은데, V8엔진 내부에선 리터럴들을 생성자로 치환해서 호출한다고 한다.
const a = {} 가 const a = new Object() 로 읽힌다는 얘기다.
함수 선언문 vs 함수 표현식
함수를 선언하고 사용하는 방법은 3가지가 존재한다.
- 함수 선언문
function a() { ... }- 함수 표현식
const a = function() { ... }
const b = () => { ... }
// 둘은 this의 차이가 있다.- 함수 생성자
const a = new Function("...")함수 선언문의 경우, 코드블럭이 실행되기 전에 미리 처리되기 때문에 선언순서에 상관없이 사용가능한 반면, 표현식은 변수와 마찬가지로 실행 컨텍스트가 표현식에 도달하면 생성된다.
함수는 선언되면서 자신이 어느 환경에서 만들어 졌는지를 보이지 않는 property에 저장한다. 이러한 출생지(?)를 Lexical Environment라고 한다.
function b() {
function a() { ... }
const c = new Function("...")
let d = 1;
...
}a의 lexcial은 b가 될 것이고, b는 전역이 될 것이다. 하지만 c는 b가 아닌 전역 lexical로 저장된다. 따라서 함수 b 내부에 있는 변수 d에 접근할 수 없다.
최소 단위 컴포넌트
component를 어디까지 쪼갤 것인가?
개인적으로 나눴던 최소 단위는 '화면-기능'이었다. instagram의 메인 페이지(모바일 기준)를 생각하면 header, Post List, Nav Bar 로 크게 나눌 수 있고, Post List는 여러 Post로 구성되어있다. 여기서 Post가 내가 생각하는 가장 작은 단위의 component였다.
하지만 강의에선 이보다 더 작은 단위까지 세분하고 있다. Header의 icon도 component로 나누고, 모든 Image들을 하나의 component로 묶음과 동시에 나누고 있었다. 심지어 작성자명이나 게시글 내용같은 Text도 하나의 Component로 묶어서 나눴다..
이렇게 까지 나눌 수 있다는 걸 알게 되고, 나눈 결과를 봤을 때 '생각보다... 괜찮은데..?' 라는 생각이 들었다..
나쁘지 않아보였다.
prototype
🚧 수정중입니다.. 🚧
javascript는 원래 class가 없었다. 비교적 최근에 추가되었고, 태초부터 없던거라 익히 알고있는 cpp나 java의 class와 본질이 약간 다르다.
OAuth
흔히 알고있는 SNS 로그인의 인증과정.
제 3의 서비스에 존재하는 사용자 정보를 통해 인증하는 방법이다. OAuth 안에서도 여러 방법이 존재하는데, 가장 많이 언급되는 Authorization Code Grant Type에 대해 작성해보겠다. 동화를 예시로 만들어가며 이해해보았다.
🚨 주의! 다소 어이없는 내용일 수 있습니다!
옛날에 일처다부제 왕국의 공주와 결혼하고 싶은 남자가 찾아왔다.
"공주님과 결혼하게 해주십시오!"
(사용자가 서비스 이용시도.)왕은 그에게 시련을 주었다.
"저어기~ 뒷산에 겁나 무섭고 거대한 용이 살고있는데, 거기서 알을 하나 가져오면 인정해주지."
(서비스를 이용하기 위해선, 구글 계정인증을 하면 주는 권한증서(Authorization Grant (a.k.a code))가 필요함.)남자는 왕의 시련을 완수하기 위해 두려움을 무릅쓰고, 용을 찾아갔다.
용은 남자가 올 것을 이미 알고 있는 것 같았다."어~ 왔나? 즈어기 앞동네 왕이 오라캐서 왔제? 요섀 코로나니까능~ 일단 명↗부↘부터 쟉셩해라! 이럼(이름)! 사능 곧(사는 곳)! 즈나버노(전화번호)! 단디 쓰라이~(꼼꼼히 작성하시오)"
(구글 로그인(필요에 따라 회원가입).)생각보다 친근한 용의 말투에 어리둥절한 남자는 일단 용이 시킨대로 명부를 작성했다.
명부를 작성하자, 용은 자신의 알을 건네줬다.
(사용자에게 권한증서 전달. (구글 -> 사용자))알을 들고 다시 돌아온 남자는 왕에게 증표로 알을 건네줬다.
(서비스에 권한증서 전달.(사용자 -> 서비스))이제 결혼하는 일만 남았다 생각했지만, 의심많은 왕은 쉽게 승낙하지 않았다.
"이게 비둘기 알인지, 메추리 알인지 어떻게 아나?"
왕은 신하에게 '알을 가지고 용에게 찾아가, 용의 알이 맞는 지 확인할 것'을 명령했다.
신하가 가져온 알을 본 용은 단번에 자신의 알임을 확신했다.
"대굴빡이 딱! 우리 집안 알이네!"
(사용자로부터 받은 권한증서를 구글에 전달 및 확인.(서비스 -> 구글))용은 남자가 작성했던 코로나 명부와 자신의 발바닥 도장이 찍힌 종이 두 장을 신하에게 건네줬다.
(구글은 사용자 정보와 access token, refresh token 등 필요정보를 서비스에게 전달.)남자는 성공적으로 왕으로부터 인정받았고, 왕국의 일원임을 증명하는 용발바닥 도장이 찍힌 종이를 하사받았다.
(구글에게서 받은 access token을 사용자에게 전달.)그리고 공주의 10,473번째 남편으로 행복하게 살았다.
상세한 내용들이 생략되어있지만, 전체적인 흐름은 위와 같다고 생각한다.
redirection URI, client ID & PW 등 좀 더 다양한 정보들이 인증과정에서 필요하고 사용된다.
이해하는데 있어, 아래의 링크글들로부터 도움을 얻었다.
- https://tansfil.tistory.com/60
- https://velog.io/@piecemaker/OAuth2-인증-방식에-대해-알아보자
- https://cheese10yun.github.io/oauth2/
토큰 저장소(브라우저 저장소)
Cookie
특징
key, value형태로 저장하며, 4KB의 저장공간을 갖는다.- http header에 담겨 요청마다 전달할 수 있다는 장점.
- 옛날부터 전해 내려오던 저장소.
사용, 추가 및 삭제
// 사용
console.log(document.cookie);
// 추가
document.cookie(
"MY_COOKIE=hello; expires=new Date('2030-12-31').toUTCString()"
);
// 삭제: 추가와 동일하나, 만료일을 과거로 설정.Session Storage
특징
- Cookie와 마찬가지로,
key, value형태로 저장. - HTML5부터 추가됨.
- 브라우저를 닫으면 사라짐.
사용법
// 추가
sessionStorage.setItem("MY_SESSION", "hello");
// 사용
sessionStorage.getItem("MY_SESSION");
// 삭제
sessionStorage.removeItem("MY_SESSION");
// 몽땅 삭제
sessionStorage.clear();LocalStorage
특징
- 역시나
key, value형태로 저장. - HTML5부터 추가됨.
- 브라우저를 닫아도 사라지지 않음(만료기간 지정 가능).
- 최대 5KB 저장 가능.
사용법
// 추가
localStorage.setItem("MY_LOCAL", "hello");
// 사용
localStorage.getItem("MY_LOCAL");
// 삭제
localStorage.removeItem("MY_LOCAL");
// 몽땅 삭제
localStorage.clear();기타
- npx는 컴퓨터의 사용자 계정이 한글이나 공백이 들어간 경우, 오류가 발생할 수 있다. 이 경우 CRA할 때 npm이나 yarn으로 설치해주면 된다.
