CORS(Cross-Origin Resource Sharing, 교차 출처 리소스 공유)

서로 다른 출처(origin) 간의 리소스를 공유할 수 있게 해주는 것

출처(origin)란?

origin은 protocol + host + port를 의미함
(참고로 포트는 https는 443, http는 80번이며, 생략가능함)

SOP(same origin policy, 동일 출처 정책)이란?

SOP은 브라우저에서 보안을 위해 동일한 출처끼리만 리소스를 공유할 수 있게하는 정책을 뜻함

예전에는 프론트와 백엔드를 따로 구성하지 않고 한 번에 구성해서 모든 처리가 같은 도메인에서 가능했음
하지만 시간이 흐르고 웹이 커지면서 클라이언트에서 api를 직접 호출하게 됨 -> 그런데 클라이언트와 api가 다른 도메인인 경우가 많음 -> CORS 생김(즉, 서버에 리소스 호출이 허용된 출처를 명시해주면 출처가 다르더라도 리소스를 공유할 수 있도록 해주자!)

CORS 해결 방법

1. 서버단에서 Access-Control-Allow-Origin 응답 헤더 셋팅하기
   Access-Control-Allow-Origin 헤더를 서버에서 설정해서 요청을 수락할 출처를 명시적으로 지정할 수 있음
   *(와일드카드)를 사용하면 출처에 상관없이 리소스에 접근할 수 있기 때문에 보안에 취약해짐
   따라서 명시적으로 직접 허용할 출처를 셋팅하는 게 좋음

'Access-Control-Allow-Origin': https://example.com

2. Proxy 설정(in React)
   프록시 서버를 사용해 웹 어플리케이션이 리소스와 동일한 출처에서 요청을 보내는 것처럼 보이므로 CORS 에러 방지 가능

리액트에서는 package.json에서 아래와 같이 설정하면 간단하게 프록시를 사용할 수 있음

"proxy": "https://openapi.naver.com"

하지만 이 방법은 개발할 때만 사용가능해서 배포하면 적용이 안 됨

3. API Routes(Next.js에서 내가 해결했던 방법)
   여기 참조

useEffect

API로 데이터를 요청하는 경우, 일반적인 HTTP통신 작업은 비동기로 처리된다.
컴포넌트 본문안에 HTTP통신 작업이 존재하면 리렌덜이 될때마다 작업을 다시 요청하게 되며
API로 요청한 데이터 크기가 클 경우브라우저의 페인팅 작업이 늦춰져 리소스를 비효율적으로 운영하게 된다. 이런 것을 부수효과(Site Effect)라고 한다.
side Effect들은 주로 화면을 렌더링 하는데 직접적인 영향을 주지 않기 때문에 주요 렌더링 작업과 부수효과를 구분하여 처리하는 것은 버그를 예방하는데에 도움을 주고 좋은 사용자 경험을 준다.
이러한 side Effect처리하기 위한 hook이 useEffect 이다.

클래스형 컴포넌트의 생명주기 메서드인 componentDidMout componentDidUpdate componentWillUnmount기능을 함수형 컴포넌트 에서 useEffect로 3가지의 메소드를 하나의 API로 통합해서 제공한다. 그러므로 코드해석 및 유지보수가 편리하다는 장점이 있다.

useEffect 구현

기본적으로 두가지 인자를 받는다

1. callback함수
2. 의존성배열( 선택적으로 작성)

useEffect()=>{
	//callback 함수
}) //의존성 배열

• 의존성 배열이 없는 경우
  • componentDidMount componentDidUpdate를 합친것 처럼 동작
  • 렌더링 될때 마다 실행된다.

useEffect()=>{
	//callback 함수
},[]) //의존성 배열

• 빈배열
  • componentDidMount처럼 동작
  • 화면에 첫 렌더링 될때만 실행된다.

useEffect()=>{
	//callback 함수
},[state,props]) //의존성 배열

• 배열상태나 속성 지정
  • componentDidMount componentDidUpdate 를 합친것 처럼 동작
  • 화면 첫 렌더링 했을 경우 와 상태가 변경 될때 실행된다.

의존성 배열
첫 번째 인자인 콜백함수는 배열에 있는 값들에 의존 하고 있어서 의존성 배열 이라고 한다.

useEffect()=>{
	//callback 함수
	return ()=>{
		//cleanUP
	}
},[state,props]) //의존성 배열

• 정리 함수 (clean-up function)
  • componentWillUnmount 처럼 동작한다.
  • 컴포넌트가 언마운트 될때 반환 함수를 실행하게 된다. (구독해지)
  • 예) 타이머 종료

useRef

1. useRef의 사용 목적

1. 특정 DOM에 접근하여 제어해야 할 경우
2. 렌더링과 관계없이 값을 변경하고 싶을 경우

js의 경우 getElementById, querySelector등 메서드를 통해 쉽게 DOM에 접근하여 제어할수 있으나 React의 경우 직접 DOM을 조작하는 것을 권장 하지 않는다.그러나 스크롤바의 위치를 파악하거나, input 요소에 자동 포커스를 설정해 주어야 할 경우 처럼 직접 DOM을 제어해 주어야 하는 예외적인 상황이 생겼을때 useRef를 통해 접근할 수 있다.

React는 virtual DOM을 사용하기 때문에 DOM 조작으로 인한 브라우저 렌더링을 최소화 한다는 장점을 가지고 있다. 이러한 장점 때문에 직접 DOM을 제어하는 것을 지양 하는것이 좋다.

useRef를 사용하여 반환된 객체는 컴포넌트이 전 생애 주기를 통해 유지 된다. .current의 값이 변경 되어도 컴포넌트 리렌더링을 발생시키지 않고, 렌더링을 할 때 동일한 ref 객체를 제공하게 된다.
따라서 컴포넌트가 언마운트 되기 전까지 값을 그대로 유지하게 되며 컴포넌트 값의 변경은 관리해야 하지만 리렌더링을 발생시킬 필요는 없을때 사용한다.

2. useRef 와 useState 차이

useRef와 useState는 상태 관리를 위해 사용할 수 있다.
useState는 state가 변경된 후에 리렌더링이 진행되고, useRef는 리렌더링을 하지 않는다.
useRef는 내부적으로 값이 변하여 컴포넌트가 렌더링 되기 전까지 변경된 값이 보이지 않다가 렌더링이 되는 시점에 변경된 값이 보이게 된다. 이러한 특성에 맞추어 렌더링이 필요한 state의 경우에는 useState를 사용하는 용도와 생애 주기 내내 변화하는 값을 가리키고있다는 차별점을 가지고 있다.

3. useRef 와 DOM

function App(){
   const textInput = useRef(null)

   const handleClickBtn =()=>{
       textInput.current.focus();
     }
	return (
	<div>
		<input type="text" ref={textInput}/>
		<input type="button" value="ref" onClick={handleClickBtn}/>
	</div>
      )
}
export default App;

3. useRef로 DOM 선택 후 사용시 주의 사항

useRef은 React Dom을 렌더링 하고 기존의 DOM에 반영되고 난후에 사용하거나, 조건부렌더링을 통해 ref.current가 존재할 때에만 사용이 가능하도록 해야 한다.

import React, { useEffect, useRef } from "react";
import music from "./assets/music.mp3";

function Player() {
  const audioRef = useRef(null);

  useEffect(() => {
    audioRef.current && audioRef.current.play(); //

});

  const handlePlay = () => { 
    audioRef.current.play(); console.log(" ");
  };

  const handlePause = () => {
    audioRef.current.pause();
    console.log("⏸ !"); 
  };

return ( <>

    <audio src={music} ref={audioRef} controls></audio>
    <br />
    <div style={{ margin: "10px 89px" }}>
	    <button onClick={handlePlay}></button>
		<button onClick={handlePause}> ⏸ </button>
	</div>

</> );

}
export default Player;

얕은복사는 객체의 참조값(주소값)을 복사하고, 깊은 복사는 객체의 실제 값을 복사한다.

원시값

• Number, String, Boolean, Null, Undefined
• 변수의 메모리 공간에 실제 데이터 값이 저장
• 할당된 변수를 조작하려고 하면 저장된 실제 값이 조작된다.

참조값

• Object, Symbol
• 변수에 객체를 저장하면 독립적인 메모리 공간에 값을 저장하고 변수에 저장된 메모리 공간의 참조(위치 값)를 저장하게 된다.
• 할당된 변수를 조작하는 것은 객체 자체를 조작하는 것이 아닌, 해당 객체의 참조를 조작하는것

깊은복사

원시값

실제 값을 복사하는 것을 깊은 복사라고 한다.
원시값을 복사할 때 그 값은 또 다른 독립적인 메모리 공간에 할당하기 때문에 복사를 하고 값을 수정해도 기존 원시값을 저장한 변수에 영향을 끼치지 않는다.

const a = 'a'
let b = 'b'

b = 'c'

console.log(a) //a
console.log(b) //c

얕은 복사

객체의 참조값(주소값)을 복사하는 것을 얕은 복사라고한다.
복사할 때는 변수가 객체의 참조를 가리키고 있기 때문에 복사된 변수 또한 객체가 저장된 메모리 공간의 참조를 가리키고 있다. 그래서 복사를 하고 객체를 수정하면 두 변수는 똑같은 참조를 가리키고 있기 때문에 기존 객체를 저장한 변수에 영향을 끼친다.

const a = {
	one:1,
	two:2,
}
let b = a;

b.one = 3;

console.log(a) // {one:3, two:2}
console.log(b) // {one:3, two:2}

얕은 복사 방법

얕은 복사란 객체를 복사할 때 기존 값과 복사된 값이 같은 참조를 가리키고 있는 것을 말한다.
객체 안에 객체가 있을 경우 한 개의 객체라도 기존 변수의 객체를 참조 하고 있다면 이를 얕은 복사라고 한다.

1. Array.prototype.slice()

start ~ end 인덱스 까지 기존 배열에서 추출하여 새로운 배열을 리턴하는 메소드

const original = ['a',2,true,4,'hi']
const copy = original.slice()

console.log(JSON.stringfy(original) === JSON.stringify(copy)) // true

copy.push(10)
console.log(JSON.stringify(original) === JSON.stringfy(copy)) //false

console.log(original); // [ 'a', 2, true, 4, 'hi' ]

console.log(copy); // [ 'a', 2, true, 4, 'hi', 10 ]

2. Object.assign()

메소드의 첫 번째 인자로 빈 객체를 넣어주고 두번째 인자로 복사할 객체를 넣어주면된다.

const object = {
	a:'a',
	number:{
		one:1,
		two:2
	}
}

const copy = Object.assign({},object)
copy.number.one = 3

console.log(object === copy) //false
console.log(object.number.one === copy.number.one) //true

깊은 클로닝에 대한 주의사항
깊은 클로닝에 대해서, Object.assign()을 속성의 값을 복사하기 때문에 다른 대안을 사용해야한다.
출처 값이 객체에 대한 참조인 경우, 참조 값만을 복한다.

deapth가 1일때 까지만 적용

3. spread연산자

const object = {
	a:'a',
	number:{
		one:1,
		two:2
	}
}
const copy = {...object}
copy.number.one = 3

console.log(object === copy) //false
console.log(object.number.one === copy.number.one) //true

deapth가 1일때 까지만 적용

깊은 복사 방법

깊은 복사된 객체는 객체 안에 객체가 있을 경우에도 원본과 참조가 완전히 끊어진 객체를 말한다.

JSON.parse && JSON.stringify

JSON.stringify()는 객체를 json문자열로 변환 -> 원본객체와 참조가 모두 끊어진다.
JSON.parse()를 이용해 다시 원래 객체(자바스크립트 객체로 만들어준다.)
쉽지만 다른방법에 비해 느림.
function일 경우 undefined로 처리가 단점이다.

const object = {
  a: "a",
  number: {
    one: 1,
    two: 2,
  },
  arr: [1, 2, [3, 4]],

};
const copy = JSON.parse(JSON.stringify(object))
copy.number.one = 3;
copy.arr[2].push(5)
console.log(object === copy); //false
console.log(object.number.one === copy.number.one); // false
console.log(object.arr === copy.arr); // false 
console.log(object); // { a: 'a', number: { one: 1, two: 2 }, arr: [ 1, 2, [ 3, 4 ] ] }
console.log(copy); // { a: 'a', number: { one: 3, two: 2 }, arr: [ 1, 2, [ 3, 4, 5 ] ] }

Lodash 라이브러리

쉽고 안전하게 깊은 복사를 할수 있다.

const deepCopy = require("lodash.clonedeep")

const object = {
  a: "a",
  number: {
    one: 1,
    two: 2,
  },
  arr: [1, 2, [3, 4]],

};

const copy = deepCopy(object)
copy.number.one = 3
copy.arr[2].push(5)
console.log(object === copy); // false

console.log(object.number.one === copy.number.one); // false
console.log(object.arr === copy.arr); // false
console.log(object); // { a: 'a', number: { one: 1, two: 2 }, arr: [ 1, 2, [ 3, 4 ] ] }
console.log(copy); // { a: 'a', number: { one: 3, two: 2 }, arr: [ 1, 2, [ 3, 4, 5 ] ] }

재귀함수를 구현한 복사

const object = {

  a: "a",
  number: {
    one: 1,
    two: 2,
  },

  arr: [1, 2, [3, 4]],

};


function deepCopy(object) {

  if (object === null || typeof object !== "object") {
    return object;
  }

  // 객체인지 배열인지 판단
  const copy = Array.isArray(object) ? [] : {};
  for (let key of Object.keys(object)) {
    copy[key] = deepCopy(object[key]);
  }
  return copy;
}

const copy = deepCopy(object);
copy.number.one = 3;
copy.arr[2].push(5);

console.log(object === copy); // false
console.log(object.number.one === copy.number.one); // false
console.log(object.arr === copy.arr); // false
console.log(object); // { a: 'a', number: { one: 1, two: 2 }, arr: [ 1, 2, [ 3, 4 ] ] }
console.log(copy); // { a: 'a', number: { one: 3, two: 2 }, arr: [ 1, 2, [ 3, 4, 5 ] ] }

var, let, const 의 차이

var

• var는 중복 선언이 가능하다. 그래서 기존에 선언한 변수를 잊고 값을 재 할당 하는 실수를 할수 있다.
• var은 재할당이 가능하다.
• var는 최상위에 끌어올려진 것 처럼 동작한다 (호이스팅)
• var는 함수 스코프 안에서만 지역 변수 이고 이외의 곳에서는 전역 변수이다.

let

• let은 중복 선언이 되지 않는다.
• let은 재할당이 가능하다.
• let은 호이스팅이 되지만 TDZ(Templar Dead Zone)때문에 참조에러가난다. - 선언 전에는 사용할수 없으며 코드를 예측가능하게하고 잠재적인버그를 줄일 수 있다.
• let은 블록스코프 이며 블록스코프 이외에서는 전역 변수 이다.

const

• const는 선언+초기화+할당 단계가 한번에 이루어진다.
• const 는 재할당이 되지 않는다.
• const도 호이스팅은 되지만 TDZ에 적용되어 선언전에는 접근 할수 없다.
• const 는 블록 스코프이다.

호이스팅

호이스팅이란 변수 선언과 함수 선언을 코드의 맨 위로 끌어올려지는 현상을 말한다.
javascript엔진이 코드를 실행하기 전에 선언들을 메모리에 저장하는 방식 때문에 발생한다.
변수 생성과 초기화의 작업이 분리되어 진행 되기 때문에 발생된다.

변수의 호이스팅

var로 선언된 변수는 초기화 되지 않은 상태 Undefined로 호이스팅된다.
let,const 는 TDZ에 들어가 변수가 선언되기 전까지 접근 할수 없어 이기간동안 변수에 접근하려고 하면 참조에러가 난다

함수의 호이스팅

함수는 함수 선언식은 선언전에도 호출할수 있다. 함수선언이 스코프의 최상단으로 완전히 호이스팅되기 때문이다.
함수 표현식은 변수에 할당 하므로 변수 선언후 에 함수를 아직 할당 받지 못한상태로 호출 하여 error가 발생한다.

협업에서 기억에 가장 남는 상황, 협업에서 어려웠던 경험(어려웠던 이유, 어떻게 해결했는지)

“팀에서 1인분을 한다”고 할 때, 1인분은 어떤걸 의미하는걸까요?

OAuth, JWT

OAuth(Open Authorization)란?

• 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는 접근 위임을 위한 개방형 표준
• 사용자들이 타사 애플리케이션이나 웹사이트의 계정에 관한 정보를 공유할 수 있게 허용
• OAuth가 나오기 전까지 기본 인증이 아닐 경우는 각 애플리케이션들이 각자의 개발한 회사의 방법대로 사용자를 확인하였으나 OAuth가 나오면서 이렇게 제각각인 인증방식을 표준화�함
  OAuth를 이용하면 이 인증을 공유하는 애플리케이션끼리는 별도의 인증이 필요 없음. 따라서 여러 애플리케이션을 통합하여 사용하는 것이 가능하게 됨

OAuth의 구성 요소

• Resource Owner(자원 소유자): 유저를 말함
• Client(클라이언트): 유저의 정보를 필요로 하는 애플리케이션
  (ex: 유저가 로그인하려는 웹 사이트가 클라이언트)
• Resource Server(자원 서버): 유저의 계정 정보를 가지고 있는 서버
  (ex: '구글 로그인하기' 기능을 사용하는 경우 구글이 자원 서버가 됨)
• Authorization Server(인증 서버): 유저의 계정 정보에 접근할 권한을 부여하는 서버
  대부분의 경우 자원 서버와 인증 서버는 같은 서버가 맡게 됨
  따라서, '구글 로그인하기' 기능을 사용하는 경우 구글 역시 인증 서버가 됨
• Redirect URI(리다이렉트 URI): 인증 서버가 인증 결과를 보내는 클라이언트의 주소
  클라이언트가 OAuth 공급자(ex: '구글 로그인하기' 기능을 이용하는 경우에는 구글이 OAuth 공급자가 됨. 유저는 구글을 통해 인증 받고, 구글은 액세스 토큰을 발행하여 클라이언트(웹사이트)에게 제공)에게 이 주소를 제공하면, 사용자가 로그인을 성공하거나 실패한 후 이 주소로 리다이렉트됨
• Access Token(액세스 토큰): 인증 후 클라이언트가 자원 서버에 접근하기 위해 사용하는 토큰을 말함
  이 토큰을 이용해 클라이언트는 자원 서버로부터 사용자의 정보를 안전하게 요청할 수 있음

OAuth의 동작 방식

백엔드에서는 뒤쪽에서 어떻게 처리하고 있을까? - 1 <- 간단하게 이해하기 좋음

백엔드에서는 뒤쪽에서 어떻게 처리하고 있을까? - 2 <- 좀 더 구체적인 예시와 설명

백엔드에서는 뒤쪽에서 어떻게 처리하고 있을까? - 3 <- 그 분의 블로그

JWT

#23 중 JWT를 참고

OAuth와 JWT와 차이점

차이점이라기 보다는 OAuth의 인증과정에서 JWT는 엑세스 토큰으로 사용될 수 있음
즉, JWT는 토큰의 한 종류이고 OAuth는 토큰을 발급하고 인증하는 오픈 스탠다드 프로토콜임

Key Props

Key Props란?

Key Props는 리액트가 어떤 항목을 변경, 추가 또는 삭제할지 식별하는 것을 돕기 위해 사용하고,
요소에 안정적인 고유성을 부여하기 위해 배열 내부의 요소에 지정해야함
때문에 key는 중복되지 않는 유니크한 값이어야하고, 보통 데이터의 id를 key로 많이 사용함

const todoItems = todos.map((todo) =>
  <li key={todo.id}>
    {todo.text}
  </li>
);

Key Props가 필요한 이유

리액트는 화면이 바뀌기 전 가상 DOM과 화면이 바뀐 후의 구조가 담겨있는 가상DOM을 가지고 있음
이 둘을 비교해 바뀐 부분이 있으면 실제 DOM에 바뀐 부분만을 적용해 바꾸어 줌
하지만 key가 없다면 바뀐 부분을 식별해줄 식별자가 없으므로 모든 요소가 다르다고 생각해 필요없는 리렌더링이 발생함

예를 들면 todo라는 배열에 새로운 todo라는 아이템이 추가된다고 가정해봄
key가 없다면 리액트는 아래와 같이 작동함

1. 바뀌기 전 가상 DOM과 바뀐 후 보여주어야 할 가상 DOM의 모든 요소를 하나하나 비교함
2. key가 없기 때문에 이전 요소와 동일한지 아닌지 식별할 수 없어 리액트는 이전 요소들과 다르다고 판단함
3. 실제 DOM에서 모든 요소를 리렌더링함

=> 필요없는 리렌더링이 발생함!

만약 key가 있다면 아래와 같이 작동할 것임

1. 바뀌기 전 가상 DOM과 바뀐 후 보여주어야할 가상 DOM에서 바뀐 요소의 key를 발견함
2. 해당 key가 있는 요소만 렌더링함(전체 렌더링x)

key를 사용해 변경된 부분만 업데이트할 수 있어 전체 렌더링을 방지하고 성능을 개선할 수 있음 !

Props와 State

props (short for “properties”) and state are both plain JavaScript objects. While both hold information that influences the output of render, they are different in one important way: props get passed to the component (similar to function parameters) whereas state is managed within the component (similar to variables declared within a function).

리액트 공식홈페이지에서는 props와 state 둘 다 렌더링 결과에 영향을 끼치는 일반 자바스크립트 객체라고 정의함.
즉, 둘 다 컴포넌트의 렌더링에 영향을 미치는 데이터임.

props와 state의 차이점

• props : 부모에서 자식컴포넌트로 내려주는 데이터이며, 내려받은 컴포넌트에서 수정이 불가능함
• state : 컴포넌트 안에서 관리되는 (함수에서 선언된 변수처럼) 데이터임. useState 같은 훅을 통해 관리되고 사용자의 인터랙션에 따라 변화함

즉, state는 사용자와의 인터랙션을 통해 변화하는 데이터임.
예를 들면 좋아요를 누르면 갯수가 변화한다든지, 장바구니에 제품을 담을 때 제품이 추가되고, 삭제할 때는 제품이 삭제되는 등 사용자와의 인터랙션을 통해 상태가 변화하는 것을 볼 수 있음

JavaScript

Variables(var, let, const )

var

• 중복선언 O , 재할당 O

var a = 1;
var a = 10
a = 2

console.log(a) // 2

• 전역 변수로 선언한 경우 window 객체의 속성이 됨

var a = 'hi';
console.log(window.a) // 'hi';

• 호이스팅될 때 초기화됨

console.log(x) // undefined
var x = 1
console.log(x) // 1

• 함수 스코프를 가짐
  (함수 내부에서 어디든 var로 선언한 변수에 접근할 수 있음)

function example() {
  if (true) {
    var a = 1;
  }

  for (var i = 0; i < 5; i++) {
    console.log(i, "i") // 0 1 2 3 4
  }

  console.log(a); // 1
  console.log(i); // 5
}

example();

let

• 중복선언 X, 재할당 O

let b = 1
b = 2
console.log(b) // 2

-----------------------------
let p = 111
let p = 222 // error

• 선언문 이전 접근 불가(참조할 값이 없기 때문에 참조 에러 발생) -> 변수의 중복 선언을 막을 수 있음

console.log(x) // 참조 에러
let x = 1

• 블록 스코프를 가짐 (선언된 블록({}) 안에서만 접근이 가능함 )

function example() {
  if (true) {
    let a = 1;
  }

  for (let i = 0; i < 5; i++) {
    console.log(i, "i") // 0 1 2 3 4
  }

  console.log(a); // 참조 에러
  console.log(i); // 참조 에러
}

example();

const

• 중복선언X, 재할당 X
• let과 마찬가지로 선언문 이전 접근 불가
• 객체가 할당되는 경우 객체 안의 값을 바꿀 수 있음(새로운 값을 재할당하는 것이 아니므로)
• 블록 스코프를 가짐 (선언된 블록({}) 안에서만 접근이 가능함 )

Hoisting

호이스팅이란 간단하게 말하자면 선언부가 제일 최상단으로 끌어올려진 것 같은 현상을 말함

자바스크립트 엔진은 코드를 위에서 아래로 읽어나감. 그 과정에서 선언해둘 것이 있다면 먼저 선언해두는데, 선언하는 과정에서 실행한 실행 컨텍스트(아래 예시의 경우 전역 컨텍스트) 안에 새로운 식별자(아래 예시에서는 cat)를 environment record에 저장함. 아래 예시의 경우 cat은 var 키워드로 되어있기 때문에 초기화를 함

console.log(cat) // undefined

var cat = 'rey';

console.log(cat) // 'rey'

let이나 const로 선언한 경우 자바스크립트 엔진이 environment record에 저장을 하긴 하지만 값을 초기화하지 않음.
따라서 식별자 cat의 값을 참조할 수 없으므로 참조 에러가 발생함(자바스크립트 엔진이 cat의 값을 읽을 수 없기 때문)

즉, let이나 const로 선언했을 때 선언 이전에 식별자를 참조할 수 없는 구역인 TDZ(temporal Dead Zone)가 발생함

console.log(cat) // reference error

let cat = 'rey';

console.log(cat) // rey

정리

변수

var

• 중복선언 O , 재할당 O
• 전역 변수로 선언한 경우 window 객체의 속성이 됨
• 호이스팅될 때 초기화됨
• 함수 스코프를 가짐

let

• 중복선언 X, 재할당 O
• 선언문 이전 접근 불가(참조할 값이 없기 때문에 참조 에러 발생) -> 변수의 중복 선언을 막을 수 있음

const

• 중복선언X, 재할당 X
• let과 마찬가지로 선언문 이전 접근 불가
• 객체가 할당되는 경우 객체 안의 값을 바꿀 수 있음(새로운 값을 재할당하는 것이 아니므로)
• 블록 스코프를 가짐 (선언된 블록({}) 안에서만 접근이 가능함 )

호이스팅

1. 변수 호이스팅

• var 로 변수를 선언한 경우 선언과 초기화가 동시에 일어남
• let, const의 경우 초기화하지 않음 -> 따라서 값이 할당되기 전까지는 변수에 아무런 값이 담겨있지 않기 때문에 값을 읽을 수 없음 -> 선언 라인 이전에는 변수를 참조할 수 없음(TDZ 발생)

선언
메모리 공간을 확보하고 메모리 주소에 식별자와 연결

초기화
식별자에 암묵적으로 undefined 값 바인딩

2. 함수 호이스팅

• 함수 선언문의 경우 함수선언문 전체가 호이스팅됨
• 함수 표현식의 경우 선언부만 호이스팅됨

OAuth와 JWT는 웹 애플리케이션에서 일반적으로 사용되는두가지 보안 메커니즘이다. 둘 다 인증 기능을 제공하지만 접근 방식과 사용사례가 다르다.

OAuth

OAuth는 자격 증명을 노출하지 않고 타사 애플리케이션이 사용자의 리소스에 액세스할 수 있도록 하는 개방형 인증 표준이다. OAuth 흐름에는 리소스 소유자(사용자),클라이언트(애플리케이션)및 권한 부여 서버 이 세가지가 관련된다.
클라이언트는 Authorization Server를 통해 리소스 소유자에게 Authorization(권한부여)을 요청하고, 승인이 나면 클라이언트는 리소스에 접근하기 위한 Access Token을 받는다.
OAuth는 일반적으로 사용자가 Facebook또는 Google자격증명을 사용하여 애플리케이션에 로그인할 수 있는 소셜 미디어 로그인에 사용된다.

JWT

JWT(JSON Web Token)는 두 당사자 간에 전송될 클레임(Clam)을 표현하는 URL 안전의 컴팩트한 수단이다.
header, payload, signature의 세 부분으로 구성된다. 헤더는 토큰 유형과 서명 알고리즘을 지정하고, 페이로드에는 클레임이 포함되며, 서명은 토큰의 무결성을 확인하는데 사용된다.
JWT는 일반적으로 사용자가 애플리케이션에 로그인하고 JWT를 응답으로 받는 인증에 사용된다.
그런 다음 JWT를 사용하여 애플리케이션 내의 보호된 리소스에 액세스할 수 있다.

OAuth와 JWT의 차이점

OAuth와 JWT는 서로 다른 목적으로 사용되며 사용 사례도 다르다. OAuth는 권한 부여 (authorization)에 사용되고 JWT는 인증(authentication)에 사용된다.
OAuth는 타사 애플리케이션에 리소스에 대한 액세스 권한을 부여하는데 사용되는 반면, JWT는 애플리케이션 내의 보호된 리소스에 액세스 하는데 사용 된다.
OAuth에는 인증 서버가 필요하지만 JWT에는 그렇지 않다. OAuth 흐름에는 여러 단계와 당사자가 포함되는 반면, JWT흐름은 더 간단하고 두 당사자만 포함한다.

실행컨텍스트란?

실행할 코드에 제공할 환경 정보들을 모아 놓은 객체이다.
어떤 실행 컨텍스트가 활성화 되는 시점에 다음과 같은 일을 한다.

1. 선언된 변수를 위로 끌어 올린다. (호이스팅)
2. 외부 환경 정보를 구성
3. this값을 설정한다.

실행 컨텍스트 객체의 담기는 정보

1. Variable Environment
   • 현재 컨텍스트 내의 식별자 정보(recode)를 갖고 있다.
   • 외부 환경 정보를 갖고 있다.
   • 선언 시점 LexicalEnvironment 의 snapshot
2. LexicalEnvironment
   • variableEnvironment와 동일하지만 변경사항을 실시간으로 반영한다.
3. this Binding

VariableEnvironment, LexicalEnvironment 개요

1. VE vs LE
   • VE : 스냅샷을 유지
   • LE : 스냅샷을 유지 하지 않는다. 실시간으로 변경사항을 계속해서 반영한다.

LexicalEnvironment - EnvironmentRecord

실행 컨텍스트를 실행할 때, VE에 정보를 먼저 담은 다음, 그대로 복사해 LE를 만들고 이후에는 주로 LE를 활용한다.

• EnvironmentRecord : 현재 컨텍스트와 관련된 식별자와 식별자에 바인딩된 값이 기록되는 공간 (내부 전체를 순서대로 수집)

LexicalEnvironment의 environmentRecord의 경우 해당 컨텍스트 환경에 필요한 식별자와 식별자의 값이 기록 되며, 함수의 실행시 실행 컨텍스트가 생성되므로 (실행보다 environmentRecord수집이 먼저 되므로 )변수와 같은 식별자를 끌어올리는 것과 같다 라는 개념의 호이스팅이 생겼다.

호이스팅

1. 매개변수 및 변수는 선언부를 호이스팅 한다.

function a (x) {
	console.log(x);
	var x;
	console.log(x);
	var x = 2
	console.log(x)
}
a(1)

// 매개변수 적용
function a (){
	var x = 1;
	console.log(x)
	var x;
	console.log(x);
	var x = 2
	console.log(x)
}
a(1)

//호이스팅 적용
function a() {
	var x;
	var x;
	var x;

	x =1;
	console.log(x)
	console.log(x)
	x =2
	console.log(X)
}
a(1) 
//1,1,2

2. 함수 선언은 전체를 호이스팅한다.

function a(){
	console.log(b)
	var b ='bbb'
	console.log(b)
	function b(){}
	console.log(b)
}
a()

//호이스팅 적용
function a () {
	var b;
	function b(){} //var b = function b(){}

	console.log(b)
	b= "bbb"
	console.log(b)
	console.log(b)
}
a() // b함수, 'bbb','bbb'

LexicalEnvironment(2) - 스코프, 스코프체인, outerEnvironmentReference(=outer)

outerEnvironmentReference(outer)란 현재 호출된 함수가 선언될 당시의 LexicalEnvironment를 참조한다.
항상 outer는 오직 자신이 선언된 시점의 LexicalEnvironment를 참조하고 있으므로 가장 가까운 요소부터 차례로 접근 가능하다.

var a = 1;
var outer = function(){
	var inner = function(){
		console.log(a) //undefined
		var a = 3
	}
	inner()
	console.log(a) //1
}
outer()

| outerEnvironmentReference란 해당 함수가 선언된 위치의 LexicalEnvironment를 참조하며, 변수의 접근을 한다면 해당 LexicalEnvironment에서 발견된다면 사용, 찾지 못할 경우 다시 outerEnvironmentReference 참조하여 탐색하는 과정을 반복한다.
이러한 과정을 스코프 체인이라고 하며 outerEnvironmentReference는 스코프 체인을 가능케 하는 역할을 한다.

this Binding

this의 값이 할당이 여기서 결정된다. 전역 실행 컨텍스트에서 this는 전역객체이다.(window)
함수 실행 컨텍스트에서의 값은 this함수가 호출되는 방식에 따라 다른데 함수가 객체 참조에 의해서 호출되면 해당객체로 설정되고 그렇지 않을 경우 전역 객체(window)를 가르키거나 strict mode에서는 undefined를 가르킨다.

const person ={
	name: "choco",
	say: function(){
		console.log( `Hello, my name is${this.name}`);
	}
}

person.calcAge(); //Hello, my name is choco

const sayHello = person.say;
sayHello();//NaN ---(2) // 객체 참조 값이 없다.  (.도 없기때문에 전역객체를 잠조 하는 것으로 가정하는 this는 window 전역객체를 가르키게되고 전역 객체에 sayHello라는 프로퍼티가 없기 때문에 NaN이 나온다.

타입스크립트 사용 이유, Type과 Interface의 차이점

타입스크립트 사용 이유

1. 정적 타입 체크
   자바스크립트는 런타임 시 타입이 결정됨
   따라서 타입관련 오류가 발생시 발견하기 어렵다는 단점이 있음
   그래서 타입스크립트를 사용해 코드를 작성하는 시점에 타입 관련 오류를 발견하고 수정할 수 있음

2. 타입추론
   타입을 명시적으로 지정하지 않아도 타입스크립트가 코드를 보고 타입을 추론함. 이를 통해 불필요한 타입 지정을 줄일 수 있고, 가독성도 높일 수 있음

Type과 Interface의 차이점

인터페이스는 객체의 형태를 묘사하는 데 사용됨
즉, 다양한 프로퍼티, 메소드 등을 포함하는 객체에 사용함

타입은 다 가능함

Type과 Interface의 사용법에서의 차이점

1. 프로퍼티 추가
   인터페이스는 따로 선언해도 인터페이스의 변수명이 같으면 프로퍼티가 합쳐짐
   타입은 타입의 변수명이 같아도 인터페이스처럼 알아서 합쳐지지 않고 에러 발생함

// interface

interface Person {
	name: string;
}

interface Person {
	age: number;
}

const haha: Person = {
	name: 'jerry',
	age: 4
} // 에러 X

// Types

type Person = {
	name: string;
}

type Person = {
	age: number;
}

const haha: Person = {
	name: 'jerry',
	age: 4
} // 에러 O

2. 프로퍼티 확장
   인터페이스는 extends 키워드를 사용해 확장할 수 있고
   타입은 & 기호를 사용해 확장할 수 있음

둘 다 여러 개의 다른 인터페이스나 타입을 상속받아 확장시킬 수도 있음(다중 상속)

// Interface

interface Name = {
	name: string
}

interface Person extends Name{
	age: number;
} 

const person: Person = {
	name: 'gh',
	age: 42
}

// Type

type Name = {
	name: string
}

type Person = Name & {
	age: number;
} 

const person: Person = {
	name: 'gh',
	age: 42
}

TypeScript Generic Utility Types

이미 정의한 타입을 변환할 때 사용하는 문법임

• Partial : 특정 타입의 일부 프로퍼티만 나타내는 타입
• Readonly : 모든 프로퍼티를 읽기 전용으로 설정.
• Record<K,T> : <key, type>으로 Key(key):Type(value)형태임

interface Person {
  age: number
}

type Member = 'mimi' | 'yujin' | 'youngji'

const example : Record<Member, Person> = {
   'mimi': {age: 25},
   'yujin': {age: 30},
   'youngji': {age: 2}
}

• Pick : 특정 타입에서 몇 개의 속성을 선택한 타입

interface User {
  name: string;
  email: string;
  age: number;
}

type aaType = Pick<User, 'email', | 'phone'>

const user: aaType = {
  email: '[email protected],
  age: 111
}

• Omit<T,K> : T 중에서 k를 제외한 속성을 사용하고 싶을 때 사용함

interface User {
  	email: string;
  	password: string;
  	game: {
    	kill: number;
  		death: number;
      	assist: number;
    }
}

const userOne: Omit<User, 'game'> = {
	email: '[email protected]',
    password: '1234',
};

콜백함수

매개변수로 함수 객체를 전달해서 호출 함수 내에서 매개변수 함수를 실행하는 것

콜백함수란 파라미터로 함수 자체를 전달 하는것

function sayHello(name, callback){
	const words = `안녕하세요 내 이름은 ${name} 입니다.`
	callback(words) // 매개변수 콜백 함수 호출
}

sayHello('마루', function printing(name){
	console.log(name) // 안녕하세요 내 이름은 마루 입니다.
})

콜백함수 사용 원칙

1. 익명 함수

콜백함수는 호출 함수에 일회용으로 사용 하는 경우가 많아 코드간 결성을 위해 이름 없는 "익명함수"를 사용한다.

sayHello('마루', funcion (name){
	console.log(name)
})

• 개발자의 실수로 인한 함수 이름 충돌 방지

let add =10 

function sum(x,y,callback){
	callback(x+y)
}

sum(1,2,function add(result){
 console.log(result)
})

console.log(add) // 변수 -> 함수가 되어버린다.

2. 화살표 함수모양의 콜백

function sayHello(callback){
	var name = 'sunja'
	callback(name)
}

sayHello((name)=>{
	console.log('Hello,' + name)
})

3. 함수의 이름을 넘기기

콜백함수가 일회용이 아닌 여러호출 함수의 재활용으로 자주 이용될 경우 별도로 함수를 정의하고 함수의이름만 호출 함수의 인자에 전달하는 식으로 가능한다.

function greet(name){
	console.log('hello'+ name)
}
function sayHello(callback){
	var name ="choco"
	callback(name)
}
function sayHello2(callback){
	var name ="sunja"
	callback(name)
}

sayHello(greet) // hello choco
sayHello2(greet) // hello sunja

여러가지 함수 현태를 다양하게 전달 가능

function introduce(last, first, callback){
	var fullName = last + first
	callback(fullName)
}

function say_hello(name){
	console.log('안녕하세요'+name + '입니다.')
}
function say_bye(name){
	console.log('안녕히 계세요' + name + 입니다.)
}

introduce('홍','길동',say_hello)

introduce('홍','길동',say_bye)

콜백 함수 활용 사례

1. 이벤터 리스너로 사용

addEventListner는 특정 이벤트가 발생했을 때 콜백 함수를 실행하는 메서드
클릭과 같은 이벤트를 처리하기 위해 등록하는 이벤트 리스너로 콜백함수가 쓰인다.

let button = document.getElementById('button')

button.addEventListener('click',function(){
	console.log('Button Clicked')
})

2. 고차함수에 사용

고차함수 : 함수를 파라미터로 전달받거나 연산의 결과로 반환해 주는 메서드

let numbers = [1,2,3,4,5]
let doubled = []

numbers.forEach(function(num){
	doubled.push(num*2)
})
console.log(doubled) // [2,4,6,8,10]

3. Ajax 결과값을 받을 때 사용

서버와 데이터를 주고받을 때 사용 하는 fetch메서드의 서버요청의 결과값을 처리하기 위해 콜백함수가 사용된다.

fetch("https://jsonplaceholder.typicode.com/users")
  .then(function (response) {
    // fetch 메서드가 성공하면 콜백 함수로 response 인자를 받음
    return response.json(); // response 객체의 json 메서드를 호출하여 JSON 데이터를 반환
  })
  .then(function (data) {
    // json 메서드가 성공하면 콜백 함수로 data 인자를 받음
	console.log(data);
  })

4. 타이머 실행 함수

setTimeout 이나 setInterval 과 같은 타이머함수에서 일정한 시간마다 스크립트를 실행하는 용도

자바스크립트 콜백함수 주의점

this를 사용한 콜백함수

자신을 전달받은 함수에 의해 호출되는데, 이때 콜백 함수 내부에서의 this는 해당 콜백 함수의 제어권을 넘겨받은 함수가 정의한 바에따르며, 정의하지 않은 경우에는 전역 객체를 참조한다.

let userData = {
    signUp: '2021-4-06 12:00:00',
    name: 'Not Set',
    setName: function(firstName, lastName) {
        this.name = firstName + ' ' + lastName;
    }
}
function getUserName(firstName, lastName, callback) {
    callback(firstName, lastName);
}
// 해당 콜백함수는 userData.setName과 아무런 관계가 없는 함수 형태만 비슷한 독립적인 함수이다.
getUserName('홍', '길동', function(firstName, lastName) {
	this.name = firstName + ' ' + lastName;
});
console.log('1: ', userData.name); // Not Set
console.log('2: ', window.name); // 홍 길동

그리고 일반적으로 콜백 함수를 호출하는 함수들은 별도로 this를 설정하지 않으므로 기본적으로 전역 객체가 바인딩 되는 것이다.

this 해결 방안

1. call, bind,apply 메서드 사용
   참조할 객체를 추가로 함수의 매개변수로 전달하고, 콜백 함수 내에서 call(), apply() 메서드를 통해 콜백 함수가 참조할 객체를 지정
2. 화살표 함수 사용
   화살표 함수를 사용해서 this를 외부 함수의 this와 동일하게 유지하는 방법이 있다. 화살표 함수는 자신만의 this를 가지지 않고 상위 스코프의 this를 참조하기 때문에 전역 객체를 무시하고 무조건 자신을 들고 있는 상위 객체를 가리킨다.

콜백 지옥

콜백 지옥이란 함수의 매개변수로 넘겨지는 콜백 함수가 반복되어 코드의 들여쓰기 수준이 감당하기 힘들어질 정도로 깊어지는 현상

콜백 지옥을 해결 하는 방법 비동기

동기

자바스크립트는 싱글 스레드 언어이기 때문에 한 번에 하나의 작업만 수행할수 있다. 이전작업이 완료되어야 작업을 수행할수 있으며 함수와 코드들이 위에서 아래로 차례로 동작하는 방식
간단하고 직관적이지만 작업이 오래걸리거나 응답이늦어진다.

비동기?

현재 실행중인 작업을 멈추지 않고 다른 작업을 병렬적으로 수행하는 것을 말한다.
여러 작업(task)이 있을때 비동기적으로 수행하면 작업을 동시에 한번에 수행할수 있다.
비동기는 메인 스레드가 작업을 다른 곳에 인가하여 처리되게 하고, 그 작업이 완료되면 콜백 함수를 받아 실행하는 방식으로 쉽게 말해 작업을 백그라운드에 요청하여 처리되게 하여 멀티로 작업을 동시에 처리하는 것으로 보면된다.

자바스크립트 비동기 특징

비동기 처리 유용성

비동기 방식으로 작업을 하게 되면 기다리는 동안 다른 작업을 할수 있으므로 자원을 효율적으로 사용할수 있다.
대규모 트래픽에서도 안정적으로 동작할 수 있는 웹애플리케이션을 만들수 있다.

Ajax

서버로부터 응답을 기다리는 동안에도 사용자와 인터넥션을 유지 할 수 있으므로 사용자 경험을 향상 시킬수 있다.

// fetch 함수에 URL 전달
fetch("https://jsonplaceholder.typicode.com/todos/1")
  .then(function(response) {
    return response.json(); // 응답을 JSON 형식으로 변환
  })
  .then(function(data) {
    console.log(data); // JSON 데이터를 출력
  })
  .catch(function(error) {
    console.error(error); // 에러를 출력
  });

비동기 병렬 처리 원리

자바스크립트는 싱글 스레드 언어 이지만 작업(task)들을 동시에 처리 가능하게 하는 이유는

브라우저라는 소프트웨어가 멀티스레드 이기때문에 메인 자바스크립트 스레드를 차단하지 않고 다른스레드를 사용하여 web API작업을 처리하여 동시 처리가 가능하다.

하지만 멀티스레딩은 아니다.
web api 만 병렬로 처리되고 그안에 콜백함수는 콜스택에 들어가 싱글스레드로 처리되기 때문이다.

브라우저의 비동기 처리

HTML 마크업 언어에서 의 비동기 처리
<script>태그에 async 와 defer의 키워드를 붙히면된다

• async : 브라우저가 페이지를 파싱되는 동안에도 스크립트가실행됨
• defer : 브라우저가 페이지의 파싱을 모두 끝내면 스크립트가 실행됨
• 모두 명시 하지 않았을 경우: 브라우저가 페이지를 파싱하기 전에 스크립트를 가져와 바로 실행

비동기 처리 방법

비동기와 콜백함수

비동기 방식은 요청과 응답 순서를 보장하지 않는다.
따라서 응답의 처리 결과에 의존하는 경우에는 콜백함수를 이용하여 작업 순서를 간접적으로 끼워줄수 있다.

function getDB(callback){
// 데이터베이스로부터 3초 후에 데이터 값을 받아온 후, 콜백 함수 호출
	setTimeout(()=>{
		const value = 100
		callback(value)
	},3000)
}

function main(){
  
// 호출할 작업에 콜백 함수를 넘긴다
	getDB(function(value){
		let data = value * 2
		console.log('data :', 'data' )
	})
}
main()

하지만 과도한 콜백함수를 할경우 콜백지옥에 빠질수 있다.

프로미스 객체

콜백함수는 비동기를 순차적으로 처리하기위한 '편법' 같은 것이며 비동기 전용 함수가 아니다.
프로미스의 객체는 비동기 처리를 위한 전용객체이다.
비동기 작업의 성공 또는 실패의 결과값을 나타내는 객체이다.

function getDB(){
	 return new Promise((resolve)=>{
		 setTimeout(()=>{
			 const value = 100;
			 resolve(value)
		 },3000)
	 })
}

function main(){
		getDB().then((valve)=>{ //성공적응로 수행했을 때 실행코드
		let data =value * 2
		console.log('data',data)
	})
	.catch((error)=>{ // 실패 했을 때 실행될 코드
		console.error(error)
	})
	.finally(()=>{ //성공하든 실패하든 무조건 실행
	
	})
}

프로미스 3가지 상태

1. Pending : 처리가 완료되지 않은 상태
2. Fulfilled :성공적으로 처리가 완료된 상태 (then)
3. Rejected: 처리가 실패로 끝난상태 (catch)

프로미스 핸들러

프로미스의 상태에 따라 실행되는 콜백 함수

1. then() : 이행되었을 때
2. catch(): 거부되었을 때
3. finally(): 이행 거부 상관없이 실행

프로미스 체이닝

프로미스 핸들러를 연달아 연결하는것, 여러개의 비동기 작업을 순차적으로 수행 할 수 있다.

프로미스 정적 메서드

1. Promise.resolve()

// Promise.resolve() 를 사용하여 프로미스 객체를 반환하는 함수
function getPromiseNumber() {
  const num = getRandomNumber(); // 일반 값
  return Promise.resolve(num); // 프로미스 객체
}
// 핸들러를 이용하여 프로미스 객체의 값을 처리하는 함수
getPromiseNumber()
    .then((value) => {
      console.log(`랜덤 숫자: ${value}`);
    })
    .catch((error) => {
      console.error(error);
    });

2. Promise.reject()

// 주어진 사유로 거부되는 프로미스 생성
const p = Promise.reject(new Error('error'));
// 거부 사유를 출력
p.catch(error => console.error(error)); // Error: error

3. Promise.all()
   모든 프로미스 비동기 처리가 이행 될대 까지 기다려서, 모든 프로미스가 완료되면 그때 then핸들러가 실행된다.

// 1. 서버 요청 API 프로미스 객체 생성 (fetch)
const api_1 = fetch("https://jsonplaceholder.typicode.com/users");
const api_2 = fetch("https://jsonplaceholder.typicode.com/users");
const api_3 = fetch("https://jsonplaceholder.typicode.com/users");
// 2. 프로미스 객체들을 묶어 배열로 구성
const promises = [api_1, api_2, api_3];
// 3. Promise.all() 메서드 인자로 프로미스 배열을 넣어, 모든 프로미스가 이행될 때까지 기다리고, 결과값을 출력
Promise.all(promises)
    .then((results) => {
      // results는 이행된 프로미스들의 값들을 담은 배열.
      // results의 순서는 promises의 순서와 일치.
      console.log(results); // [users1, users2, users3]
    })
    .catch((error) => {
      // 어느 하나라도 프로미스가 거부되면 오류를 출력
      console.error(error);
    });

4. Promise.allSettled()
   주어진 모든 프로미스가 처리되면 모든 프로미스 각각의 상태와 값(거부사유)를 모아 배열에 반환
5. Promise.any()
   주어진 모든 프로미스 중 하나라도 완료되면 바로 반환
6. Promise.race()
   이행, 실패 여부 상관없이 무조건 처리가 끝난 프로미스 결과값을 반환

프로미스 또한 코드가 복잡해 지면 읽을수 없는 코드가 되며 이를 극복하기 위해 나온 async/await 가 있다.

async/await

마치 동기 코드처럼 작성할수 있게 해준다.

• async : 함수앞에 async 를 작성하면 되며, 어떤 값을 리턴하든 무조건 프로미스 객체로 감싸져 반환된다.
  프로미스 상태를 다르게 지정하여 반환이 가능하다.
  then을 붙이는것도 가능
  • await : then 복잡하게 사용할 필요없이 비동기 함수에 await만 명시해주고 결과값을 변수에 받도록 하면된다. promise가 처리될 때가지 코드 실행을 일시 중지하고 promise가 처리되면 결과값을 반환하여 변수에 할당

에러 처리

try cath로 처리하면 된다.

// async/await 방식
async function func() {

    try {
        const res = await fetch(url); // 요청을 기다림
        const data = await res.json(); // 응답을 JSON으로 파싱
        // data 처리
        console.log(data);
    } catch (err) {
        // 에러 처리
        console.error(err);
    }

}
func();

useRef, useEffect

useRef

useRef returns a mutable ref object whose .current property is initialized to the passed argument (initialValue). The returned object will persist for the full lifetime of the component.

공식 홈페이지의 설명에 따르면 .current 속성이 전달된 인수로(initialValue) 초기화되는 변경 가능한 ref 객체를 반환하고, 반환된 객체는 컴포넌트의 전체 수명동안 유지된다고 함
이를 풀어서 설명하면 아래와 같음

• useRef는 변경 가능한 객체를 반환함
• 반환 객체는 useRef 인자를 current라는 속성 안에 저장함

const ref = useRef('hihi')
console.log(ref.current) // 'hihi'

// { current: 'hihi' } 이런식으로 반환됨

• 반환 객체는 컴포넌트의 수명이 다하기 전까지 유지된다(언마운트 되기 전까지 유지가 된다는 소리)

또한 useRef로 직접 DOM을 조작할 수 있는데, useRef를 사용하면 Ref의 값이 변해도 리렌더링이 되지 않고, 리렌더링이 되어도 컴포넌트가 언마운트 되기 전까지(컴포넌트의 수명이 다 하기 전까지) Ref의 값이 유지됨

useRef가 사용되는 대표적인 예

• 저장 공간
  state 처럼 값을 저장하는 공간으로 사용할 수 있지만 차이점이 있음

State 변화 -> 렌더링 -> 컴포넌트 내부 변수들 초기화
Ref 변화 -> 렌더링 X -> 변수들의 값이 유지됨
State 변화 -> 렌더링 -> Ref의 값은 계속 유지됨(컴포넌트 언마운트전까지)

=> 그래서 변경시 렌더링을 발생시키지 말아야하는 값을 다룰 때 사용하면 좋음

• DOM 에 접근
  바닐라 자바스크립트의 document.querySelector() 같이 직접적으로 DOM 요소에 접근할 수 있음
  예를 들면 로그인 페이지에 들어왔을 때 자동으로 아이디를 적는 인풋을 클릭하지 않아도 자동으로 포커스가 가게 한다든지 등의 상황에서 사용됨

useEffect

useEffect는 componentDidMount, componentDidUpdate, componentWillUnmount룰 하나로 통합한 리액트 훅이고, 컴포넌트 렌더링과 관련된 side effect 를 처리하고(데이터 가져오기, 수동 DOM 조작 등), 의존성 배열을 통해서 필요한 상황에서만 실행되도록 관리할 수 있는 훅임

useEffect 훅을 사용하면 리액트 컴포넌트가 화면에 렌더링 된 후 비동기 작업을 처리함.

useEffect(() => {
  console.log('componentDidMount')

  return () => {
    // cleanUp
    console.log('componentWillUnmount')
  }
}, [array dependencies])
// deps에 포함된 state나 props가 변경될 때마다 다시 렌더링 됨(componentDidMount와 componentDidUpdate를 합친 것처럼 동작)
// deps에 빈배열을 넣은 경우 componentDidMount처럼 동작함. 즉, 마운트되고 첫 렌더링이 끝난 직후에만 첫번째 인자인 함수가 실행됨
// 리턴 부분에 쓰인 함수는 클린업 함수로 componentWillUnmount처럼 동작함

useEffect는 사이드 이펙트를 처리하면서 컴포넌트 성능이나 렌더링에는 영향을 끼치지 않도록 도와주는 역할을 하며, 이는 비동기 작업과 컴포넌트 렌더링을 분리하고 최적화를 가능하게 함

사이드 이펙트(부수효과, side effect)란?

리액트 컴포넌트는 함수로 정의되며, 대부분의 리액트 함수는 순수함수처럼 동작함.
즉, 입력(props)을 받으면 예측 가능한 jsx를 return하는 것을 의미함

순수함수는 주어진 입력에 대해 항상 동일한 결과를 리턴하고 외부 상태나 변수에 영향을 주지 않음. 하지만 사이드 이펙트를 가진 함수는 무엇인가를 하기 위해 리액트 컴포넌트 외부와 함께 수행되기 때문에 순수함수와는 달리 외부 상태를 변경하거나, 외부와 상호작용해 수행한 결과가 어떤지 예측할 수 없음

사이드 이펙트는 다음과 같은 것들이 있음

• 백엔드 서버로 api 데이터 요펑
• 브라우저 api와 상호작용(document, window 직접 사용 등 DOM 조작에 관련됨)
• setTimeout, setInterval 등 타이머 관련 함수

정리

useRef

• useRef로 직접 DOM을 조작할 수 있음
• useRef는 값이 변해도 리렌더링X, 컴포넌트가 리렌더링이 되어도 컴포넌트가 언마운트 되기 전까지(컴포넌트의 수명이 다 하기 전까지) Ref의 값이 유지됨

useEffect

• componentDidMount, componentDidUpdate, componentWillUnmount룰 하나로 통합한 훅
• 컴포넌트 렌더링과 관련된 side effect 를 처리하고 의존성 배열을 통해서 필요한 상황에서만 실행되도록 관리할 수 있음
• 비동기 작업과 컴포넌트 렌더링을 분리하고 최적화를 가능하게 함

HTTP 프로토콜이란?

HTTP는 인터넷 상에서 데이터를 주고 받기 위한 서버/클라이언트 모델을 따르는 프로토콜이다.

HTTP 특징

• 비연결지향 : request에 대한 response를 해주면 서버와 클라이언트가 연결이 끊어진다. 커넥션을 낭비하지 않기 때문에 리소스의 낭비를 줄일 수 있다.
• 무상태(stateless) : 연결을 끊는 순간 상태 정보를 유지 하지 않는다.

클라이언트의 로그인 정보나 브라우저에 입력한 값 등이 페이지를 이동 할대 마다 초기화 된다.
이러한 문제점을 해결하기 위해 데이터 저장에 사용되는 것이 쿠키,세션, 웹스토리지 이다.

1.쿠키 (Cookie)

• 클라이언트 로컬에 저장되는 키와 값 형태의 작은 파일로, 이름, 값, 만료시간, 경로정보가 들어있다.
• 클라이언트의 상태 정보를 로컬에 저장했 다가 참조한다.
• 클라이언트에 300개까지 저장가능, 하나의 도메인당 20개의 값만 가질수 있으면 하나의 쿠키 값은 4KB까지 저장가능
• 쿠키는 특정 시간 초과 후에 데이터를 무효화 하는 것을 권장하기에 만료기간이 존재한다
• 클라언트가 서버에 접속한 방문 정보를 클라이언트에 저장하기에 매번 서버 전송이 되기에 자원 소모가 발생한다.
• 오랜시간 동안 유지될 수 있고, 자바스크립트를 이용하여 쿠키에 접근할 수 있기에 쿠키에 민감한 정보를 담기에 CSRF 공격에 취약하다

CSRF (Cross Site Request Forgery) 웹 어플리케이션 취약점 중 하나로 인터넷 사용자가 자신의 의지와 무관하게 공격자가 의도한 행위(수정,삭제,등록)를 특정 웹사이트에 요청하게 만드는 공격 이다.

쿠키 사용처

• 로그인 화면에서 아이디 자동완성
• 팝업 화면에서 오늘 하루 보지 않기
• 미 로그인 상태에서 장바구니 담기

2.세션

• 사용자 정보를 파일 브라우저에 저장하는 쿠키와 달리 세션은 ==서버측에서 관리==한다.
• 서버에서 클라이언트를 구분하기 위해 세션 ID를 부여하여, 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지한다.
• 접속 시간에 재한을 두어 일정 시간 응답이 없다면 정보가 유지되지 않게 설정 가능
• 데이터를 서버에 두기 때문에 쿠키보단 보안이 좋지만, 사용자가 많아질 수록 서버 메모리를 많이 차지하게 된다.

쿠키와 세션의 차이점

3. 웹스토리지

• 클라이언트(브라우저)에 데이터를 저장할 수 있도록 HTML5부터 추가된 저장소
• 간단한 Key-Value 스토리지 형태
• 쿠키와 달리 자동 전송 위험성이 없다.
• 오리진(Origin)(도메인,프로토콜, 포트)단위로 접근이 제한되는 특성 덕분에 CSRF로부터 안전
• 쿠키보다 큰 저장 용량 지원(모바일 2.5MB, 데스트탑 5~10MB)
• 서버가 HTTP헤더를 통해 스토리지 객체를 조작할 수 없음(자바스크림트 내에서만 수행가능)
• 오직 문자형(String)데이터 타입만 지원
• 로컬스토리지, 세션스토리지가 있으면 같은 스토리지 객체를 상속하기 때문에 메서드가 동일

로컬 스토리지 (localStorage)

• 사용자가 데이터를 지우지 않는 이상, 브라우저나 OS를 종료해도 계속 브라우저에 남아있다(영구성)
• 동일한 도메인 내에서만 유효하며, 다른 도메인에서는 유효하지 않는다.
• 지속적으로 필요한 데이터 저장(자동 로그인)

세션 스토리지(SessonStorage)

• 브라우저를 종료하거나 OS를 종료하면 사라지고 새로고침이나 브라우저 탭이 유지될 때에만 해당 저장소가 유지
• 동일한 도메인과 탭에서만 유효하고, 다른도메인 또는 브라우저 내에서는 유효하지 않는다.
• 이미로 유지되는 입력폼 정보, 일회성 로그인, 새로고침 시 데이터 유지 정보

인증과 인가

시스템의 자원을 적절하고 유효한 사용자에게 전달하고 공개하는 방법

인증(Authentication)

로그인, 클라이언트가 자기자신아라고 주장하고 있는 사용자가 맞는지를 검증하는 과정이다. 클라이언트가 패스워드를 입력해 제출하면 서버는 유저가 맞는지 확인한다.

인가(Authorization)

인증 작업 이후에 행해지는 작업,
인증된 사용자에 대한 자원에 대한 접근 확인 절차
유저1이 쓴글에 유저2 가 수정 삭제 하지 못하는데이는 인가가 되어 있지 않기 때문이다.

HTTP는 비상태성이라는 특성을 가지고 있어 서버는 클라이언트의 상태를 저장하지 않으며 인증과정을 거쳤는지 알 방법이 없다.

이러한 HTTP 환경에서 서버는 세션 또는 토큰을 사용하여 사용자를 인가한다.

세션기반 인증

사용자의 인증정보가 서버의 세션 저장소에 저장되는 방식

1. 로그인 -> 인증정보 서버의 세션 저장소 저장
2. Session ID 발급 -> 브라우저 쿠키 형태 저장 -> 실제 인증 정보는 서버에 저장
3. 요청마다 HTTP Cookie 헤더에 Session ID를 함께 서버로 전송
4. Session ID 해당 하는 세션 정보가 세션 저장소에 존재한다면 해당 사용자를 인증된 사용자로 판단 하여 인가를 수행 해 준다.

장점

• 서버에 저장하기 때문에 관리가 매우 편하고 효율적
• 구현이 명확하며 실제 서버에서 로그인 상태를 확인하기 유용

단점

• 서버에서 클라이언트의 상태를 모두 유지하고 있어야 하므로 클라이언트 수가 많으면 메모리나 DB에 부하가 심하다
• 멀티 디바이스 환경(모바일, 공동 사용)에서 로그인시 중복 로그인 처리가 되지 않는 등의 신경 써야 할 부분들이 발생한다.
• 사용자가 많아지는 경우 로드 밸런싱을 사용한 서버 확장을 이용해야 하는데 이때 세션의 관리가 어려워진다.

로드 벨런싱
서버가 처리해야 할 업무 혹은 요청을 여러 대의 서버로 나누어 처리하는것

이러한 단점들로인해 토큰 방식이 생겨남

토큰 기반 인증 방식

인증 정보를 클라리언트가 직접 들고 있는 방식.

1. 유저가 로그인 요청 -> id, pw 정보유효 -> 서버에서 Secret Key를 사용하여 유저에게 토큰 발급
2. 클라이언트 토큰 저장 -> 서버에 요청을 할 때마다 해당 토큰을 함께 서버에 전달
3. 서버는 토큰 검증 -> 요청 응답

토큰 구조

인코딩 암호화된 3가지 데이터를 이어 붙인것

1. header : 토큰을 어떻게 검증하는가에 대한 내용
2. playload: 토큰에 담긴 사용자 정보 등의 데이터가 저장 되어있다.

• 누가 누구에게 발급?
• 유효기간
• 사용자에게 이 토튼을 통해 공개하기 원하는 내용 (사용자의 닉네임, 서비스 상의 레벨, 관리자 여부)
  => 사용자가 받아서 갖고 있는 토큰 자체에 이러한 정보들이 있으므로 서버가 요청마다 데이터베이스에서 찾아야 할 것들이 줄어듬

3. signature: 부호화 시킨 header와 playload를 가지고 발급해준 서버가 지정한 scret key로 암호화 시켜 토큰 변조하기 어렵게 한다.

장점

• 클라이언트에 토큰이 저장되어 있기 때문에 서버의 메모리 부담이 되지 않으며 Scale에 있어 대비책을 고려할 필요가 없음
• 멀티 디바이스 환경에 대한 부담이 없다.

단점

• 암호화가 풀릴 가능성을 배제 할수 없다.
  • 암호화가 풀리더라도 토큰을 사용할수 없도록 만료기간을 짧게 설정한다.(5,6분~ 1시간)
• playload 자체는 암호화 되지 않고 base64로 코딩한 데이터이므로, 중간에 playload를 탈퇴하면 디코딩을 통해 데이터를 볼수 있다. 따라서 JWT을 통해 암호화 하거나, playLoad에 중요한 데이터를 넣지 않아야 한다.

JWT 란?

(JSON Web Token)란 인증에 필요한 정보들을 암호화시킨 JSON토큰

JWT 기반 인증
JWT 토큰(Access Token)을 HTTP헤더에 실어 서버가 클라이언트를 식별하는 방식

JWT를 이용한 인증 과정

1. 사용자가 ID, PW를 입력 -> 서버 로그인 인증
2. Header,payLoad,Signature를 각각 Base64로 한 번더 암호화하여 JWT 생성하고 이를 쿠키에 담아 클라이언트에 발급
3. 클라이언트는 서버로 받은 JWT를 로컬스토리 저장(쿠키,세션 저장) API를 서버에 요청할 때 Authorization header에 Access Token 담아 보낸다.
4. 서버는 클라이언트가 Header에 담아 보낸 JWT가 서버내에 발행한 토큰인지 일치여부 확인하여 인증통과 시켜주고 페이로드에 들어있는 유저의 정보들을 select해서 클라이언트에 돌려준다.
5. 클라이언트 -> 서버 요청 했는데 AccessToken 이 만료되면 클라이언트는 refresh token을 이용해서 서버로 부터 새로운 에세스 토큰을 발급 받는다.

쿠키에 JWT 저장 시 취약점

• Cross-Site Scripting (XSS) 공격: 쿠키에 저장된 JWT는 XSS 공격에 취약할 수 있습니다. 공격자가 악성 스크립트를 삽입하여 사용자의 브라우저에서 실행되면, 이 스크립트는 쿠키에 접근하여 JWT를 탈취할 수 있습니다.

• CSRF (Cross-Site Request Forgery) 공격: CSRF 공격은 사용자가 로그인한 상태에서 공격자가 준비한 트랩 사이트를 방문할 경우, 사용자의 브라우저가 자동으로 쿠키를 포함한 요청을 서버에 보내는 것을 이용합니다. JWT를 쿠키에 저장하면, 이러한 공격에 노출될 수 있습니다.

• 쿠키 설정의 중요성: 쿠키를 사용할 때 HttpOnly, Secure, SameSite 등의 속성을 올바르게 설정하지 않으면, 보안 취약점이 발생할 수 있습니다. HttpOnly는 XSS 공격으로부터 보호하며, Secure는 HTTPS를 통해서만 쿠키를 전송하도록 합니다. SameSite 속성은 쿠키가 동일한 사이트에서만 전송되도록 제한합니다.

해결책

• 로컬 스토리지 사용: 쿠키 대신 JWT를 로컬 스토리지에 저장하는 방법이 있습니다. 하지만 이 방법 역시 XSS 공격에 취약할 수 있습니다.
• 쿠키의 보안 속성 설정: 쿠키에 JWT를 저장할 때는 보안 속성을 적절히 설정하는 것이 중요합니다.
• 토큰의 만료 시간 단축: 토큰 탈취 위험을 줄이기 위해 토큰의 유효 시간을 짧게 설정합니다.
  이러한 점들을 고려하여 시스템을 설계하고 구현하는 것이 중요합니다. JWT와 쿠키를 사용할 때는 항상 보안 측면을 고려하여 적절한 방어 메커니즘을 구현해야 합니다.

Redux

단방향으로 흐르는 Flux 아키텍처 구조

장점

• 모든 상태 업데이트를 액션으로 정의하고, 액션 정보에 기반이여 리듀서에서 상태를 업데이트 하기 때문에 상태를 더욱 쉽게 예측 가능하게 하여 유지보수 측면에 긍정적인 효과가 있다.
• 데이터 흐름이 단방향으로 흐른다
• redux devtools를 이용하여 디버깅이 쉽다.
• 비동기 처리를 위하 미들웨어가 있다 (redux-thunk, redux-saga)

단점

• 사용방법이 복잡하다
• 보일러클레이트코드(변화없이 여러 군데 반복되는 코드)가 많다.
• 비동기 요청을 위해 redux-thunk, redux-saga등 서드파티 라이브러리가 필요하다.
• hook 기반이 아니다.

Recoil

Facebook에서 개발한 상태관리 라이브러리
컴포넌트 계층 ㅇ구조 기반으로 하는 전역 상태 관리 방식
컴포넌트 간 데이터 전달을 보다 쉽고 직관적으로 처리 할 수 있다.

Recoil 주요기능

• Atom
  • 업데이트와 구독 가능
  • 로걸 state 대신 사용할 수 있다.
  • 고유한 키 값고 디폴트 값을 설정해야한다.
  • 디폴트 값은 정적인 값, 함수, 비동기 함수가 될수 있다.
• Selector
  • 다른 atom에 의존하는 동적인 데이터를 만들 수 있게 해준다.
  • 순수 함수 이다.
  • 기본적으로 들어왔던 적이 있는 값을 기억하고 있기 때문에(= 캐싱), 같은 응답을 보내는 api call에 대해서는 추가적으로 요청하지 않아 성능적으로 유리하다.
  • Selector는 useRecoilValue()를 사용해 읽을 수 있다.

const fontSizeLabelState = selector({
  key: 'fontSizeLabelState',
  get: ({get}) => {
    const fontSize = get(fontSizeState);
    const unit = 'px';

    return `${fontSize}${unit}`;
  },
});

장점

• useState훅과 비슷하게 동작 하여 직관적이고 간단하다
• selector로 비동기 처리가 가능하다.
•  BoilerPlate-free API 리덕스는 상태를 변화시키고 업데이트 시키려면 그만큼 코드가 늘어나는데 recoil은 그렇게까지 많은 코드를 작성할 필요가 없다. 그리고 상태 정의는 증분 및 분산되어 code splitting이 가능하다.

단점

• 안정적인 Devtools가 없어 디버깅이 상대적으로 불편
• 어느 컴포넌트라도 전역상태에 직접 접근하여 상태를 업데이트 할 수 있기 때문에 언제 전역상태를 변경하는지 알기 어렵다. (전역상태가 늘어나면 유지보수가 어려움)

특징비교

면접 대비를 위한 CS tip : 상태관리에 대한 3가지 접근 방식

1. Flux
   저장소(store) / 액션함수(action) / 리듀서 등을 통해서 상태를 업데이트 하는 방식
   Redux, Zustand

2. Atomic
   React에 사용되는 state와 비슷하게 리액트 트리 안에서 상태를 저장하고 관리하는 방식
   Recoil, Jotai

HTTP

http(Hyper Text Transfer Protocol)란 서버/ 클라이언트 모델을 따라 데이터를 주고 받기 위한 프로토콜이다.

즉 HTTP는 인터넷에서 하이퍼텍스트를 교환하기 위한 통신 규약으로 80번 포트를 사용하고 있다. 따라서 HTTP 서버가 80번 포트에서 요청을 기다리고 있으며, 클라이언트는 80번 포트로 요청을 보내게 된다.

HTTP의 구조

HTTP는 애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동한다. HTTP는 상태를 가지고 있지 않은 Stateless포로토콜이며 Method,Path,Version,Header,Body등으로 구성된다.

• Method : Get, Post, Delete ...
• Path: HTTP
• Version: 1.1
• Header: Accept-Language:kr...

하지만 HTTP는 암호화가 되지 않은 평문 데이터를 전송하는 프로토콜이였기 때문에, HTTP로 비밀번호나 주민등록번호 등을 주고 받으면 제3자가 정보를 조회 할수 있다.

이러한 문제를 해결 하기 위해 HTTPS가 등장하게 되었다.

HTTPS

HyperTExt Transfer Protocol over Secure Sokey Layer, HTTP over TLS, HTTP over SSL , HTTP Scure등 으로 불리는 HTTPS는 HTTP에 데이터 암호화가 추가된 프로토콜이다. HTTPS는 HTTP와 다르게 443번 포트를 사용하며, 네트워크 상에서 중간에 제 3자가 정보를 볼 수 없도록 암호화를 지원하고 있다.

대칭키 암호화와 비대칭키 암호화

HTTPS는 대칭키 암호화 방식과 비대칭키 암호화 방식 모두를 사용하고 있다.

• 대칭키 암호화
  • 클라이언트와 서버가 동일한 키를 사용해 암호화/복호화를 진행함
  • 키가 노출되면 매우 위험하지만 연산 속도가 빠름
• 비대칭키 암호화
  • 1개의 쌍으로 구성된 공개키와 개인키를 암호화/복호화 하는데 사용함
  • 키가 노출되어도 비교적 안전하지만 연산 속도가 느림

HTTPS의 동작 과정

HTTPS 는 대칭키 암호화와 비대칭키 암호화를 모두 사용하여 빠른 여난 속도와 안정성을 모두 얻고 있다. HTTPS 연결 과정(Hand-Shaking)에서 먼저 서버와 클라이언트 간에 세션키를 교환한다. 여기서 세션기키를 주고 받는 데이터를 암호화하기 위해 사용되는 대칭키이며 데이터 간의 교환에는 빠른 연산 속도가 필요하므로 세션키는 대칭키로 만들어 진다.
세션키를 클라이언트와 서버가 비대칭키를 사용하여 교환한다. 처음 연결을 성립하여 안전하게 세션키를 공유하는 과정에서 비대칭 키가 사용되는 것이고, 이후에 데이터를 교화하는 과정에서 빠른 연산 속도를 위해 대칭키가 사용된다.

HTTPS 연결 과정이 성립되는 흐름

1. 클라이언트가 서버로 최초 연결을 시도함
2. 서버는 공개키(인증서)를 브라우저에 넘겨줌
3. 브라우저는 인정서의 유효성을 검사하고 세션키를 발급
4. 브라우저는 세션키를 보관하며 추가로 서버의 공개키로 세션키를 암호화하여 서버로 전송
5. 서버는 개인키로 암호화된 세션키를 복호화하여 세션키를 얻음
6. 클라이언트와 서버는 동일한 세션키를 공유하므로 데이터를 전달 할 쌔 세션키로 암호화/복호화를 진행함

HTTP와 HTTPS

HTTP는 암호화가 추가되지 않았기 때문에 보안에 취약한 반면, HTTPS는 안전하게 데이터를 주고받을 수 있다. HTTPS를 이용하면 암호화/복호화의 과정이 필요하기 때문에 HTTP봐 속도가 느리다.(거의 차이를 못느낌)
HTTPS는 인증서를 발급하고 유지하기 위한 추가 비용이 발생한다.

HTTP HTTPS 쓰임

• HTTP: 노출이 되어도 괜찮은 단순한 정보 조회 등 만을 처리 하고 있다.
• HTTPS:개인정보와 같은 민감한 데이터를 주고 받아햐 한다

참고예시
https://aws.amazon.com/ko/compare/the-difference-between-https-and-http/

얕은 복사, 깊은 복사

얕은 복사와 깊은 복사에 대해서 이해하기 전 알아야 할 것들
데이터 타입, 메모리 할당

데이터 타입에는 기본형 데이터와 참조형 데이터가 있음

기본형 데이터 타입(원시 데이터)

• string
• number
• boolean
• null
• undefined
• symbol

기본형 데이터들은 모두 불변값임.

// 예시1
var a = 'abc';
a += 'def';

---- 
// 예시2
var b = 5;
var c = 5
b = 7

참조형 데이터

• Object : new Object Array, Map, Set, Weak map, Date
• Function

var obj1 = {
    a : 1,
    b : 'ccc'
}

obj1.a = 100;

변수 복사 이후 값 변경(얕은 복사, 깊은 복사가 필요한 이유)

// 기본형 데이터 복사
var a = 10
var b = a

// 참조형 데이터 복사
var obj1 = { c: 10, d: 'qwer'};
va obj2 = obj1

// 값 변경
b = 15
obj2.c = 20

변수 b의 값을 15로 변경할 때, 데이터 영역에서 15가 있는지 찾아보고 있다면 그 주소를 변수 b에 저장함. 없다면 데이터 영역의 새로운 공간에 15를 저장하고 그 주소를 변수 b에 저장함
따라서 변수 a와 b는 다른 주소를 참조함 -> 불변성 유지

obj2.c = 20의 경우 데이터 영역에 20이 없다고 가정한다면 데이터 영역에 20을 새롭게 만들고 그 주소를 변수 영역에 있는 obj2(@1004)의 값(@5002)이 가리키는 변수 영역에서 다시 c를 찾아 그곳에 저장함

변수 obj1를 복사한 obj2는 프로퍼티의 값을 바꾸었지만 저장된 값(@5002)는 바뀌지 않음 -> obj1과 obj2는 같은 객체를 참조하고 있음 -> 그래서 obj1이나 obj2의 프로퍼티 중에 무엇을 바꾸든 두 객체에 모두 변경된 값이 적용됨(같은 주소를 참조하니까)
그래서 개발자가 obj2의 값만을 바꾸었는데 의도치 않게 obj1의 값도 바뀜

그러면 어떻게 해아하나?
원본 객체는 변하지 않고 복사한 객체가 다른 주소를 참고하면 됨 -> 불변 객체 필요함

얕은 복사와 깊은 복사의 차이점

• 얕은 복사 : 바로 아래 단계의 값만 복사하는 방법
• 깊은 복사 : 내부의 모든 값들을 하나하나 찾아서 전부 복사하는 방법

어떤 객체를 복사할 때 객체 내부의 모든 값을 복사해서 완전히 새로운 데이터를 만들 때, 객체의 프로퍼티 중에서 그 값이 기본형 데이터일 경우 그대로 복사하면 되지만, 참조형 데이터는 다시 그 내부의 프로퍼티들을 복사해야함. 이 과정을 참조형 데이터가 있을 때마다 재귀적으로 수행해야하지만 깊은 복사가 됨

자바스크립트에서 얕은 복사와 깊은 복사 구현하는 방법

const original = {name: '철수', age: 12};
const clone = { ...original };
clone.name = '영희'

console.log(original) // { name: '철수', age: 12 }
console.log(clone); // { name: '영희', age: 12 }

const original = {profile: {name:'철수', age:12}, grade: 'A'};
const clone = { ...original };

clone.profile.name = '영희';
clone.grade = 'B';

console.log(original) // {profile: {name: '영희', age: 12}, grade: 'A'}
console.log(clone); // {profile: {name: '영희', age: 12}, grade: 'B'}

const original = {name: '철수', age: 12};
const clone = Object.assign({}, original);
clone.name = '영희'

console.log(original) // {name: '철수', age: 12}
console.log(clone); // {name: '영희', age: 12}
console.log(original === clone) // false

const originalArray = [1, 2, 3, { a: 4 }];

const shallowCopyArray = originalArray.slice();

shallowCopyArray[3].a = 10;

console.log(originalArray); // [1, 2, 3, {a: 10}]
console.log(shallowCopyArray); // [1, 2, 3, {a: 10}]

const originalArray = [1, 2, 3, { a: 4 }];

const shallowCopyArray = originalArray.concat();

shallowCopyArray[3].a = 20;

console.log(originalArray); // [1, 2, 3, {a: 20}]
console.log(shallowCopyArray); // [1, 2, 3, {a: 20}]

const originalObj = {
  a: 1,
  b: { c: 2 },
};

const deepClone = (obj) => JSON.parse(JSON.stringify(obj));

function deepClone(obj) {
  if (obj === null || typeof obj !== 'object') {
    return obj;
  }

  const clone = Array.isArray(obj) ? [] : {};

  for (const key in obj) {
    if (Object.prototype.hasOwnProperty.call(obj, key)) {
      clone[key] = deepClone(obj[key]);
    }
  }

  return clone;
}

import _ from 'lodash';

const originalObj = {
  a: 1,
  b: { c: 2 },
};

const deepClone = _.cloneDeep(originalObj);

타입스크립트를 사용하는 이유

TypeScript란?

Javascript의 슈퍼 셋.
상위 확장자로 Javascript 엔진을 사용하며 자신이 원하는 변수의 타입을 정의하고 프로그램밍 하면 Javascript로 컴파일 되어 실행할 수 있다.

컴파일
사람이 이해할 수 있는 언어를 컴퓨터가 이해할 수 있는 언어로 바꾸어 주는 과정.
ts 는 js와 달리 브라우저에서 실행하려면 파일을 한번 변환 해 주어야 하는데 이러한 과정을 컴파일 이라고 한다.

TypeScript 장점

1. 손쉽게 버그를 예방할 수 있는 강력한 타입 시스텝

   • 컴파일 과정에서 타입을 지정하기 때문에 컴파일 에러를 예방할 수 있을뿐 아니라, 손쉬운 디버깅이 가능해 진다.

2. 같은 일을 두 번 하지 않는다. 높은 생산성의 타입 스크립트

   • js는 객체의 필드나 함수의 매개변수로 들어오는 값이 무엇인지 알기 위해 여러 파일을 살펴야한다.
   • ts는 변수 이름 뿐 아니라 그 데이터의 자료형까지 알수 있게 된다.
   • 타입 지정이 되어있기 때문에 리팩토링 후 예기치 않는 동작을 방지한다.

3. typescript는 javascript의 슈퍼셋 이다.

   슈퍼셋
   특정한 언어의 모든 기능을 포함하면서 다른 기능까지 활용 가능하도록 확장된 것을 말한다

   • js로 짜여진 코드를 확장하는 식으로 대규모 수정 없이도 ts적용이 가능하다.

TypeScript vs Javascript

동적타입
변수의 타입이 런타임, 즉 실행 시간에 결정된다
런타임 에러가 발생할 가능성을 가지고 있다

정적타입
컴파틸 단계에서 타입을 체크 하기 때문에 코드 작성중 타입 오류를 방지하는 타입 체킹이 가능하다

인터프리터 언어
소스코드를 한 줄 한 줄 읽어가며 명령을 바로 처리하는 언어 컴파일 언어에 비해 빠르다.

컴파일 언어
기계어로 변환한는 언어 변환과 실행이 따로 이루어짐
인터프리터 언어에 비해 시간이 오래 걸리지만 런타임 상황에서 모든 소스코드가 변환되어 있기 때문에 빠르게 실행

Type과 Interface의 차이점

확장(상속)

interface

extends 키워드를 이용해 확장

interface Person {
	name: string;
	age: number
}

interface Student extens Person{
	school:string;
}
const maru: Student  ={
	name:'maru',
	age:8,
	school:'tdc'
}

type

& 기호 사용 확장

type Person = {
	name: string,
	age:number
}
type Student = Person & {
	school: string
}

const maru:Student = {
	name:'maru'
	age:8
	school:'tdc'
}

선언적 확장

interface

선언적 확장이 가능하다
같은 이름의 interface를 선언하면 자동으로 확장된다.

interface Person {
	name:string,
	age:number
}
interface Person {
	gender:string
}
const maru: Person = {
	name:'maru',
	age:8,
	gender: 'male'
}

type

선언적 확장이 불가능

type Person = {
	name:string,
	age: number
}
type Person = { //Error
	gender: string;
}

타입 객체의 확장성을 위해서는 interface를 사용하는 것이 더 좋다.

자료형(type)

interface

객체(Object)의 타입을 설정할 때 사용할 수 있으며, 원시 자료형에는 사용할 수 없다.

interface Person {
	name:string;
	age:number;
	gender:string;
}

// 원시타입 확장 에러
interface name extends string {

}

type

객체 타입을 정의할 때도 사용할 수 있지만 객체타입을 정의할 때는 interface를 사용하는게 좋고,
단순한 원시값(Primivite type)이나 튜플(Tuple), 유니언(Union)타입을 선언할때 type을 사용하는 것이 좋다.

type name = string;
type Age = number;
type Person = [string, number, booleann] // tuple
type NumberString = string|number // union

// 객체는 interface
type Person = {
	name: string;
	age:number;
	gender:string
}

computed value 사용

interface

computed value 사용이 불가능

type Subjects = 'math'|'science'|'sociology'

//Error
interface Grades {
	[key in Subjects] :string 
}

type

computed value 사용이 가능

type Subjects = 'math'|'science'|'sociology'

type Grades = {
	[key in Subjects] :string
}

type 은 모든타입 선언할 때 사용할 수 있고
interface 는 객체에 대한 타입을 선언할 때만 사용할 수 있다.

확장 불가능한 타입을 선언하고 싶다면 type을 사용
확장 가능한 타입을 선언하고 싶다면 interface를 사용하면 된다.

React

useState

useState란?

const [count, setCount] = useState(0)

• 공홈의 정의 : 렌더링 사이에 데이터를 유지하기 위한 state 변수 + state 변수를 업데이트하고 리액트가 다시 컴포넌트를 리렌더링하게 하는 setState로 이루어진 상태관리 훅
• 좀 더 축약한 정의 : 데이터를 저장하고 유지할 수 있는 state를 가지고 setState를 통해 state의 상태를 관리하는 상태관리 hook
• setState는 기존의 state를 복사해 새롭게 state를 갱신 -> 객체의 불변성을 지킬 수 있음 -> 오류들을 미리 방지할 수 있음.
• setState를 통해 state에 변화가 생기면 알아서 리렌더링을 해주기 때문에 훨신 쉽게 상태관리를 할 수 있음

state, state management

useState가 상태를 관리하는 상태관리 훅이라고 했는데, 여기서 상태는 무엇이고 상태 관리는 무엇일까?

useState와 useRef의 차이점

가장 큰 차이점은 useState는 상태값을 관리하기 위해 사용되고, 상태가 업데이트될 때마다 컴포넌트가 리렌더링되며, UI에 반영이 됨.
반면 useRef는 컴포넌트의 생애주기동안 계속 유지되며, 값이 변경되어도 컴포넌트가 리렌더링되지 않음.

import { useRef, useState } from 'react;
import "./styles.css";

export default function App() {
  const [stateCount, setStateCount] = useState(0);
  const refCount = useRef(0);

  return (
    
    <div className="App">
      <button
        onClick={() => {
          setStateCount((prev) => prev + 1);}}> State</button>
      <button
        onClick={() => {
          refCount.current += 1;}} >Ref</button>
      <br />
      <br />
      <div>useState Count: {stateCount}</div>
      <div>useRef Count: {refCount.current}</div>
</div> 
);
}

useState의 불변성

• setState는 기존의 state를 복사해 새롭게 state를 갱신 -> 객체의 불변성을 지킬 수 있음 -> 오류들을 미리 방지할 수 있음.
• 예를 들면 useState를 통해 불변성을 유지하지 않고 임의로 상태를 변경하면 리액트가 상태 변경을 알아채지 못해 컴포넌트가 불필요하게 재렌더링되거나 혹은 이전 상태와 현태 상태를 리액트가 비교하지 못해 변경된 상태를 UI에 반영하지 못함.
• 따라서 아래와 같은 방식으로 불변성을 지키면서 값을 변경해야 함

setItem([...item, 'peach'])

정리

useState란?

• 데이터를 저장하고 유지할 수 있는 state를 가지고 setState를 통해 state의 상태를 관리하는 상태관리 hook
• setState는 기존의 state를 복사해 새롭게 state를 갱신 -> 객체의 불변성을 지킬 수 있음 -> 오류들을 미리 방지할 수 있음.
• setState를 통해 state에 변화가 생기면 알아서 리렌더링을 해주기 때문에 훨신 쉽게 상태관리를 할 수 있음

상태란?

컴포넌트 안에서 관리되고, useState 같은 훅을 통해 관리되며 사용자의 인터랙션에 따라 변화하는 데이터

상태관리란?

state를 props로 내려주는 방식을 사용하면 props drilling이 발생해 코드가 복잡해지고, 유지보수가 어려워짐 -> 상태관리 도구를 사용해 상태를 중앙에서 관리하고 필요한 컴포넌트만 사용하게 하여 코드의 복잡도를 줄이고, 유지보수가 용이하게 함

상태관리 툴

• Redux, Recoil, Zustand 등

useState와 useRef의 차이점

• useState : 상태값을 관리하기 위해 사용되고, 상태가 업데이트될 때마다 컴포넌트가 리렌더링되며, UI에 반영이 됨.
• useRef : 컴포넌트의 생애주기동안 계속 유지되며, 값이 변경되어도 컴포넌트가 리렌더링되지 않음.

useState의 불변성

state가 객체나 배열 등의 참조형 데이터인 경우, 기존 상태를 직접 수정하는 것이 아니라 새로운 상태를 생성해주�어 불변성을 유지하게 함 -> 불변성을 유지함으로써 React는 상태의 변화를 효율적으로 감지하고 필요한 컴포넌트만을 재렌더링할 수 있음

SPA

Single Page Application
하나의 HTML 페이지에서 새로운 페이지를 불러오지 않고, 필요한 부분만 동적으로 컨텐츠를 바꾸는 어플리케이션

MPA

Multiple Page Application
여러개의 페이지로 이루어져 있으며, 사용자가 페이지를 요청할 때마다 서버에서 렌더링된 HTML를 받아와서 컨텐츠를 변경하는 어플리케이션

SPA는 첫페이지만 서버에서 받아오고, 필요한 부분만 동적으로 변경
MPA는 여러페이지로 이루어져 있으며 페이지가 달라질 때마다 서버에서 렌더링 된 파일을 받아온다.

CSR

Client Side Rendering
SPA가 사용하는 렌더링 방식
첫 구동 시에 HTML, JS 파일을 받아오고, 사용자의 상호작용에 따라 js를 이용하여 동적으로 렌더링 진행

장점

• 동적으로 빠르게 렌더링 : 사용자 경험이 좋다
• 서버 요청 횟수가 적다: 서버의 부담이 덜한다.

단점

• 첫 화면을 보기까지 오랜시간이 걸린다.(FP,FCP속도 느림) : 초기 렌더링에 필요한 js파일의 크키가 크기 때문에 코드분할(code splitting)을 고려해야한다.
• 낮은 SEO 성능 : JS 중심이기 때문에 크롤링이 어려움

SSR

Server Side Rendering
MPA구현할때 사용 서버측에서 렌더링을 담당하는 방식
새로운페이지로 이동할 때 마다 서버에서 렌더링을 마친 HTML 파일을 받아와서 렌더링

장점

• 빠른 화면 로딩 (FP, FCP 빠름) : HTML파일을 먼저 서버에서 제공해 주기 때문에 사용자가 기다리지 않아도 된다.
• 빠른 TTI(Time To Interactive): 서버에서 페이지 로직 및 렌더링을 사전에 실행한 경우 js파일을 많이 보낼 필요가 없기 때문에 TTI또한 빠르게 수행도니다.
• 향상된 SEO : HTML 타이틀, 태그 등으로 검색 엔진에 노출되기 훨씬 쉬워진다.

단점

• 보이지만 작동 하지 않는 기능: html파일만 제공하기 때무에 화면에 보이지만 실제로 동적인 기능을 수행하기 위해서 js파일을 다운받아야 한다.
• 서버 과부하 위험: 페이지 요청시 마다 새로고침과 파일을 요청하기 때문에 서버부하가 크다
• 느린 TTFB(Time to First Byte) : 페이지 요청마다 html을 받아야 하므로 서버로부터 첫번째 byte가 오기까지 걸리는 시간이 csr보다 느리다.
• CDN 캐싱전략:-요청에 대한 HTML 파일을 받아올 때마다 렌더링을 해야하기 때문에 CDN을 활용한 캐싱 전략을 사용할 수 없다.

프론트엔드 관점에서의 프로세스와 스레드의 차이점

프로세스와 스레드는 웹 브라우저의 작동 방식과 밀접한 관련이 있다.
프로세스와 스레드를 사용하여 웹 애플리케이션을 효율적으로 실행하고 관리한다.

용어 정리

• 프로그램 : 파일이 저장 장치에 저장되어 있지만 메모리에는 올라가지 있지 않은 정적인 상태. (window-exe파일/MaxOS .dmg파일 )
• 프로세스 : 프로그램을 실행하는 순간 해당 파일은 컴포터 메모리에 올라가게 되고, 동적인 상태가 된다.
• 스레드 : 프로세스의 한계를 해결하기 위해 만들어진 개념 - 프로세스 내에서 실행되는 결양의 실행단위로, 프로세스의 자원을 공유한다.

프로세스

• 브라우저 프로세스 : 웹 브라우저는 각 탭을 별도의 프로세스로 실행한다. 한 탭에서 발생하는 문자게 다른 탭이나 브라우저에 영향을 주지 않도록 격리하는데 도움이 된다.
• 안전성과 독립성: 탭이 별도의 프로세스로 동작하므로 한 탭에서 발생한 오류나 메모리 누수가 다른 탭에 영향을 미치지 않아 안정성이 향상된다.

스레드

• 렌더링 엔진의 스레드 : 프론트엔드 개발에 중요한 요소는 브라우저의 렌더링 엔진이다.
  렌더링 엔진은 HTML. CSS 를 파싱하고 DOM 트리를 구축하는 등의 작업을 수행하는 여러 스레드로 구성되어 있다.
• 자바스크립트 실행 : 자바스크립트는 싱글 스레드로 실행된다. 하지만 비동기 처리와 이벤트 루프를 통해 동시에 여러 작업을 처리하는 것처럼 보일 수 있다.

프론트엔드 개발 적용

• 비동기 프로그래밍의 중요성 : 비동기 프로그래밍은 UI 스레드를 차단하지 않고 백그라운드에서 데이터를 가져오거나 처리하는데 중요하다.
• 웹 워커의 사용 : 복잡한 계산이나 데이터 처리를 백그라운드 스레드에서 수행하기 위해 웹워커를 사용 할 수 있다. 메인 스레드의 UI 블로킹을 방지하고 성능을 향상 시킨다.
  웹 애플리케이션의 성능 최적화 와 효율적인 리소스 관리에 필수적이다. 이러한 이해를 바탕으로 사용자에게 더 나은 경험을 제공하는 웹 에플리케이션을 구축할 수 있다.

HTTP, HTTPS

HTTP

• 애플리케이션 계층의 프로토콜로 클라이언트와 서버 간에 하이터 텍스트를 전송할 때 사용됨
• HTTP는 암호화가 되지 않기 때문에 데이터가 전송되는 동안 제 3자가 정보를 도청하거나 변조할 수 있는 위험이 있음.

하이퍼 텍스트란?
문서들 사이를 연결해주는 참조 링크(hyperlink)를 의미�함. 예를 들면 우리가 흔히 볼 수 있는 HTML 문서 내에 있는 파란색 밑줄로 되어있는 링크가 연결�된 글자임. 웹 페이지에 있는 텍스트를 클릭하면 다른 문서나 웹페이지로 이동할 수 있는데, 이를 가능하게 하는 것이 바로 하이퍼텍스트임

HTTPS

• HTTP만으로는 위에서 말했던 문제들이 발생할 수 있음
• 따라서 이를 방지하기 위해 HTTP 통신에 신뢰성과 무결성(데이터가 조작되지 않았다는 것을 증명하는 것)을 추가함
• 자신을 신뢰할 수 있음을 증명하는 인증서를 사용 및 통신 내용은 SSL(Secure Socket Layer)/TLS(Transport Layer Security)를 사용하여 암호화함
• HTTPS에서 클라이언트와 서버는 신뢰할 수 있는 상대인지 확인하기 위해 인증서를 이용한 비대칭 키 암호화 방식을 사용함(참조)

SSL/TLS란?

• 전송 계층에서 보안을 제공하는 프로토콜로 클라이언트와 서버가 통신할 때 제 3자가 메시지를 도청하거나 변조, 데이터를 중간에서 인터셉트하지 못하도록 함. 따라서 HTTPS는 HTTP에 비해 데이터 전송 과정에서 더 안전함

참고

• https://tlogkr.tistory.com/70
• https://howhttps.works/ko/

1. Props와 State의 차이?

Props와 State는 모두 컴포넌트의 데이터를 다루는데 사용

1) props

컴포넌트가 외부에서 받는 데이터.
부모 컴포넌트로 부터 자식 컴포넌트로 전달 되는 데이터.
props는 읽기 전용 이므로 직접 수정 할 수 없다.

2) state

컴포넌트 내부에서 관리 되는 데이터.
컴포넌트의 상태를 변경하거나 업데이트할 때 사용된다.
state는 읽기와 쓰기 모두 가능, setState()함수를 이용하여 값이 변경됨. 사용자 입력 또는 네트워크 응답과 같은 이벤트에 응답하여 state를 업데이트 한다.

3) 왜 변수가 아닌 state에 데이터를 저장하는가?

변수에 데이터를 저정 하여도 되나, 변수값이 바뀌었을 때 일반 변수는 리렌더링 되지 않으나 state는 리렌더링 되며 리액트에서 분리된 컴포넌트 별로 리렌더링을 하게 하여 성능을 높일수 있다.

2. State의 불변성은 어떻게 유지 ?

불변성?

메모리 영역에서 직접적인 변경을 하지 않고, 기존의 값을 수정하지 않으면서 새로운 값을 만들어 내는 것

기존의 state의 불변성을 지켜주어야만, 리액트 컴포넌트에서 상태가 업데이트가 됐음을 감지 할 수 있고 이에 따라 필요한 리렌더링이 진행된다.

리액트에서 불변성을 지켜야 하는 이유?

1) 얕은 비교를 통해 상태 변화를 감지

리액트는 상태 값을 업데이트 할 때 얕은 비교(객체의 참조 주소값만 변경되었는지 확인)를 수행한다. 이전 참조 값과 현재 참조값만을 비교하여 상태 변화를 감지한다. 불변성을 지킴으로써 리액트는 상태 변화를 감지 할 수 있다.

2)사이트 이펙트 방지

외주에 존재하는 원본데이터를 직접 수정하지 않고, 원본데이터의 복사본을 만들어 값을 사용하기에 예상치 못한 오류를 사전에 방지 할수 있다.

불변성을 지키는 방법

• spread operator
• map
• filter
• slice
• reduce
  등 새로운 배열을 반환하는 메소드들을 활용한다.

setState를 이요할 때 원시타입 경우에는 값을 바로 넣어 주어도 되지만 참조타입인 경우에는 새로운 객체나 배열을 생성한 후 값을 넣어주어야 한다.

//원시타입
const [number, setNumber] = useState(0) setState(3) 
// 참조타입 
const [person, setPerson] = useState({ name: '', age: 30 }) setState({...person, name: 'pyo'})

3. key Props를 사용하는 이유?

key란?

React가 어떤 항목을 변경, 추가 또는 삭제할지 식별하는 것을 돕고, 엘리먼트에 안정적인 고유성을 부여 하기 위해 배열 내부의 엘리먼트에 지정해야 한다. (유일한 식별자의 역할을 가진다.)

key를 사용하는 이유

key props를 주었을 때는 변경된 부분을 식별해 필요한 부분만 리렌더링 해주지만 없을 경우 불필요한 리렌더링이 발생된다. 그렇게 되면 속도 저하, 의도치 않은 오류등이 발생 시킬 수 있다.

key props 의 index

인덱스를 key로 사용 중 배열이 재배열 되면 컴포넌트의 state와 관련된 문제가 발생할 수 있다. 컴포넌트 인스턴스는 key를 기반으로 갱신되고 재사용된다. 인덱스를 key로 사용하면 항복의 순서가 바뀌었을때 key 또한 바뀔것이며 그 결과로 컴포넌트의 state가 엉망이 되거나 의도지 않은 방식으로 바뀔수 있다.
그러므로 해당데이터의 id값을 key props로 주고 렌더링 한 항목에 대한 안정적인 id가 없다면 최후의 수단으로 항동의 인덱스를 key를 사용하는 것이 좋다.

브라우저에 www.naver.com을 입력하면 어떤 일들이 일어날까?

1. 유저가 브라우저에 url을 입력함

url(Universal Resource Locator)이란?
서버에 자원을 요청하기 위해 입력하는 영문주소

2. DNS(domain name system) 조회
   DNS는 브라우저가 리소스를 로드할 수 있도록 도메인 이름을 IP주소로 변환함
   우선 브라우저는 로컬에 DNS 캐시가 있는지 살펴보고 없으면 ISP(ex: SK 브로드밴드, KT 등)의 DNS 서버에 해당 도메인 이름에 해당하는 IP 주소를 요청함
   그러면 DNS 서버는 도메인 이름에 해당하는 IP 주소를 찾아 반환함

3. 브라우저는 이렇게 얻은 IP주소를 사용해 서버와 통신하기 위해 TCP 연결을 함.
   이 과정에서 3-way-handshake가 이루어짐(이를 통해 서버와 연결 및 데이터를 수신 받을 수 있게됨)

3-way-handshake란?
TCP 통신을 사용해 데이터를 전송하기 위해 네트워크 연결을 설정하는 과정

1. 클라이언트는 서버에 접속을 요청하는 SYN 패킷 전송
2. 서버는 SYN 요청을 받고 클라이언트에게 요청을 수락한다는 SYN_ACK-flag가 설정된 패킷 전송
3. 클라이언트는 서버에게 ACK를 전송 후 연결이 이루어짐 -> 데이터를 주고 받을 수 있게 됨

4. 브라우저는 설정된 TCP 연결을 통해 서버에 HTTP 요청 보냄
5. 서버는 요청을 처리 후 응답을 보냄
6. 브라우저는 응답을 수신 후 렌더링함(브라우저 렌더링)

Rest

웹의 기존 기술과 HTTP프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일
구체적으로 HTTP URI를 통해 어떤 자원인지 명시하고, HTTP Method(GET,POST,PUT,PATCH,DELETE)를 통해 해당 자원을 처리하도록 설계 된 것 이다.

6가지 원칙

• Uniform interface(인터페이스 일관성)
  • URI로 지정한 자원에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 것을 말한다.
  • HTTP 표준 프로토놀에 따르는 모든 플랫폼에서 사용이 가능
• Stateless(무상태)
  • 세션 정보나 쿠키를 별도로 저장하고 관리하지 안힉 때문에 API 서버는 들어오는 요청만 단순히 수행한다.
  • 이전 요청이 다음 요청의 처리에 연관되면 안된다.
  • 서비스의 자유가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해 진다.
• Cacheable(캐시 처리 기능)
  • 웹표준 HTTP프로토콜을 그대로 사용하므로 웹에서 사용하는 기존 인프라를 그대로 활용 할수 있다.
  • HTTP가 가진 캐싱 기능 적용이 가능하다. 그렇기에 대량의 요청을 효율적으로 처리할 수 있다.
• Client-Server(클라이언트 - 서버 구조)
  • Client는 사용자 인증이나 컨텍스트(세션, 로그인정보)등을 직접 관리하고 책임진다.
  • REST 서버는 API 제공하고 비즈니스 로직 처리 및 저장을 책임진다.
  • 각각의 역할이 확실히 구분되기 때문에 서로 간의 의존성이 줄어든다.
• Layered System(계층화)
  • Client는 REST API Server만 호출합니다.
  • REST API Server는 다중 계층으로 구성된다.
    • 보안, 로드밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있다.
    • Proxy, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있게 한다.
• Code-On-Demand(opional)
  • server가 네트워크를 통해 client에 프로그램을 전달하면 client에서 실행될 수 있어야 한다

REST API 란

API(Application Programming InterFace)란 프로그램과 또다른 프로글매을 연결해주는 일종의 다리라고 볼수 있다.
REST기반으로 서비스 API를 구현한 것이다.
즉, HTTP요청을 보낼 때, 어떤 URI에 어떤 메소드를 사용할지 개발자들 사이에 널리 지켜지는 약속이다.

REST API 설계 기본 규칙

• URI는 정보의 자원을 표현해야한다.
  • 동사보다는 명사를, 대문잡다는 소문자
  • 자료에 따라 단수명사, 복수 명사 구분
• 자원에 대한 행위는 HTTP Method(GET,PUT,POST,DELETE)로 표현한다.
  • URI에 HTTP Method가 들어가면 안된다.
  • URI에 행위에 대한 동사 표현이 들어가면 안됀다.
  • 경로 부분 중 변하는 부분은 유일한 값으로 대체

REST API 설계 규칙

• 슬래시 구분자(/)는 계층 관계를 나타내는데 사용
• URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
• 하이픈 (-)은 URI 가독성을 높이는데 사용ㅎ나다.
• 밑줄( _ )은 URI에 사용하지 않는다.
• URI 경로에는 소문자가 적합하다
• 파일확장자는 URI에 포함하지 않는다.

응답상태 코드

• 1xx : 정보응답
• 2xx: 성공응답
• 3xx:리다이렉션 메시지
• 4xx: 클라이언트 에러 응답
• 5xx: 서버 에러 응답

RESTful이란

RESTful은 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어
'REST API'를 제공하는 웹 서비스를 'RESTful'하다고 할수 있다.
RESTful은 REST를 REST답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것이 아니다. 즉, REST원리를 따르는 시스템은 RESTFul이란 용어로 지칭된다.

React에서 State의 불변성 유지

state의 불변성 유지 방법

setState는 기존의 state를 복사해 새롭게 state를 갱신 -> 객체의 불변성을 지킬 수 있음 -> 오류들을 미리 방지할 수 있음.
예를 들면 불변성을 유지하지 않고 임의로 state를 변경하면 리액트가 상태 변경을 알아채지 못해 컴포넌트가 불필요하게 재렌더링되거나 혹은 이전 상태와 현태 상태를 리액트가 비교하지 못해 변경된 상태를 UI에 반영하지 못함.
따라서 아래와 같은 방식으로 불변성을 지키면서 값을 변경해야 함

예시
const [item, setItem] = useState(['apple', 'banana', 'orange'])라는 배열을 가진 state가 있다고 가정함
여기에 'peach'를 추가한다고 했을 때 item.push('peach')를 한다면 직접 변경을 하는 것이기 때문에 리액트는 item 배열의 변화를 알지 못함(변경을 할 때는 setState를 사용해 이전 상태와는 별개의 새로운 상태를 생성하기 때문(그러니까 똑같이 생겼는데 메모리 주소값을 다르게해서 새로운 상태를 만듦))
따라서 불변성을 유지하면서 상태를 변경하려면 리액트에서는 다음과 같이 할 수 있음

setItem([...item, 'peach'])

스프레드 연산자를 사용해 기존 item의 요소들을 새로운 배열에 복사 후 'peach'라는 새로운 요소를 새로운 배열에 추가함. 그러면 기존 item배열은 변하지 않고 기존의 item 배열과는 별개의 새로운 배열이 생성되어 state가 업데이트 됨

REST API

REST(Representational State Transfer)란?

• 웹 상의 자원을 HTTP URI를 통해 특정하고 HTTP Method를 통해 해당 자원에 대한 작업을 수행하는 방식을 말함
• REST는 웹의 기존 기술과 HTTP 프로토콜을 그대로 사용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일임

REST의 구성요소

• 자원(Resource) : URI를 통해 자원의 이름을 나타내고 웹 상에서 해당 자원을 찾을 수 있는 위치를 제공
  ex: 'https://www.example.com/products'

• 행위(Verb) : HTTP 메소드(GET, POST, PATCH, DELETE 등)

• 표현 (Representations) :

  • 클라이언트와 서버가 데이터를 주고 받는 형태
  • JSON, XML, TEXT, RSS 등이 있음
  • 주로 JSON이나 XML을 통해 데이터를 주고 받음

[
  {
    "name": "globe",
    "price": 50000,
    "color": "black"
  },
  {
    "name": "shirts",
    "price": 30000,
    "color": "red"
  }
]

위 JSON 객체는 서버가 클라이언트에게 보내는 표현임. 이를 통해 서버는 'products' 자원의 상태를 JSON 형태로 클라이언트에게 전달함

REST의 원칙(특징)

(1) Uniform (유니폼 인터페이스)
모든 자원과 행위가 일관된 방식으로 이루어지는 아키텍처를 말함
ex: 모든 웹 자원은 URI로 표현되고, 해당 자원에 대한 행위는 HTTP 메소드(GET, POST, PUT, DELETE 등)로 일관되게 표현됨 -> 개발자가 API를 쉽게 이해하고 사용할 수 있도록 도와줌

(2) Stateless (무상태성)
REST는 작업을 위한 상태정보를 따로 저장하고 관리하지 않�음.
세션 정보나 쿠키정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리하면 됨 -> 따라서 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해짐

(3) Cacheable (캐시 가능)
HTTP라는 기존 웹표준을 그대로 사용하기 때문에 웹에서 사용하는 기존 인프라를 그대로 활용이 가능함. 따라서 HTTP가 가진 캐싱 기능이 적용 가능함. Last-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능함(서버에서 응답과 함께 온 'Last-Modified' 태그나 'ETag' 태그를 받아 자동으로 저장하고, 다음 요청 시 'If-Modified-Since' 또는 'If-None-Match' 헤더를 추가하여 요청을 보냄)

(4) Self-descriptiveness (자체 표현 구조)
REST API 메시지만 보고도 이를 쉽게 이해 할 수 있음

(5) Client - Server 구조
REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어들게 됨

(6) 계층형 구조
REST 서버는 다중 계층으로 구성될 수 있음
즉, 클라이언트가 직접 연결된 서버로부터만 응답을 받는 것이 아니라, 여러 개의 중간 계층(로드 밸런서, 캐시 서버 등)을 거쳐서 응답을 받을 수 있다는 의미임.
ex: 클라이언트의 요청이 먼저 로드 밸런서에 도착 -> 로드 밸런서는 요청을 처리할 서버를 선택하여 요청을 전달

이런 계층형 구조는 시스템의 확장성과 유연성을 높여줌

REST API

REST의 원칙을 따르는 API를 의미함

REST API의 설계 규칙

1. URI는 대문자보다는 소문자를, 동사보다는 명사를 사용

http://www.example.com/Member/delete/1 (x)
http://www.example.com/member/1 (O)

URI는 자원을 표현하는데 중점을 두어야 하기 때문에 delete와 같은 행위에 대한 표현이 들어가서는 안 됨
그리고 대소문자에 따라 다른 리소스로 인식하게 되기 때문에 URI에 대문자는 가급적 사용하지 않는게 좋음

2. 마지막에 슬래시를 포함하지 않음

http://www.example.com/run/ (x)
http://www.example.com/run (O)

3. 언더바(_) 대신 하이픈(-)을 사용

http://www.example.com/run_member (x)
http://www.example.com/run-member (O)

4. URI에 파일 확장자 포함하지 않음

http://www.example.com/photo.jpg (x)
http://www.example.com/photo (O)

5. 행위를 포함하지 않음

`DELETE` http://www.example.com/delete/post (x)
`DELETE` http://www.example.com/post/:id (O)

행위에 대한 정의는 HTTP METHOD를 통해 하기!

HTTP 응답 상태 코드

잘 설계된 REST API는 리소스에 대한 응답을 잘 주는 것까지 포함되어야 함

RESTful API이란?

REST의 설계 규칙을 잘 지켜서 설계된 API를 RESTful한 API라고 함

예를 들면 어떤 사람이 /api/post라는 URI에 대한 CRUD에 관한 행위를 모두 POST로 처리했다고하면 REST를 사용하긴 했지만 설계 규칙을 제대로 지키지 않음(유니폼 인터페이스 원칙에 어긋남) -> REST API를 사용하긴 했지만 RESTful하지 못하다고 할 수 있음

리덕스를 사용 하면 컴포넌트의 상태 관련 로직들 을 다른 파일로 분리시켜서 더욱 효율적으로 관리할 수 있으며 글로벌 상태 관리도 손쉽게 할 수 있다.

리덕스 사용 여부

1. 프로젝트의 규모가 큰가?
2. 비동기 작업을 자주 사용하는가?
3. 리덕스가 사용하기 편한가?

액션

• 앱에서 스토어에 운반할 데이터
• 무조건 객체 형태 여야한다.
• type 프로퍼티를 필수적으로 갖고 있어야 하며, 그 외의 값은 상황에 따라 자유롭게 넣어줄 수 이따.
• dispatch의 파라미터로 전달된다.

{
	type: 'CHANGE_INPUT', // 필수
	text : '블라블라',
	data :{
		id:0,
		text:"리덕스 배우기"
	}
}

액션 생성함수(Action Creator)

• 액션을 만드는 함수
• 컴포넌트에서 쉽게 액션을 발생시키기 위해서 export키워드를 붙여 다른 파일에서 불러와서 사용

export function addTodo(data){
	return {
		type:"ADD_TODO".
		data
	}
}

리듀서

• 변화를 일으키는 함수
• 기존상태를 전달 받은 action을 참고해서 새로운 상태를 반환한다.

function reducer(state, action) {
  // 상태 업데이트 로직
  return alteredState;
}

스토어

• 한 애플리케이션당 하나의 스토어를 만든다.
• 구성: 현재의 앱 상태 / 리듀서/ 몇가지 내장 함수
• 스토어가 하는일
  • 애플리케이션의 상태를 저장
  • getState()을 통해 상태에 접근할 수 있게 해준다.
  • dispatch을 통해 상태를 수정할 수 있게 해준다.
  • subscribe(listner)를 통해 리스너를 등록

디스패치(dispatch)

• 스토어의 내장함수 중 하나
• 액션을 발생
• 액션을 파라미터로 전달

구독

• 스토어의 내장함수 중 하나
• 함수형태의 값을 인자로 받는다
• subscribe함수에 특정 함수를 전달해주면, 액션이 디스패치 되었을 때 마다 전달해준 함수가 호출된다.

리덕스의 3가지 규칙

1. 하나의 애플리케이션안엔 하나의 스토어가 있어야한다.
2. 상태는 읽기 전용이다.
3. 리듀서는 순수함수여야 한다.

Flux 패턴

client-side 웹 애플리케이션을 만들기 위해 사용하는 디자인 패턴

MVC(Model, View, Controller)

• Model : 데이터 저장
• Controller : Model의 데이터를 관리(CRUD)
• View: Model의 데이터가 변경되면 View로 전달되어 사용자에 보여진다.
  View를 통해 데이터를 입력하면 Model을 업데이트 할 수 있다. 데이터가 양방향으로 흐를 수 있다

View가 업데이트가 되고 업데이트된 View가 또다른 Model을 업데이트하면서 복잡한 데이트 흐름을 가지게 된다. 많은 의존성을 가지면 Model의 개수가 많아질수록 이벤트가 애플리케이션 전체로 퍼저나갈때 이를 예측하기 힘들어진다.

Flux

MVC패턴의 복잡성을 해소하기 위해 데이터가 한 방향으로만 흐르도록 Flux 패턴이 생겨났다.

Flux 패턴은 단방향 데이터 흐름을 유지한는 아키텍처 디자인 패턴이다. 사용자의 입력을 기반으로 Action을 만들고, Action을 Dispatcher에 전달하여 Store의 데이터를 변경한 뒤 View에 반영하게 된다.
단방향 흐름을 사용 하여 데이터를 일관성과 예측가능하게 유지하며 복합성을 낮추고 유지보수성을 높이는데 도움이 된다.

action

• 애플리케이션에서 일어나는 이벤트를 나타내는 객체
• Action creator 메서드는 새로 발생한 action의 type과 새로운 데이터(playload)를 묶어 Dispatcher에 전달한다.

Dispatcher

• Action을 받아서 Store에 전달하는 역할
• 모든 데이터의 흐름을 관리하는 중앙 허브
• Store의 데이터를 조작하는 것은 오직 Dispatcher만 가능하다.

Store

• 애플리케이션의 모든 상태와 로직을 가지고 있다.
• Store의 state변경이 완료되면 변경된 상태를 View에 전달한다.

View

• Flux의 view는 MVC 의 View와는 달리 Store에서 데이터를 가져오는 한편 데이터를 자식 View로 전달 하기도 하는 일종의 View-controller로 보아야 한다.
• 리액트의 컴포넌트 이다.

아키텍처와 디자인패턴

MVC는 애플리케이션의 구성 요소를 세가지 역할(Model, view, Controller)로 나눈 아키텍처 디자인패턴이고
Flux는 단반향 데이터 흐름을 구현하는데 사용 되는 디자인 패턴이다.

아키텍처 디자인 (MVC)
전체 시스템의 구조와 구성 요소 간의 관계를 설계 하는것

디자인패턴 (Singleton, Observer)
소프트웨어 개발 시 특정 상황에서 자주 발생하는 문제를 해결하는 패턴을 쉽게 재사용할 수 있도록 추상화한것.

이벤트 흐름

HTML 문서의 각 엘리먼트들은 태그 안에 태그가 위치하는 계층적으로 이루어져 있다. 계층적 구조 특징 때문에 요소의 이벤트가 발생할 경우 연쇄적 이벤트 흐름이 일어난다.
전파 방행에 따라 버블링과 캡처링으로 구분한다.

버블링

자식 요소에서 발생한 이벤트가 바깥 부모 요소로 전파

<div id="ancestor">
	<div id="parent">
		<div id="child"></div>
	</div>
</div>
<script>
	ancestor.addEventListener("click", (e) => {
	  console.log('ancestor clicked');
	})
	parent.addEventListener("click", (e) => {
	  console.log('parent clicked');
	})
	child.addEventListener("click", (e) => {
	  console.log('child clicked');
	})
</script>

캡쳐링

자식요소에서 발생한 이벤트가 부모요소부터 시작해서 안쪽 자식 요소까지 도달

<div id="ancestor">
    <div id="parent">
   		<div id="child"></div>
    </div>
</div>

<script>
	ancestor.addEventListener("click", (e) => {
	  console.log('ancestor clicked');
	}, true)
	parent.addEventListener("click", (e) => {
	  console.log('parent clicked');
	}, true)
	child.addEventListener("click", (e) => {
	  console.log('child clicked');
	}, {capture: true})
</script>

이벤트 전파 방지

꼭 필요한 경우를 제외하곤 버블링, 캡처링을 막는 것은 좋지 않다.

e.stopPropagation()

버블링, 캡처링 설정에 따라 이벤트 전파를 막을 수 있다.

ancestor.addEventListener("click", (e) => {
  e.stopPropagation() // 이벤트 전파 방지
  print('ancestor')
})
parent.addEventListener("click", (e) => {
  e.stopPropagation() // 이벤트 전파 방지
  print('parent')
})
child.addEventListener("click", (e) => {
  e.stopPropagation() // 이벤트 전파 방지
  print('child')
})

e.stopImmediatePropagagation()

이벤트 전파 뿐 아니라 같은 요소에 발생한 동일한 이벤트에 대한 다른 이벤트 핸들러의 실행까지 막는다.

child.addEventListener("click", (e) => {
    
    if(조건)
    	e.stopImmediatePropagation()
        
    print('child')
})
child.addEventListener("click", (e) => {
    print('child 2')
})

e.target

직접 조건 분기를 통해 일일히 지정해 줄 수 있다.

document.body.addEventListener('click', (e) => {
    if (e.target.id === "ancestor") {
        print('ancestor')
    }
    if (e.target.id === "parent") {
        print('parent')
    }
    if (e.target.id === "child") {
        print('child')
    }
    
});

e.target vs this(e.currentTarget)

• e.target 부모로부터 이벤트가 위임되어 발생하는 자식의 위치, 내가 클릭한 자식요소 반환
• e.currentTarget 이벤트가 부착된 부모의 위치 반환

이벤트 위임

비슷한 방식으로 여로 요소를 다뤄야 할 때 사용된다.
이벤트 위임을 사용하면 요소마다 핸들러를 할당하지 않고, 요소의 공통 조상에 이벤트 핸들러를 단 하나만 할당해도 여러 요소를 한꺼번에 다룰 수 있다.

<ul id="menu">
  <li><button id="file">파일</button></li>
  <li><button id="edit">편집</button></li>
  <li><button id="view">보기</button></li>
</ul>
<script>
document.getElementById('menu').addEventListener('click',function(e){
	var target = e.target
	if(target.id === 'file'){
	
	}else if(target.id === 'edit'){
	
	}else if(target.id === 'view'){
	
	}
})
</sctipt>

이벤트 위임의 장점

1. 동적인 엘리먼트에 대한 이벤트 처리가 수월하다
2. 이벤트 핸들러 관리가 쉽다
3. 메모리 사용량이 줄어든다.
4. 메모리 누수 가능성도 줄어든다.

콜백함수, 비동기

콜백함수

const example = (cb) => {
  setTimeout(() => {
    console.log("비동기 함수 완료");
  }, 2000);
};

console.log("비동기함수 호출");
example(() => {
  console.log("콜백함수 실행");
});
console.log("비동기 함수 호출 후 코드");

함수의 인자로 다른 함수를 전달하고 해당 함수의 실행이 끝나면 전달받은 함수를 실행하는 방식임
이를 통해 비동기적인 동작을 구현할 수 있음
하지만 콜백함수로 비동기 동작을 구현하다보면 콜백헬이 발생함

콜백헬이란?

비동기 처리 로직을 구현하기 위해 콜백 함수를 중첩하여 사용하게 되면서 발생하는 것
콜백 함수 내부에 다시 콜백 함수를 정의하고 그 안에 또 콜백 함수를 정의하는 식으로 코드가 깊게 중첩되면서 발생하는 현상
주로 이벤트 처리 및 서버 통신과 같은 비동기적 작업을 수행할 때 발생했었음

이렇게 콜백헬이 발생하면 코드를 이해하기 어려워지고 유지 보수하기에 어려워짐
따라서 비동기적인 것을 동기적으로 보이게 하는 것이 필요함
이를 위해 나온 것이 Promise, Generator(ES6), async & await(ES7)임

비동기란?

• 동기
  현재 코드가 끝날 때까지 다음 코드를 실행하지 않는 것

• 비동기
  실행 중인 코드의 완료 여부와 무관하게 즉시 다음 코드로 넘어가는 방식
  ex: addEventListener, setTimeout 등

자바스크립트에서의 비동기 런타임 과정

여기를 참조해보자
아주 자세하게 설명되어 있음

Promise

비동기 작업의 최종 완료 또는 실패를 나타내는 객체이며, 콜백 함수로 인한 콜백헬을 해결하기 위해 도입된 개념
Promise는 pending, fulfilled, rejected의 세 가지 상태를 가지고, .then()과 .catch() 메소드를 통해 비동기 작업의 성공, 실패를 처리할 수 있음

var addCoffee = function (name) {
	return function (prevName) {
		return new Promise(function (resolve) {
			setTimeout(function () {
				var newName = prevName ? (prevName + ', ' + name) : name;
				console.log(newName);
				resolve(newName);
			}, 500);
		});
	};
};

addCoffee('에스프레소')()
	.then(addCoffee('아메리카노'))
	.then(addCoffee('카페모카'))
	.then(addCoffee('카페라떼'));

async, await

ES7에 새로 도입된 비동기 처리 패턴으로 async는 함수 앞에 위치하며 해당 함수는 항상 Promise를 반환함
await는 async 함수 내부에서만 사용할 수 있으며 Promise의 처리가 끝날 때까지 기다린 후 결과를 반환함
이를 통해 비동기 처리 시간을 기다리면서도 동기적인 코드처럼 보이는 코드를 작성할 수 있음

var addCoffee = function (name) {
	return new Promise(function (resolve) {
		setTimeout(function(){
			resolve(name);
		}, 500);
	});
};
var coffeeMaker = async function () {
	var coffeeList = '';
	var _addCoffee = async function (name) {
		coffeeList += (coffeeList ? ', ' : '') + await addCoffee(name);
	};
	await _addCoffee('에스프레소');
	console.log(coffeeList);
	await _addCoffee('아메리카노');
	console.log(coffeeList);
	await _addCoffee('카페모카');
	console.log(coffeeList);
	await _addCoffee('카페라떼');
	console.log(coffeeList);
};
coffeeMaker();

로딩 최적화 와 렌덜이 최적화로 구분하여 방법을 작성한다.

렌더링 최적화

웹 페이지 렌더링 최적화의 목표는 리플로우를 최대한 적게 발생시키면서, 빠르게 화면을 그리는 것

1. CSS 최적화

1. 리플로우, 리페인트를 고려한 스타일 작성

리플로우
레이아웃의 넓이, 높이, 위치 등에 영향을 주는 CSS속성을 변경할 경우 'Layout'부터 다시 그려지게 된다. 이를 리플로우 라고 한다

position / width / height / margin / padding / display / top / left / right / bottom / 
box-sizing / border-color / text-align / border / border-width / 
font-family / float / font-size / font-weight / line-height / vertical-align / 
white-space / word-wrap / text-overflow / text-shadow ...

리페인트
레이아웃에 영향을 주지 않는 속성을 변경하면 레이아웃을 건너뛰고 페인트 작업부터 다시 수행하게 되는데 이를 리페인트라고 한다.

color / border-style / visibility / background / background-color / 
background-image / background-position / background-repeat / background-size / 
text-decoration / outline / outline-style / outline-color / outline-width / 
border-radius / box-shadow ...

리플로우와 리페인트를 발생시키지 않는 속성

opacity / transform / cursor / z-index ...

리플로우가 일어나면 브라우저가 전체 픽셀을 다시 계산해야 하기 때문에 리페인트 속성을 사용하여 스타일을 작성하는 것이 성능면에서 좋다.

2. 사용하지 않는 CSS 제거
   lighthouse 에서 확인후 제거한다.

3. 간결한 스타일 작성
   복잡한 셀렉터는 지양한다. 레이아웃을 그리는데 시간 소요가 된다.

2. HTML최적화

1. 인라인 스타일을 사용하지 않는다.
   • 불필요한 코드 중복 발생
   • 레이아웃에 영향을 미치면서 리플로우가 발생
   • 스타일 시트에 작성하는 것이 표준에 맞고 유지보수 에도 적합
2. 복잡한 DOM 지양
   자식요소가 많을 수록 DOM트리가 커지며 계산해야는 것들이 많아진다. (불필요한 div wrapper)

3. 애니메이션 최적화

1. css 통해 구현 하는 것이 성능면에서 좋다
2. transform은 리플로우와 리페인트 모두 발생시키지 않고 합성만 발생시키는 속성이며 사용시 렌더링 속도를 향샹 시킬수 있다.
3. position설정 시 absolute나 fixed로 설정하면 주변 요소에 영향을 주지 않는다.

4. JS 최적화

강제 동기 레이아웃 피하기/레이아웃 스레싱(thrashing) 피하기

• 레이아웃 단계가 완료되기 전에 요소의 위치나 크기를 변경 후 바로 가져오려고 하면 강제로 레이아웃이 발생한다. (강제동기 레이아웃이라 한다.)
• 레이아웃을 반복적으로 발생시키는것을 레이아웃 스레싱이다.

로딩 최적화

1. 렌더 블로킹 최적화

1. css는 head, js는 body 하단에서 불러온다.
   • 빠르게 로드 되면 시각적으로 빠르게 그려진다.
   • script는 html파싱을 멈추고 파일을 다운로드 한다. 모든 구조들이 끝나고 js 다운로드 하는것이 좋다.
2. media 속성 사용
   • 조건별로 css 불러올 수 있다.
   • media 속성이 없는 스타일시크는 해당 스타일 시트를 브라우저가 해석하는 동안 화면에 스타일을 불러오지 않는다.
3. async/ defer
   • async : 다운로드 후 즉시 실행
   • defer : 웹헤이지가 모두 그려지고 DOM이 들어왔을때 스크립트 실행

<!-- 병렬 다운로드 & 즉시실행 -->
<script async src="test.js"></script>

<!-- 병렬 다운로드 & 지연실행 -->
<script defer src="test.js"></script>

<script> - 반드시 순서대로 실행되어야 할때
<script async> - 빨리 실행되어야 할때
<script defer> - 마지막에 파싱해도 상관없을때

2. 이미지 최적화

1. 환경에 맞는 이미지

• webp
• avif : 크롬/삼성지원 저용량이면서 고품질
• media 사용하여 브라우저 사이즈 맞는 이미지 제공

<source srcset="mob.webp" media="(max-width: 760px)">

2. img 지연 로딩(loading)
   • 화면 지연/병렬 로딩
   • auto: 디폴트
   • lazy: 화면상 보이는 부분만 출력
   • eager : 위치 상관없이 페이지가 로딩되자마자 이미지 로드

<img src="item.jpg" loading="lazy" alt>

3. 스프라이트 이미지
   • 이미지 파일 개수 자체를 줄이므로 리소스 ㅇ ㅛ청 개수를 줄일 수 있다.

3. 웹팩(webpack)사용

모듈 번들러 웹팩을 사용하여 css와 js파일을 번들링(하나의 파일로 묶는다.)해 리소스 요청을 줄일 수 있다.

4. Gzip 사용

• Gzip 사용하여 텍스트 기반의 리소스 압축
• 이미지나 pdf는 이미 압축된 파일 경우가 많아 사용하지 않는다.

5. js 압축

UglifyJS 사용하여 js 파일을 압축한다.

• 불필요한 공백이나 줄바꿈을 제거 -> 파일용량 감소

6. CDN

유저에게 많은 콘튼츠를 손실없이 빠르게 전달하는 서비스

• 대용량 콘텐츠 다운 또는 스트리밍에 사용
• 사용한 만큼 비용 지불

7. 캐싱

html,css,js,image 첫 요청시 내려 받은 뒤 특정 위치에 복사본을 저장하고 이후 동일한 URI의 리소스 요청이 왔을 때 이전에 저장해둔 파일을 사용하여 더빠르게 로딩하는데 사용

• 브라우저가 다운로드할 파일 개수가 줄어들므로 시간이 줄어든다.

Redux, Flux Pattern

Redux란?

리덕스는 자바스크립트 상태관리 라이브러리임

리덕스는 왜 생겨났을까?

리덕스가 나오기 전 프론트엔드쪽에서 데이터 흐름을 관리하는 방식은 MVC 패턴이었음
MVC 패턴은 Flux Pattern과 달리 양방향 데이터 흐름을 가지고 있음
즉, 모델이 변경되면 뷰가 변경되고, 사용자와의 인터렉션을 통해 뷰에서 변경이 일어나면 모델도 변경됨
이는 프로젝트가 점점 커지면 문제가 됨 -> 왜냐하면 데이터 흐름을 이해하기 어려워지기 때문에 버그가 발생하면 찾기 어려워짐(대표적인 예시 : 페북 - 알람 정보 업데이트가 제대로 안 되어 알람 표시 계속 유지)

MVC Pattern

• Model : 데이터 형식이나 구조를 관리함
  어플리케이션 정보, 데이터를 나타냄
  또한 이러한 데이터나 정보들의 가공을 하는 부분임

• View : 코드가 사용자에게 보여지는 부분을 담당함
  예를 들면 input, 체크박스 항목 등의 사용자 인터페이스 요소 등이 있음
  데이터를 받으면 화면에 표시해주는 역할만 함

• Controller : 변화하는 데이터 관리.
  Model(데이터), View(UI)를 잇는 역할을 함
  즉, 사용자가 데이터를 클릭하고 수정하는 것에 대한 이벤트들을 처리하는 부분임

때문에 2014년 페이스북에서 이에 대한 대안으로 Flux라는 새로운 아키텍처 패턴을 개발함

Flux Pattern이란?

MVC 패턴에서 발생한 문제를 개선하기 위해 나온 아키텍처 패턴
MVC 패턴과 다르게 단방향 데이터 흐름을 가지고 있음
또한 데이터가 단방향으로 흐르기 때문에 데이터를 추적하기 용이하고 흐름이 예측가능하다는 특징이 있음

Flux Pattern 동작 원리

2018년, Dan Abramov에 의해 React + flux 구조에 Reducer를 결합한 Redux가 등장하게 됨

Redux의 상태관리 순서

- 상태가 변경되어야하는 이벤트 발생 -> 변경될 상태에 대한 정보가 담긴 Action 객체 생성
- Dispatch 함수는 Action 객체를 Reducer 함수로 전달함
- Reducer 함수는 Action 객체의 값을 확인해 전역 상태 저장소 Store의 상태를 변경함
- 상태가 변하면 React는 리렌더링을 함

• Store: state가 관리되는 저장소

• Reducer : Dispatch에서 전달받은 Action 객체의 type 값에 따라 상태를 변경시키는 함수

• Action :

  • 어떤 액션을 취할 것인지 정의해 놓은 type이 필수로 지정된 객체
  • 보통 Action 객체를 생성하는 함수 Action Creator를 만들어 사용

• Dispatch : Action 객체를 Reducer로 전달해주는 함수

참고

cookie, web storage, session

쿠키, 웹스토리지(로컬 스토리지, 세션 스토리지), 세션

쿠키와 웹스토리지가 생긴 이유

HTTP 프로토콜은 무상태(stateless)라는 특성을 가짐
때문에 서버는 클라이언트에서 보내는 요청만으로는 클라이언트가 누구인지 구별할 수 없음
따라서 클라이언트의 상태를 서버가 아닌 클라이언트에 저장해두고 필요할 때마다 이를 사용해 사용자를 식별하거나 사용자가 이전에 수행한 작업 등을 기억하는 데 사용하기 위해서 생김

무상태
요청과 응답을 주고 받는 사이클이 끝나고 나면 서버와의 연결이 끊어져 상태 정보를 유지하지 않는 특성

Cookie

• 쿠키 하나당 최대 4KB까지 사용가능. 사이트 하나 당 약 20여개를 허용함(브라우저마다 다름).
• 쿠키 생성 단위는 브라우저(브라우저별로 생성된 쿠키는 서로 다르기 때문)
• 문자열만 저장 가능
• 서버가 response header에 set-cookie 에 내용을 넣어 전달하면 브라우저가 자체적으로 브라우저 안에 저장함
• 사용자가 따로 요청하지 않아도 매 요청시 브라우저가 request header에 쿠키를 넣어 자동으로 서버에 쿠키를 전송함
• expires(유효일자)나 max-age(만료 기간) 옵션이 지정되어 있지 않으면 브라우저가 닫힐 때 쿠키도 함께 삭제됨(세션쿠키)
• expires(유효일자)나 max-age(만료 기간) 옵션이 지정되어있으면 브라우저를 종료해도 쿠키가 삭제되지 않음
• secure : 이 옵션을 설정하면 HTTPS로 통신하는 경우에만 쿠키가 전송됨
• samesite : 요청이 외부 사이트에서 일어날 때, 브라우저가 쿠키를 보내지 못하도록 막아줌. csrf 공격을 막는데 유용함
• httpOnly : 이 옵션을 설정한 쿠키는 document.cookie로 쿠키 정보를 읽을 수 없게 됨 -> 크로스사이트 스크립팅(xss) 공격 방지
• 사용목적 : 세션관리(서버에 저장해야할 로그인, 장바구니, 게임 점수 등의 관리), 개인화(사용자 테마, 선호 등), 트래킹
• 사용 예시 : 아이디 저장, 로그인 상태 유지, 일주인간 다시보지 않기창, 최근 검색 상품광고에서 추천, 장바구니

Web Storage(local storage, session storage)

web storage가 생긴 이유

HTML5부터 클라이언트에 데이터를 저장할 수 있게 추가된 저장소
기존에 사용되던 쿠키는 용량제한이 있어 많은 양의 정보를 저장하거나 처리하는데 제한적이었음
또한 쿠키는 서버의 모든 요청에서 HTTP 헤더에 포함되므로 트래픽을 증가시키고 서버의 부담을 줌
이러한 쿠키의 단점을 보완하여 나온 게 웹스토리지임

• Local Storage

  • 브라우저나 os를 종료해도 계속 브라우저에 저장되어 있음
  • 오리진이 같은 경우 로컬스토리지에 저장된 데이터는 모든 탭과 창에서 공유됨
  • 사용 예시 : 지속적으로 필요한 데이터 저장(자동 로그인)

• Session Storage

  • 현재 떠 있는 탭 내에서만 유지됨(각 탭마다 독립적으로 유지됨)
  • 예외 : 한 탭 내에서 여러 개의 iframe을 사용하는 경우
    ex: 한 탭에서 여러 개의 쇼핑 사이트를 iframe으로 열었음 -> 모든 iframe은 동일한 세션 스토리지 공유함 -> 왜냐면 같은 탭내에 있는 iframe들은 동일한 오리진에서 왔다고 보기 때문임
  • 새로고침을 해도 사라지지 않지만 윈도우나 브라우저 탭을 닫을 경우 제거됨
  • 사용 예시 : 일시적으로 필요한 데이터 저장(일회성 로그인 정보, 입력폼 저장 등)

브라우저에서 탭 이동 혹은 탭 종료 시에는 세션 스토리지에 어떤 영향을 끼치나요?

탭 이동 시 : 세션스토리지는 동일한 탭 내에서 페이지를 이동하거나 새로고침을 하는 경우에는 그대로 유지됨
탭 종료 시 : 브라우저에서 탭을 종료하는 경우 해당 탭에 연결된 세션스토리지의 데이터는 삭제됨
따라서 세션스토리지에는 일시적인 정보를 저장하는 것이 적합함

Session

사용자가 웹 브라우저를 통해 웹 서버에 접속한 시점으로부터 웹 브라우저를 종료하여 연결을 끝내는 시점까지 같은 사용자로부터 오는 일련의 요청을 하나의 상태로 보고 그 상태를 일정하게 유지하는 기술

즉, 클라이언트 별로 각각의 상태 정보를 서버에 저장하는 기술임

• 서버에서 클라이언트를 구분하기 위해 각 클라이언트 별로 세션ID를 부여하고, 웹 브라우저가 서버에 접속해 브라우저를 종료할 때까지 세션을 유지함
• 접속 시간에 제한을 두어 일정 시간 응답이 없다면 정보가 유지되지 않게 설정가능
• 사용자가 많아질 수록 서버 메모리를 많이 차지하게 됨 -> 서버에 부하가 생길 수 있음
• 쿠키에 비해 보안적인 면에서 좀더 나음(쿠키는 중간에 정보를 탈취할 수 있으므로)
• 브라우저 종료 시 만료기한에 상관없이 종료됨

세션 동작방식

(클라이언트(브라우저)가 서버에 로그인 요청한다고 가정)
서버는 클라이언트의 요청을 받고 클라이언트의 정보를 담은 세션 생성함
그 후 세션ID를 담은 쿠키 생성 -> HTTP 헤더에 Set-Cookie 옵션을 통해 쿠키를 포함한 응답을 보냄
-> 브라우저는 해당 쿠키를 쿠키에 저장함

(클라이언트가 로그인 후 마이페이지로 이동함�)
클라이언트는 쿠키를 꺼내 HTTP 요청에 쿠키를 담아 전송함 -> 서버는 HTTP 요청에 같이 담겨온 쿠키를 읽어 쿠키 안의 세션 ID를 확인해 세션 정보 조회 -> 세션 정보에 있는 사용자 id 등의 식별 정보를 사용해 사용자의 데이터를 데이터베이스에서 조회함 -> 해당 데이터를 클라이언트에게 응답으로 보냄

useCallback, useMemo, React.memo

React는 컴포넌트를 렌더링 한 뒤 이전 렌더된 결과와 비교하여 Dom 업데이트를 결정한다.
재렌더가 필요없는 컴포넌트 의 렌더를 방지하여 업데이트의 속도를 높일수 있다. (=최적화)

최적화 하는 이유

쓸데없는 렌더링을 방지 하기 위해서 이다.
쓸모없는 렌더링이 메모리를 사용해 속도를 느리게 만들고 사용자 경험에도 영향을 미치게 된다.

• 리액트 최적화 = 렌더링을 최적화 하는 것이다.

렌더링 이란?

1. props가 변경될때
2. state가 변경될때
3. forceUpdate()를 실행 했을 때
4. 부모 컴포넌트가 렌더링 되었을때 자식 컴포넌트 렌더링 된다.

최적화 방법

React.memo, useCallback, useMemo는 memoization 개념을 활용한다.

memoization : 한번 계산한 것을 메모리에 저장해 뒀다가 같으면 그대로 쓴다.

React.memo

컴포넌트의 결과값을 기억한다.
고차 컴포넌트 이다. (Highter Order Component)

고차컴포넌트 : 컴포넌트를 받아 새 컴포넌트를 반환하는 함수

React.memo는 컴포넌트를 받아 자신의 props가 바뀔때만 리렌더링 되는 고차 컴포넌트를 반환하는 함수이다.

컴포넌트가 동일한 props로 동일한 결과를 렌더링 하면 React.memo는 마지막으로 렌더링 된 결과를 재사용 하는 것이다.

const MyComponent = React.memo(function MyComponent(props) {
  /* props를 사용하여 렌더링 */
})



function MyComponent(props) {
  /* props를 사용하여 렌더링 */
}
function areEqual(prevProps, nextProps) {
  /*
  nextProps가 prevProps와 동일한 값을 가지면 true를 반환하고, 그렇지 않다면 false를 반환
  */
}
export default React.memo(MyComponent, areEqual);

자식 컴포넌트에 React.memo를 적용해 최적화 한다.
그러면 부모 컴포넌트 state가 바뀌어도 자식컴포넌트가 렌더링이 되지 않는다.

부모컴포넌트가 리렌더링 될때 해당 컴포넌트의 객체(함수도 객체)는 재생성된다.
객체는 참조형 타입이므로 주소값을 통해 비교를 하게된다.

useCallback

함수를 기억하고 재사용한다.
useCallback을 사용하면 콜백함수를 메모리에 저장해두고 재사용 할 수 있다.

const memoizedCallback = useCallback(()=>{
	doSomething(a,b)
},[a,b])
const memoizedCallback = useCallback(fn, deps)

deps(의존성배열)이 변경되었을때만 함수를 재생성하고 그렇지 않은 경우 동일한 함수를 리턴하여 사용한다.

의존성 배열이 없을 경우 렌더링 마다 리렌더링이 되므로 빈배열을 넣으면 된다.

useMemo

값을 기억한다.
Component는 state가 변하면 리렌더링을 한다. 값이 변경되지 않았는데 리렌더링이 되는 것은 불필요하기 때문에 useMemo를 통해 최적화 할 수 있다.

const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b]);

SSR, CSR, SSG

SSR, CSR, SSG, 모두 다 웹페이지가 렌더링하는 방식들임
크게 CSR(Client Side Rendering)과 SSR(Server Side Rendering)으로 나뉨. 이외에도 SSG와 ISR라는 방법도 있음
이걸 얘기하기 전에 연관되는 개념으로 SPA와 MPA에 알아야 함

// 예시
<html>
<head>
  <title>Single Page Application</title>
  <link rel="stylesheet" href="app.css" type="text/css">
</head>
<body>
  <div id="app"></div>
  <script src="app.js"></script>
</body>
</html>

CSR(Client Side Rendering)

React, Vue, Angular 등이 CSR을 사용함

• 클라이언트(브라우저)에서 웹페이지 렌더링하는 것을 말함
• 모든 로직, 데이터 가져오기, 템플릿, 라우팅은 서버가 아니라 클라이언트에서 처리됨
• 자바스크립트 번들의 크기의 영향을 많이 받기 때문에 코드분할 (code splitting)을 고려해야함

동작 방식

1. 클라이언트가 사이트 접속 -> 특정 페이지를 요청함
2. 서버에서는 빈 HTML 문서(index.html)를 클라이언트에 보냄
   (이 때 아무 내용이 없기 때문에 클라이언트 측에서는 초기에 빈 화면만 보일 것임)
3. index.html에 링크된 자바스크립트 파일을 요청한 후 다운로드 받고 실행함.
4. 받아온 것들을 합쳐 동적 HTML을 생성해서 사용자들이 화면을 볼 수 있고 인터렉션도 가능함. TTV(time to view)와 TTI(time to interact)가 동시에 일어남

장점

• 후속 페이지 로드 시간이 더 빠름
  이미 모든 파일을 사전에 로드되었기 때문에 csr의 로드시간이 줄어듦

• 페이지 이동에 걸리는 시간이 짧음
  페이지 최초 접근 시에 페이지 렌더링에 필요한 정적 리소스와 자바스크립트 파일을 모두 다운로드하기 때문에 페이지를 이동할 시 필요한 부분만 추가로 서버에 요청하면 되므로 페이지 이동에 걸리는 시간이 짧음

단점

• 초기 페이지 로딩 시간이 ssr에 비해 느림
  브라우저에서 렌더링에 필요한 리소스와 자바스크립트 파일을 다운로드 한 후 화면을 그리는 데 걸리는 시간이 길기 때문에 오래 걸리게 됨.
  특히 자바스크립트 파일의 용량이 클 수록 다운로드에 많은 시간이 소요되므로 정적 리소스 및 용량이 적은 라이브러리를 사용하고 자바스크립트 파일을 여러 개의 파일로 분할해 번들 파일 용량을 줄이는 것이 좋음

• 데이터를 받아올 떄까지 빈 화면(혹은 로딩) 표출
  CSR 방식은 번들 자바스크립트 실행이 완료된 후 API응답을 받아오기 전까지는 빈 화면(혹은 별도로 설정한 로딩화면 등)이 표출됨
  API에서 데이터를 받아온 후, 화면 리렌더링이 완료되면 화면에서 인터렉션이 가능함

• SEO 비친화적
  검색 엔진이 해당 페이지에 처음 방문했을 때 빈 페이지(index.html이 비어있음)이기 때문에 어떤 페이지인지 이해할 수 없기 때문

SSR(Server Side Rendering)

Next,js, PHP, ASP등이 SSR을 사용함

동작 방식

1. 클라이언트가 사이트에 접속 -> 특정 페이지 요청
2. 서버에서는 해당 페이지에 필요한 데이터를 포함해서 이미 렌더링된 HTML 파일을 클라이언트에게 전달함
3. 클라이언트는 HTML파일을 받아옴. 이미 렌더링된 페이지이기 때문에 사용자는 페이지를 볼 수 있지만(TTV) 아직 클릭 등의 인터렉션은 할 수 없음(자바스크립트 코드를 받아오지 않아서)
4. 클라이언트에서 자바스크립트 파일을 서버에 요청하고 받아와 실행함
5. 페이지 인터렉션이 가능해짐(TTI)
   -> TTV와 TTI 사이의 공백이 있음

장점

1. 최초 로딩 시간이 짧음
   요청한 페이지에 필요한 리소스만 다운로드해 페이지를 생성해 렌더링에 필요한 시간이 짧음

2. SEO에 유리함
   서버에서 페이지를 생성하므로 완성된 HTML 문서를 수집할 수 있음 -> 검색엔진 최적화에 유리함

단점

1. 자바스크립트 실행이 완료될 때까지 인터렉션 불가능함
   SSR방식은 사용자가 페이지를 빨리 볼 수 있지만 자바스크립트 실행이 완료될 때 까지는 클릭 등의 인터렉션이 불가능함
   만약 인터렉션 가능 시점 이전에 버튼 클릭 등의 작업이 발생했다면 인터렉션 가능 시점까지 해당 동작의 수행은 보류됨

2. 깜빡임 이슈
   사용자가 페이지를 이동하거나 무언가를 클릭하면 전체 웹페이지를 다시 서버에서 받아오기 때문에 깜빡임 이슈가 발생함 -> 사용자 경험에 좋지 않음

3. 서버 과부하
   사용자가 많을 수록 인터렉션이 많이 일어나고 이에 필요한 데이터를 서버에 요청해 받아와서 HTML을 만들기 때문에 서버에 과부하가 올 수 있음

SSG(Static Site Generation)

• 프로젝트 빌드 시에 HTML이 생성되고 매 요청마다 HTML을 재사용함
• 미리 만들어 둔 페이지를 클라이언트에게 제공하므로 렌더링 속도가 매우 빠름
• SSR과 마찬가지로 완성된 페이지를 클라이언트에게 주므로 SEO에 유리함
• 주로 마케팅 페이지, 블로그와 같이 정적으로 생성된 정보를 요청마다 동일한 정보로 반환하는 경우에 사용함

ISR(Incremental Static Regeneration)

• 이미 생성된 웹에 정적 페이지를 새롭게 추가하거나 업데이트 할 수 있는 기능
• SSG는 빌드 시에 페이지를 생성하기 때문에 데이터가 변경되면 다시 빌드를 해야하지만 ISR은 빌드한 이후에도 정적페이지를 생성하거나 업데이트할 수있음
• ex: Next.js 13 버전 이하 : getStaticProps , getServersideProps, 13 이상 버전 : fetch와 cache 사용

const res = await fetch(
    `https://api.themoviedb.org/3/${
      genre === 'fetchTopRated' ? 'movie/top_rated' : 'trending/all/week'
    }?api_key=${API_KEY}&language=en-US&page=1`,
    { next: { revalidate: 10000 } },
  );
  
  const data = await res.json();
  const results = data.results;

웹사이트 성능 최적화 방법

웹사이트 성능 최적화란?

사용자가 웹사이트를 빠르고 효율적으로 이용할 수 있도록 사이트의 로딩 속도를 향상시키고, 자원 사용을 최소화하는 작업을 의미함
웹사이트 성능 최적화를 진행하면 사이트에 대한 UX(사용자 경험)을 개선하고 SEO에도 영향을 줌

이런 서비스적 관점까지 고려해 웹 사이트 성능 최적화를 고려해야함

Google의 Core Web Vital

그러면 웹사이트의 성능을 어떻게 측정할 수 있을까?
이에 관한 측정 지표로 구글의 core web vitals를 사용함

1. LCP(최초 콘텐츠 렌더링 시간, Largest Contentful Paint)

• LCP는 사용자에게 가장 큰 콘텐츠를 보여주는 데 걸리는 시간을 뜻함
• 자세하게 말하자면 사용자가 URL을 요청한 시점부터 가장 큰 시각 콘텐츠 요소(ex: 이미지, 비디오, 큰 블록 수준의 텍스트 등)를 렌더링하는 데 걸린 시간을 말함
• 이 측정항목은 방문자가 URL이 실제로 로드되는 것을 확인하는 속도를 표시하므로 중요함
• 페이지가 로드되기 시작한 지 첫 2.5초 안에 LCP가 발생해야 이상적임

2. CLS(레이아웃 변경 횟수, Cumulative Layout Shift)

• 웹페이지의 시각적 안정성을 측정함
• 사용자가 페이지에 방문한 후 상주한 시간을 모두 측정하고, 해당 시간 동안 페이지 내부에서 발생하는 레이아웃 및 개별적인 레이아웃 요소들의 변화가 몇 번이나 변경되었는지 측정함
• 숫자가 클수록 레이아웃이 많이 변경되었음을 나타냄
• 팝업과 같이 가독성을 해치는 요소가 얼마나 자주 표시되는지 측정하기 위해서 해당 항목이 있고, 팝업 등이 많은 뉴스 사이트의 경우 CLS값이 높게 평가됨
• CLS 점수가 0.1 미만이 되어야 좋은 사용자 환경을 제공한다고 할 수 있음

3. FID(첫 입력 지연, First Input Delay) -> INP(페인트에 대한 상호작용, interaction to next paint)

• 사용자가 렌더링이 모두 끝난 웹에서 사용자가 웹 페이지와 처음 상호작용했을 때부터(어떤 요소를 클릭하거나 링크를 클릭하는 등) 브라우저가 상호작용에 반응할 때까지의 시간을 말함
• ex: 네이버에 접근 -> 로그인 버튼 누름 -> 로그인 페이지가 모두 로딩될 때까지 경과하는 시간 측정
• 사용자와 상호작용이 많이 일어나는 페이지에서 중요함
• FID가 100ms 미만이 되어야 이상적임

그런데!!! 구글에서 2023년 5월 10일 업데이트 한 내용에 따르면 2024년 3월부터 FID가 INP로 대체 된다고 함

이유 : 처음 로드될 때의 시간보다 페이지가 로드된 후 사용자들의 이용 시간 중 90%가 사용됨. 따라서 사용자가 웹과 상호작용을 시작한 시점부터 다음 프레임이 그려질 떄까지의 시간을 최대한 짧게 하는 것이 중요해짐. 참고

FID는 사용자가 페이지와 처음 상호작용할 때의 시간만 측정함. 하지만 처음 상호작용한 시간만 가지고는 페이지 전체의 모든 상호작용하는 시간을 대표할 수 없음.
따라서 모든 상호작용을 고려해 페이지 전체에서 가장 느린 상호작용과, 상호작용 시점부터 이벤트 핸들러를 거쳐 브라우저가 다음 프레임을 그릴 수 있을 때까지의 전체 시간을 측정하는 INP로 대체되게 되었음

INP(페인트에 대한 상호작용, interaction to next paint)

INP는 사용자가 페이지를 방문하는 동안 발생하는 모든 클릭, 탭, 키보드 등의 상호작용의 지연 시간(가장 느린 인터렉션 시간 및 가장 빠른 인터렉션 시간 제외 나머지의 평균)을 관찰해 사용자자와 웹의 상호작용에 대한 페이지의 전반적인 응답성을 평가하는 항목임.

• INP가 200ms 미만 : 페이지 응답성이 좋음
• INP가 200ms 초과 ~ 500ms 미만 또는 500ms : 페이지 응답성이 개선되어야 함
• INP가 500ms 초과 : 페이지 응답성이 좋지 않음

측정 지표를 토대로 웹 사이트 성능 개선하기

1. LCP

1. LCP 리소스가 HTML에서 빨리 찾아져야 함
   ex: background-image를 css에 넣으면 css가 로드될 때까지 브라우저는 LCP 리소스(ex: 이미지 등)를 모르게 됨 -> HTML의 img 태그 등으로 추가해서 빨리 LCP 리소스가 로드될 수 있게 하기

2. HTML에서 LCP 리소스를 찾았으면 우선해서 다운로드할 수 있도록 하기

3. (돈이 많이 들지만 확실하게 개선되는 방법) CDN 사용

위의 것들을 하기 위해 실제로 할 수 있는 것들

• 요소에 src나 srcset 속성을 사용해 HTML만 다운로드 받아도 HTML에 있는 이미지가 사이트의 첫 번째 화면 렌더링에 필요하다는 것을 알 수 있게됨
• SSR을 사용해서 CSR에서의 작업을 최소화하기
  브라우저에서 바로 화면을 그릴 수 있게 서버사이드에서 HTML 작업해서 보내면 LCP에 도움이 됨
• 외부 리소스를 참조해서 사용하는 경우인데, 만약 이 외부 리소스를 사용해서 그려야하는 영역이 LCP라면 HTML 부분에 <Link rel="preload"> 와 같이 rel=preload라는 속성을 지정해서 빨리 리소스를 다운로드 받으라고 알려줄 수 있음
• LCP 이미지로 사용될 태그에 fetchpriority='high' 속성을 추가해 브라우저가 우선적으로 다운로드할 수 있게 함
• 사용자에게 바로 보여야할 이미지가 아닌 경우(ex: 스크롤해야 보이는 아래쪽에 위치한 이미지들)에 속성을 추가해 브라우저가 당장 다운로드해야할 리소스가 줄어들어 LCP에 도움이 됨

2. CLS

• 로드될 컨텐츠의 크기를 명확하게 정해주기
  width, height 같은 속성을 이용해서 할 수 있음

반응형 같은 경우에는 정확한 이미지 높이를 알기 어려우니까 aspect-ratio라는 속성을 이용해 비율로 이미지 높이를 설정해주면 좋음

컨텐츠가 너무 동적이어서 높이를 잘 모르겠다 싶으면(ex: 텍스트 길이에 따라서 달라지는 배너 등) min-height라도 정해줘서 조금은 영역이 밀리더라도 최소한의 높이라도 브라우저가 알 수 있게해서 준비할 수 있게하기

• 처음 화면이 렌더링될 때 animation, transition 등의 레이아웃을 건드는 css는 지양하기
• bfcache가 되는지 확인하기
  뒤로가기나 앞으로 가기를 할 때 브라우저들이 페이지들의 정보를 캐싱해놓음 -> 네트워크 요청 다시 x
  기본적으로 브라우저에서 bfcache가 되지만 가끔가다가 막아놓는 곳도 있으니 체크하기

3. FID

• 오래 걸리는 작업을 여러 개로 나누기(왜냐하면 자바스크립트엔진은 싱글스레드인데 오래 실행되는 작업이 있다면 사용자 입력을 처리하는데 지연이 생길 수 있기 때문에)
• code splitting을 통해 통째로 파일을 받아오는 것이 아니라 필요한 부분만 다운로드 받을 수 있게 함
• 불필요한 자바스크립트 없애기
  그런데 무엇이 필요한 건지 아닌지 알기 어려워서 지속적으로 관찰하면서 관리해야함
  (데브툴에서 볼 수 있긴한데 사용자가 사이트를 사용할 수록 많아질수록 달라짐)
• DOM 사이즈를 작게 유지하기
• 트래킹들을 위한 분석툴을 많이 사용할수록 느려짐 -> 지속적으로 관찰해서 더이상 사용하지 않는 분석툴에서 제공하는 태그들을 지우기�

useCallback, useMemo, React.memo

useCallBack, useMemo, React.memo 차이점

세 개 다 메모이제이션을 통해 불필요한 렌더링이 발생하지 않게 최적화할 수 있게 만들어주는 훅임
그러면 메모이제이션은 무엇을 뜻할까?

메모이제이션
기존에 수행한 연산의 결과 값을 메모리에 저장해두었다가 동일한 입력이 들어오면 재활용하는 프로그래밍 기법을 의미함
따라서 이 훅들을 적절하게 사용하면 중복된 연산을 피할 수 있기 때문에 성능 최적화에 도움을 줄 수 있지만 너무 많이 사용하면 메모리에 부담을 줌

• useCallback : 함수를 캐싱
• useMemo : 값 자체를 캐싱
• React.memo : 컴포넌트를 캐싱
  부모 컴포넌트가 리렌더링될 때 자식컴포넌트는 리렌더링 됨
  그런데 만약 자식 컴포넌트에서는 바뀐 것이 없다면 리렌더링이 된다면 낭비일 것임
  따라서 react.memo를 사용해 컴포넌트를 메모리에 저장해두고 필요할 때 갖다가 씀
  부모의 state 변경으로 인해 props에 변경이 일어나지 않는 한 컴포넌트는 리렌더링이 일어나지 않음(컴포넌트 메모이제이션)

ShouldComponentUpdate

클래스형 컴포넌트에 있던 메소드로 컴포넌트를 리렌더링할지 말지 결정하는 메소드임
이게 함수형 컴포넌트로 넘어오면서 useCallback, useMemo, React.memo로 구현할 수 있게 되었음

실행 컨텍스트

실행 컨텍스트란?

• 실행할 코드에 제공할 환경 정보를 모아놓은 객체를 말함.
• 동일한 환경에 있는 코드들을 실행할 때 필요한 환경 정보들을 모아 컨텍스트를 구성하고, 이를 콜스택에 쌓아 올렸다가 가장 위에 있는 컨텍스트와 관련된 코드를 실행하는 식으로 전체 코드의 환경과 순서를 보장함

var a = 1;

function outer() {
    function inner() {
        console.log(a) // undefined
        var a = 3;
    }
    inner()
    console.log(a) // 1

}

outer()
console.log(1)

실행 컨텍스트가 활성화될 때 자바스크립트 엔진은 해당 컨텍스트에 관련된 코드들을 실행하는데 필요한 환경 정보를 수집해서 실행 컨텍스트 객체에 저장함. 이 객체는 자바스크립트 엔진이 활용할 목적으로 생성할 뿐 개발자가 확인할 수 없음.

실행 컨텍스트에 담기는 정보들은 다음과 같음

• variableEnvironment : 현재 컨텍스트 내의 식별자들에 대한 정보 + 외부 환경 정보, 선언 시점의 LexicalEnvironment의 스냅샷으로, 변경 사항은 반영되지 않음
• LexicalEnvironment : 처음에는 variableEnvironment와 같지만 변경 사항이 실시간으로 반영됨
• ThisBinding : this 식별자가 바라봐야 할 대상 객체

VariableEnvironment과 LexicalEnvironment의 차이점

• VariableEnvironment과 LexicalEnvironment는 둘 다 environmentRecord, outerEnvironmentReference로 구성되어 있음

environmentRecord(=Record)

• 현재 컨텍스트와 관련된 코드의 식별자 정보를 기록함
• 기록하는 정보 : 함수에 지정된 매개변수 식별자, 함수자체, var로 선언된 변수 식별자 등
• 관련 개념: #1 중 호이스팅
  자바스크립트 엔진이 현재 컨텍스트와 관련된 식별자 정보를 기록하는데, 호이스팅은변수 정보 정보 수집과정을 이해하기 쉽게 설명한 가상개념을 의미함

outerEnvironmentReference(=outer)
outer는 현재 호출된 함수가 선언될 당시의 LexicalEnvironment를 참조

var a = 1;
var outer = function() {
	var inner = function() {
		console.log(a); // undefined
		var a = 3;
	};
	inner();
	console.log(a); // 1
};
outer();
console.log(a); // 1

| inner 컨텍스트 |
| outer 컨텍스트 |
| 전역 컨텍스트 |
ㅡㅡㅡㅡㅡㅡㅡㅡ

차이점으로는 VariableEnvironment는 실행 컨텍스트가 생성될 때의 초기 스냅샷을 가지고 있음. 이후에 VariableEnvironment의 environmentRecord는 변수 등의 값이 바뀌어도 반영되지 않음

LexicalEnvironment는 실시간으로 변경된 사항을 반영함. 즉, LexicalEnvironment의 environmentRecord는 변수 등의 값이 바뀌면 실시간으로 반영함

Process, Thread

Process

Program

• 어떤 작업을 위해 실행할 수 있는 파일
  ex: kakaotalk.exe 등

Process

• 운영 체제 위에서 실행 중이거나 실행 대기 중인 프로그램을 말함

즉, 메모리에 올라와 실행되고 있는 프로그램의 인스턴스임
좀 더 자세히 말하자면 하드디스크에 있는 프로그램을 실행하면 실행을 위해 메모리 할당이 일어나고, 할당된 메모리 공간으로 프로그램이 올라감. 이 순간부터 프로세스라고 부름

프로세스는 운영체제로부터 각각의 독립된 메모리 영역(code, data, stack, heap)을 할당 받음

• 코드 영역 : 프로그래머가 작성한 프로그램이 저장되는 영역.
  (실행할 프로그램의 코드나 명령어들)
  CPU는 코드 영역에 저장된 명령어들을 하나씩 처리함.
• 데이터 영역 : 코드에서 선언한 변수나 파일들의 각종 데이터들이 저장되는 영역.
  프로그램이 실행되면서 할당되고 종료되면서 소멸함
• 스택 영역 : 함수 안에서 선언된 지역변수, 매개 변수, 리턴 값 등이 저장됨. 함수 호출 시 기록되고 종료되면 제거됨
• 힙 영역 : 동적으로 할당되는 데이터를 위해 존재함

프로세스는 최소 1개 이상의 스레드를 가지고 있으며, 각 프로세스는 별도의 주소 공간에서 실행되며 기본적으로 다른 프로세스의 자원에 접근할 수 없음.
어떤 한 프로세스가 다른 프로세스에 접근하려면 프로세스 간 통신(IPC(inter process communication))를 해야함
ex: 소켓이나 파일, 파이프 등을 이용한 통신 방법

프로세스 내에는 최소 한 개의 스레드를 가지고 스레드 단위로 스케줄링을 함

=> 우리가 음악을 들으면서 메일을 보내고 카톡 메시지가 오는 등의 여러 프로세스가 동시에 실행되는 것처럼 보이지만 CPU는 한 번에 하나의 명령밖에 처리할 수 없음. 즉 동시에 처리되는 것처럼 보여도 사실은 프로세스들을 빠르게 번갈아가면서 실행하고 관리하는 것임

�Thread

하나의 프로세스 내에서 동시에 진행되는 작업 갈래, 흐름의 단위를 말함

스레드는 프로세스 내에서 필요한 스택만 할당받고 코드, 힙, 데이터 영역은 각 스레드가 공유함(같은 프로세스 내에 있는 스레드끼리 자원(코드, 데이터, 힙)을 공유하며 실행됨)

CPU

컴퓨터가 사용자의 명령에 대한 작업을 수행하는 처리장치

cpu는 한정된 자원을 가지고 있어 최대한의 성능을 이끌어내기 위해서는 cpu를 적절하고 효율적으로 사용해야함
즉, OS는 실행대기 중인 프로그램(프로세스)들에게 CPU 자원 배정을 적절히해 시스템의 성능을 끌어올릴 수 있음

Process와 Thread의 차이점

운영체제는 프로세스마다 독립된 메모리 영역을 code,data,stack,heap의 형식으로 할당함.
각각 독립된 메모리 영역을 할당하기 때문에 프로세스는 다른 프로세스의 변수나 자료에 접근할 수 없음

이와 달리 스레드는 메모리를 서로 공유할 수 있음. 즉, 프로세스가 할당받은 메모리 영역 내에서 stack 형식으로 할당된 메모리 영역은 따로 할당받고 나머지 영역(code, heap, data) 을 공유함. 따라서 각각의 스레드는 별도의 스택을 가지고 있지만 code, heap, data 부분은 서로 공유해 읽고 쓸 수 있게 됨

협업에서 기억에 가장 남는 상황, 협업에서 어려웠던 경험(어려웠던 이유, 어떻게 해결했는지)

백엔드와 처음 외주 프로젝트를 협업 하게 되었는데 백엔드에서 API가 다 나오지 않았을때
언제까지 기다려야 하고 작업을 언제 할수 있을지 그 기다림이 힘들었다.
그래서 해결 했던 방법으로는 내가 스스로 목데이터를 만들어서 프론트에서 실행해보고 백엔드와 소통하며 API를 수정하여
유지보수관련하여 좀더 편리할 수 있도록 했던 경험이 있습니다.

“팀에서 1인분을 한다”고 할 때, 1인분은 어떤걸 의미하는걸까요?

내가 맡은 역할에 최선을 다하는 것 입니다.
내배캠부트캠프에서 4번정도 팀을 해 가면서 느낀점은 아무리 몰라도 할줄 아는게 없어도
내가 한부분에 책임을 다하고 최선을 다하는 것이 1인분이다 라는 생각을 했습니다.
잘하진 못해도 하기위해서 구글링을 하고 유튜브를 보고 할 수 있는 최선을 다해 하는 것이 팀을 위한 일이라고 생각합니다.

this, closure

this

this란?

자바스크립트에서의 this는 함수 호출 방식에 따라서 결정됨

함수의 호출방식

• 메소드로서의 호출
  메소드로 호출 시(ex: obj1.addNums) 자신을 호출한 대상이 this

• 함수로서의 호출
  함수를 독립적으로 호출 시 호출주체를 알 수 없으므로 this 지정 x -> 때문에 this는 전역 객체를 가리킴
  또한 메소드의 내부라고 해도 함수로서 호출하면 this는 전역객체를 의미함

• 콜백함수로 호출될 때 그 함수 내부에서의 this
  콜백함수도 함수이기 때문에 this는 전역객체를 참조하지만, 콜백함수를 넘겨받은 함수에서 별도로 this를 지정한 경우 예외적으로 그 대상을 참조함

• 생성자 함수 호출
  this는 인스턴스를 가리킴

• apply, call, bind 호출
  apply, call, bind는 원하는 this를 바인딩할 수 있는 메소드임

1. apply

var func = function (a, b, c) {
console.log(this, a, b, c);
};

func.apply({ x: 1 }, [4, 5, 6]); // { x: 1 } 4 5 6

var obj = {
a: 1,
method: function (x, y) {
console.log(this.a, x, y);
}
};

obj.method.apply({ a: 4 }, [5, 6]); // 4 5 6

2. call

var func = function(a,b,c) {
   console.log(this, a,b,c,)
}

func(1,2,3) // window{…} 1 2 3

func.call({x: 1}, 2,3,4) // {x:1} 2 3 4

3. bind
   call이나 apply랑 비슷해보이지만 call과 다르게 즉시 호출하지 않고 넘겨받은 this 및 인수들을 바탕으로 새로운 함수를 리턴하는 메소드

var func = function (a,b,c,d) {
  console.log(this, a,b,c,d)
}
func(1,2,3,4) // this는 window 객체 가리킴

var bindFunc = func.bind({x:1})
bindFunc(5,6,7,8) // {x:1}, 5, 6, 7, 8

// 부분 적용함수 
var bindFunc2 = func.bind({x:1, 4, 5}) 
bindFunc2(6,7) // {x:1}, 4, 5, 6, 7

Closure

Closure란?

외부함수의 생명주기가 이미 종료되었음에도 내부함수가 외부 함수의 컨텍스트에 접근할 수 있는 것을 말함 → 이미 종료된 외부함수의 변수 등을 여전의 참조(외부함수의 렉시컬 환경을 여전히 참조)할 수 있음

어떻게 접근할 수 있냐면 가비지 컬렉터가 보고 외부함수의 렉시컬환경을 아직 참조하는 곳이 있어 냅두기 때문임

const x = 1;

function outer() {
  const x = 10;
  const inner = function () {
    console.log(x); // 10
  };
  return inner;
}

const innerFunc = outer();
innerFunc();

그러면 클로저는 왜 사용하는 걸까?

1. 상태유지
   현재 상태를 기억하고 변경된 최신 상태를 유지하는 것

function makeCounter() {
  let count = 0;
  
  return function() {
    return count++;
  }
}

let counter1 = makeCounter();

console.log(counter1());  // 0
console.log(counter1());  // 1

2. 전역 변수 사용 억제
   자신이 생성되었을 때의 lexical 환경을 기억하기 때문

let count = 0;

function makeCounter() {
  return function () {
    return ++count;
  };
}

let counter1 = makeCounter();

console.log(counter1(), "before"); // 0
count = 1000;
console.log(counter1(), "after"); // 1001

3. 정보의 은닉

// 생성자 함수
function Person(name, age) {
  this.name = name; //public
  let _age = age; //private

  this.sayHi = function () {
    console.log(`Hi! My name is ${this.name}. I am ${_age}.`);
  };
}

const me = new Person("Choi", 33);
me.sayHi(); // Hi!, My name is Choi. I am 33.
console.log(me.name); // Choi
console.log(me._age); // undefined

const you = new Person("Lee", 30);
you.sayHi(); // Hi! My name is Lee. I am 30.
console.log(you.name); // Lee
console.log(you.age); // undefined

#주소창에 naver.com을 치면 일어 나는일

IP 주소

• IP 주소란 많은 컴퓨터들이 인터넷 상에서 서로를 인식하기 위해 지정받은 식별용 번호 이다.
• 현재는 IPv4버전(32비트)로 구성되어 있으며, 127.0.0.1 같은 주소를 말한다.
• 시간이 지날수록 IPv4 주소의 부족으로 IPv6가 생겼는데, 128비트로 구성되어 있기 때문에 IP주소가 부족하지 않다는 특징이 있다.
• 단점 : IP 주소는 12자리의 숫자로 되어 있기 때문에 사람이 외우기 힘들다

도메인 네임(Domain Name)

• IP주소의 단점을 보완하여 12자리의 숫자를 문자로 표현하여 주소로 표현한 것이 도메인 네임이다.
• 'naver.com' 처럼 몇개의 문자들과 .의 조합으로 구성된다.
• 도메인 네임은 사람의 편의성을 위해 만든 주소이므로 컴퓨터가 이해할 수 있는 IP 주소로 변환하는 작업이 필요하다.

DNS(Domian Name System)

• 미리 도메인 네임과 함께 해당하는 IP 주소값을 한쌍으로 저장하고 있는 데이터 베이스
• 도메인 네임으로 입력하면 DNS를 이용해 컴퓨터는 IP주소를 받아 찾아 갈 수 있다.

작동방식

1. 사용자가 브라우저에 도메인 네임(www.naver.com)을 입력산다.
2. 사용자가 입려한 URL 주소 중에서 도메인 네임(Domain Name)부분을 DNS 서버에 검색하고 DNS 서버에서 해당 도메인 네임에 해당하는 IP주소를 찾아 사용자가 입력한 URL 정보와 함께 전달한다.
3. 페이지 URL 정보와 전달받은 IP 주소는 HTTP 프로토콜을 사용하여 HTTP 요청 메시지를 생성하고 이렇게 생성된 HTTP 요청 메시니는 TCP 프로토콜을 사용하여 인터넷을 거쳐 해당 IP주소의 컴퓨터로 전송된다.
4. 이렇게 도착한 HTTP 요청 메시지는 HTTP 프로토콜을 사용하여 웹 페이지 URL 정보로 변환되어 웹 페이지 URL 정보에 해당하는 데이터를 검색한다.
5. 검색된 웹페이지 데이터느 또 다시 HTTP프로토콜을 사용하여 HTTP 응답 메시지를 생서하고 TCP 프로토콜을 사용하여 인터넷을 거쳐 원래 컴퓨터로 전송하다.
6. 도착한 HTTP 응답 메시지는 HTTP 프로토콜을 사용하여 웹 페이지 데이터로 변환되어 웹 브라우저에 의해 출력되어 사용자가 볼 수 있게 된다.

#CORS 에러란?

요청 방식에 따라 다른 CORS 발생 여부

Cross-Origin

<img>,<video>,<script>,<link> 태그 는 다른사이트의 리소스에 접근하는것이 가능하다.

Same-Origin

• 다른 도메인의 소스에 대해 자바스킙트 ajax요청 API호출시
• 웹폰트 CSS 파인 내 @font-face에서 다른 도메인의 폰트 사용 시
• XMLHttpRequest, Fetch API 스크립트

CORS 란?

Cross-Origin Resource Sharing 는 웹 어플리케이션에서 다른 도메인의 리소스에 접근할 때 발생하는 보안 이슈를 해결하기 위한 표준 방법이다.

origin 란?

Protocol + Host + Post 모두 합쳐진 URL을 의미한다.

Protocol: http, https
Host: domain
Port: 포트 번호
Path: 사이트내부 경로
Query string: 요청의 key와 value값
Fragment: 해시태그

동일 출처 정책(Same-Origin Policy)

SOP (Same-Origin Policy)

동일한 출처에 대한 정책 = 동일한 출처에서만 리소스를 공유할 수 있다.
다른출처(Cross-Origin) 서버에 있는 이미지나 유튜브 영상 같은 리소스는 상호작용이 불가능하다.

동일 정책이 필요한 이유

해커가 CSRF(Cross-Site Request Forgery)나 XSS(Cross-Site Scripting) 등의 방법을 이용해서 어플리케이션에 해커를 심어놓은 코드가 실행하여 개인 정보를 가로챌수 있다. 이러한 경우를 방지 하기위해 사전에 방지 하는 것이다.

출처의 구분

URL의 구성요소 중 Protocal, Host,Port 3가지만 동일하면 동일 출처로 판단한다.

출처비교와 차단은 브라우저가

출처를 비교하는 로직은 브라우저에 구현된 스팩이다.(브라우저가 응답을 받아 동일 출처가 아니며 에러를 보낸다.)

교차 출처 리소스 공유(Cross-Origin Resource Sharing)

다른 출처의 리소스 공유에 대한 허용/비허용 정책이다.

CORS는 예외 조항을 두고 다른 출처의 리소스 요청이라도 이 조항에 해당할 경우 허용한다.

브라우저 CORS 기본동작

1. 클라이언트에서 HTTP 요청의 헤더에 Origin을 담아 전달
   1. 기본적으로 웹은 HTTP프로토콜을 이용하여 서버에 요청을 보낸다.
   2. 브라우저는 요청 헤어데 Origin이라는 필드에 출처를 담아 보내게 된다.
   3. ![[스크린샷 2023-11-30 오후 8.06.56.png]]
2. 서버는 응답헤더에 Access-Control-Allow-Origin을 담아 클라이언트로 전달한다.
   1. 서버가 이 요청에 대한 응답을 할 때 응답 헤어데 Access-Control-Allow-Origin이라는 필드를 추가하고 값으로 이 리소스를 접근하는 것이 허용된 출처 url을 내려보낸다.
   2. ![[스크린샷 2023-11-30 오후 8.09.05.png]]
3. 클라이언트에서 Origin과 서버가 보내준 Access-Control-Allow-Origin을 비교한다.
   1. 비교해 본후 차단할지 말지 결정
   2. 유효하지 않다면 응답하지 않고 CORS에러
   3. 유효하다면 다른출처의 리소스를 문제없이 가져오게 된다.

CORS 에러가 발생하는 경우

1. 출처가 다른 도메인 또는 포트로 리소스를 요청할 때
   • Access-Control-Allow-Origin 헤더 설정하여 요청 허용
2. HTTPS에서 HTTP로 리소스를 요청할 때
3. 인증 정보를 포함한 요청을 보낼 때
   • Access-Control-Allow-Credentials 헤더 설정 (설정되어 있지 않으면 브라우저는 인증 정보가 포함된 요청을 거부함)
4. 허용되지 않은 메서드를 사용할 때
   • Access-Control-Allow-Headers 헤더를 설정하여 요청을 허용한다.
5. 프리플라이트 요청에 대한 응답이 없는 경우
6. 브라우저가 CORS를 지원하지 않는 경우
7. CDN 등에서 제공하는 리소스를 요청할 때
   • CDN 등 제공하는 리소스 요청 할때도 CORS에러가 발생할 수 있다. 해당 설정 확인해야함
8. 허용되지 않은 헤더를 사용할 때
   • Access-Control-Allow-Headers 헤더를 설정
9. 브라우저 설정 문제

프론트에서 인증정보 포함한 요청을 보낼 때

인증 정보를 포함한 요청을 보낼 때 프론트에서도 처리해줘야 할것이 있는데 withCredentials옵션을 추가 하는 것이다.

this는 호출에 의해 달라진다.

1. 단독 으로 쓴 this

global object를 가르킨다.
strict 모드 에서도 마찬가지 이다.

'use strict'

var x = this
console.log(x) //window

2. 함수 안에서 this

함수 주인에 바인딩 된다.
window 를 가르킨다.

function myFunc(){
	return this
}
console.log(myFunc()) //window

var num = 0
function addNum(){
	this.num = 100
	num++
	console.log(num) //101
	console.log(window.num) //101
	console.log(num === windwo.num) //true
}
addNum()

• num은 전역변수를 가르킨다.
• strict mode 에서는 undefined을 가르킨다.

"use strict";

function myFunction() {

return this;

}

console.log(myFunction()); //undefined

var num = 0
function addNum(){
	this.num = 100 //error cannot set property 'num' of undefined
	num++
}
addNum()

3. 메서드 안에서 this

메서드 호출시 메서드 내부 코등서 사용된 this는 해당 메서드를 호출한 객체로 바인딩된다.

var pserson = {
	firstName: 'Maru',
	lastName : 'Park',
	fullName : function () {
		return this.firstName + this.lastName
	}
}
person.fullName() // "Maru Park"

var num = 0;
function showNum(){
	console.log(this.num)
}
showNum() //0

var obj = {
	num: 200,
	func: showNum
}

obj.func()//200

4. 이벤트 핸들러 안에서 this

이벤트를 받은 HTML 요소를 가리킨다.

var btn = documnetquerySelector('#btn')
btn.addEventListener('click', function(){
console.log()//#btn
})

5. 생성자 안에서 this

생성자 함수가 생성하는 객체로 this가 바인딩 된다.

function Person(){
	this.name = name
}

var kim = new Person('kim')
var park = new Person('Park')

console.log(kim.name)  //kim
console.log(park.name) //park

new 키워드를 생략하게 되면 일반 함수 호출과 같아지기 때문에 this는 window에 바인딩된다.

6. 명시적 바인딩 this

this 바인딩을 코드에서 명시하는 것을 명시적 바인딩 이라고 한다.

자바스크립트의 모든 function 은 apply() call() bind()라는 프로토타입 메소드를 가지고 있다. 이 메서드 중 하나를 호출함으로써 this 바인딩을 코드에서 명시하는 것을 명시적 바인딩이라고 한다.

call, apply

const foo= {
	a : 20
}
function bar (){
	console.log(this.a)
}
bar.call(foo) //20
bar.apply(foo) // 20

call, apply의 다른 점

두번째 매개변수로 객체의 인자를 전달해주는데 call은 매개변수의 목록, applay는 배열을 받는다는 차이가 있다.

bind

const foo = {
	a: 20
}

function bar(){
	console.log(this.a)
}
const bound = bar.bind(foo)

bind 메서드는 매개변수로 전달받은 오브젝트로 this가 바인딩된 함수를 반환한다. 이것을 하드 바인딩 이라고 한다. 하드 바인딩된 함수는 이후 호출될 때마다 처음 정해진 this 바인딩을 가지고 호출된다.

7. 화살표 함수 this

화살표 함수는 전역컨텍스트에서 실행되더라도 this를 새로 정의 하지 않고, 바로 바깥 함수나 클래스의 this를 사용한다.

var Person = function (name, age){
	this.name = name;
	this.age = age;
	this.say = function () {
		console.log(this) //Person{name: 'Maru', age:8}
		setTimeout(function(){
			console.log(this) //window
			console.log(this.name + 'is' + this.age + ' years old')
		},100)
	}
}
var me = new Person("Maru",8)
me.say() //global is undefined years old



// ()=>{}

var Person = function (name, age){
	this.name = name;
	this.age = age;
	this.say = function () {
		console.log(this) //Person{name: 'Maru', age:8}
		setTimeout(()=>{
	console.log(this)//Person{name: 'Maru', age:8}
			console.log(this.name + 'is' + this.age + ' years old')
		},100)
	}
}
var me = new Person("Maru",8)
me.say() //Maru is 8 years old

closure

함수가 선언될(생성될) 그 당시에 주변의 환경과 함게 갇히는 것을 말한다. 함수가 속한 렉시컬 스코프를 기억하여, 함수가 렉시컬 스코프 밖에서 실행될 때도 이 스코프에 접근할 수 있게 해주는 기능.

내부함수는 외부함수의 지역변수에 접근할 수 있는데 외부함수의 실행이 끝나서 외부함수가 소멸된 이ㅜ에도 내부함수가 외부함수의 변수에 접근할 수 있는것

function outerFunc(init){
	function innerFunc(num){
		return init + num 
	}
	return innerFunc
}
let addFunc = outerFunc(1);
console.log(addFunc(1)) //2

클로저 활용

1. 데이터를 보존 할 수 있다.
   클로저 함수는 외부 함수의 실행이 끝나더라도 외부 함수 내 변수를 사용할 수 있다.
   클로저는 이처럼 특정 데이터를 스코프 안에 가두어 둔 채로 계속 사용할 수 있게하는 폐쇄성을 갖는다.
2. 정보의 접근 제한(캡슐화)
   ‘클로저 모듈 패턴’을 사용해 객체에 담아 여러 개의 함수를 리턴하도록 만든다.
   이러한 정보의 접근을 제한하는 것을 캡슐화라고 한다.
3. 모듈화에 유리하다.
   클로저 함수를 각각의 변수에 할당하면 각자 독립적으로 값을 사용하고 보존할 수 있다.
   이와 같이 함수의 재사용성을 극대화 함수 하나를 독립적인 부품의 형태로 분리하는 것을 모듈화라고한다.
   클로저를 통해 데이터와 메소드를 묶어다닐 수 있기에 클로저는 모듈화에 유리하다.

토큰 기반 인증

토큰을 기반으로 한 인증에 대해서 알기 전에 기존에 쓰이던 세션 기반 인증에 대해서도 같이 정리해보겠음

세션(Session)이란?

사용자가 웹 브라우저를 통해 웹 서버에 접속한 시점으로부터 웹 브라우저를 종료하여 연결을 끝내는 시점까지 같은 사용자로부터 오는 일련의 요청을 하나의 상태로 보고 그 상태를 일정하게 유지하는 기술

즉, 클라이언트 별로 각각의 상태 정보를 서버에 저장하는 기술임

• 서버에서 클라이언트를 구분하기 위해 각 클라이언트 별로 세션ID를 부여하고, 웹 브라우저가 서버에 접속해 브라우저를 종료할 때까지 세션을 유지함
• 접속 시간에 제한을 두어 일정 시간 응답이 없다면 정보가 유지되지 않게 설정가능
• 사용자가 많아질 수록 서버 메모리를 많이 차지하게 됨 -> 서버에 부하가 생길 수 있음
• 쿠키에 비해 보안적인 면에서 좀더 나음(쿠키는 중간에 정보를 탈취할 수 있으므로)
• 브라우저 종료 시 만료기한에 상관없이 종료됨

세션 기반 인증 방식

토큰(Token)이란?

토큰은 인증이 필요한 시스템에서 사용자의 인증 정보를 암호화하여 생성한 문자열을 말함
사용자가 시스템에 로그인하면 해당 사용자의 식별 정보를 바탕으로 토큰이 생성되며, 이는 사용자가 서버에 요청을 보낼 때마다 함께 전송되어 사용자의 신원을 확인하는데 사용됨
토큰 기반 인증 방식은 사용자의 상태를 저장하지 않으므로 Stateless한 특성을 가져 세션 기반 인증 방식에 비해 서버의 부하를 줄이고 확장성이 있음

토큰 기반 인증 방식

JWT(JSON Web Token)

토큰의 한 종류로, 인증에 필요한 정보들을 암호화시킨 JSON 토큰을 의미함.

Access, Refresh Token

JWT을 사용해 로그인을 할 때, 유효기간이 짧은 토큰을 발급하게되면 사용자 입장에서 자주 로그인을 해야하기 때문에 번거로움
반대로 유효기간이 긴 토큰을 발급하게되면 제 3자에게 토큰을 탈취당할 경우 보안에 취약함
만약 JWT가 탈취 당했다면 서버에서는 해당 토큰이 만료될 때까지 할 수 있는 것이 없음(이미 발행된 토큰에 대해서는 서버에서 제어를 할 수 없음)

이런 취약점을 막고자 Access Token과 Refresh Token을 함께 사용하는 방법을 많이 사용함

예를 들면 유저가 로그인을 하면 서버에서 엑세스 토큰과 리프레쉬 토큰을 같이 발급해서 줌
사용자가 서비스를 이용하다가 엑세스 토큰의 만료기한이 지나면 처음에 같이 발급되었던 리프레쉬 토큰(엑세스 토큰보다 만료기한이 긺. 보통 2주라고 함)을 통해 서버에 엑세스 토큰의 재발급을 요청함

하지만 리프레쉬 토큰까지 탈취된다면 공격자는 엑세스 토큰을 발급받아 원래 사용자 인것처럼 행세를 할 수 있음 -> 이에 대한 조치도 추가로 필요(ex: 리프레시 토큰이 사용될 때마다 새 리프레시 토큰을 발급하여 이전의 리프레시 토큰을 무효하는 등)

JWT 토큰을 쿠키에 저장했을 때 취약점

그럼 어디다가 저장하는 게 좋을까?
아래의 블로그를 참조

버블링, 캡쳐링, 이벤트 위임

버블링

• 버블링이란?
  • 안쪽에 있는 자식 요소에서 시작해 부모 요소로 거슬러 올라가며 이벤트가 발생하는 것을 버블링이라고 함.
  • 모든 이벤트는 버블링 됨(default)
    focus와 같이 버블링 되지 않는 몇몇의 이벤트를 제외하고는 대부분의 이벤트는 버블링이 됨

<style>
  body * {
    margin: 10px;
    border: 1px solid blue;
  }
</style>

<form onclick="alert('form')">FORM
  <div onclick="alert('div')">DIV
    <p onclick="alert('p')">P</p>
  </div>
</form>

<style>
  body * {
    margin: 10px;
    border: 1px solid blue;
  }
</style>

<form onclick="alert('form')">FORM
  <div onclick="alert('div')">DIV
    <p onclick="event.stopPropagation()">P</p>
  </div>
</form>

  <body>
    <div id="outer">
      Outer
      <button id="inner">Inner</button>
    </div>

    <script>
      document.querySelector("#outer").addEventListener("click", () => {
        alert("outer clicked!");
      });

      document.querySelector("#inner").addEventListener("click", (event) => {
        event.stopPropagation()
        alert("inner clicked - First Handler");
      });

      document.querySelector("#inner").addEventListener("click", (event) => {
        alert("inner clicked - Second Handler");
      });
    </script>

  <body>
    <div id="outer">
      Outer
      <button id="inner">Inner</button>
    </div>

    <script>
      document.querySelector("#outer").addEventListener("click", () => {
        alert("outer clicked!");
      });

      document.querySelector("#inner").addEventListener("click", (event) => {
        event.stopImmediatePropagation()
        alert("inner clicked - First Handler");
      });

      document.querySelector("#inner").addEventListener("click", (event) => {
        alert("inner clicked - Second Handler");
      });
    </script>

캡쳐링

• 캡쳐링이란?
  자식요소에서 발생한 이벤트가 부모 요소로부터 시작해 이벤트가 발생한 안쪽 자식 요소까지 도달하는 것을 캡쳐링이라 함

표준 DOM 이벤트에서 정의한 이벤트 전파 흐름에는 3가지 단계가 있음

1. 캡쳐링 단계 : 이벤트가 하위 요소로 전파되는 단계
2. 타깃 단계 : 이벤트가 실제 타깃 요소로 전달되는 단계
3. 버블링 단계 : 이벤트가 상위 요소로 전파되는 단계

위의 이미지처럼 td 태그를 클릭하면 이벤트가 최상위 조상에서 시작해 아래로 전파(캡쳐링단계) -> 이벤트가 타깃 요소에 도착해 실행(타깃단계) -> 다시 위로 전파(버블링 단계)

이 과정을 통해 할당된 이벤트 핸들러가 호출됨
캡처링 단계를 이용해야하는 경우는 많지 않은데, 캡쳐링 단계에서 이벤트를 잡아내려면 addEventListener의 capture 옵션을 true로 설정하면 됨(default는 false로, 버블링 단계에서 이벤트를 잡음)

elem.addEventListener(..., {capture: true})

혹은 아래와 같이 true만 써도 됨
elem.addEventListener(..., true)

<style>
  body * {
    margin: 10px;
    border: 1px solid blue;
  }
</style>

<form>FORM
  <div>DIV
    <p>P</p>
  </div>
</form>

<script>
  for(let elem of document.querySelectorAll('*')) {
    elem.addEventListener("click", e => alert(`캡쳐링: ${elem.tagName}`), true);
    elem.addEventListener("click", e => alert(`버블링: ${elem.tagName}`));
  }
</script>

이벤트 위임(event delegation)

• 여러 개의 하위 DOM 요소에 각각 이벤트 핸들러를 등록하는 대신, 하나의 상위 DOM 요소에 이벤트 핸들러를 등록하는 이벤트 핸들링 패턴
• 이벤트 위임을 사용하면 요소마다 이벤트 핸들러를 할당하지 않고 공통의 상위 요소에 이벤트 핸들러를 단 하나만 할당해도 여러 요소를 한꺼번에 다룰 수 있음(이벤트 전파(버블링, 캡쳐링을 사용해서))

만약 이벤트 위임이 없다면 모든 요소에 일일히 이벤트를 등록해야함
-> 하지만 이벤트 위임이 있기 때문에 하나의 부모 요소에만 핸들러를 등록함으로써 코드의 중복을 줄이고 메모리 사용량을 줄일 수 있음
ex: 리스트 아이템이 수백 개 있는 목록에서 각각의 아이템(<li>)에 클릭 이벤트 핸들러를 붙이는 것보다 리스트 전체(<ol>)에 한 번만 클릭 핸들러를 붙여서 클릭된 아이템을 판별하는 것이 효율적임

<!DOCTYPE HTML>
<html>

<head>
  <link rel="stylesheet" href="messages.css">
  <meta charset="utf-8">
</head>

<body>

  <div id="container">
    <div class="pane">
      <h3>Horse</h3>
      <p>The horse is one of two extant subspecies of Equus ferus. It is an odd-toed ungulate mammal belonging to the taxonomic family Equidae. The horse has evolved over the past 45 to 55 million years from a small multi-toed creature, Eohippus, into the large, single-toed animal of today.</p>
      <button class="remove-button">[x]</button>
    </div>
    <div class="pane">
      <h3>Donkey</h3>
      <p>The donkey or ass (Equus africanus asinus) is a domesticated member of the horse family, Equidae. The wild ancestor of the donkey is the African wild ass, E. africanus. The donkey has been used as a working animal for at least 5000 years.</p>
      <button class="remove-button">[x]</button>
    </div>
    <div class="pane">
      <h3>Cat</h3>
      <p>The domestic cat (Latin: Felis catus) is a small, typically furry, carnivorous mammal. They are often called house cats when kept as indoor pets or simply cats when there is no need to distinguish them from other felids and felines. Cats are often valued by humans for companionship and for their ability to hunt vermin.
      </p>
      <button class="remove-button">[x]</button>
    </div>
  </div>

  <script>
    container.onclick = function(event) {
      if (event.target.className != 'remove-button') return;

      let pane = event.target.closest('.pane');
      pane.remove();
    };
  </script>

</body>
</html>

Redux

장점

• 용량이 가벼움
• 확장성이 높음
• flux 패턴을 사용하기 때문에 데이터가 단방향으로 흐름 -> 버그를 예측하기 쉬워져 디버깅에 유용함
• action을 통해서 상태 변화를 관리하기 때문에 어플리케이션이 어떻게 동작할지 예측하기 쉬움

단점

• 보일러 플레이트가 많음(액션이나 디스패치, 리듀서 등을 작성해야함)
• 러닝 커브가 있음

리덕스는 언제 사용하면 좋을까?

• 어플리케이션의 여러 위치에서 필요한 많은 양의 상태들이 존재할 때 (전역 상태가 필요하다고 느껴질 때)
• 상태들이 자주 업데이트 될 때
• 상태를 업데이트 하는 로직이 복잡할 때
• 어플리케이션이 중간 또는 큰 사이즈의 코드를 갖고 있고 많은 사람들에 의해 코드가 관리될 때
• 상태가 업데이트되는 시점을 관찰할 필요가 있을 때

=> 작은 프로젝트라면 굳이 리덕스를 사용할 필요는 없다!

React - Context API

장점

• 따로 라이브러리를 설치하지 않아도 됨
• Context API를 사용해 상위 컴포넌트에서 하위 컴포넌트로 props drilling 없이 prop를 직접 전달할 수 있음

단점

• 컴포넌트 재렌더링에 관련된 최적화 x
  전역에서 context를 공유하기 위해서 Provider를 만들게되는데, 프로바이더 컴포넌트는 매번 프로바이더에 새로운 값이 지정되어있는지를 확인함
  그 값이 새로운 참조일 경우에는 리렌더링이 발생하고 해당 컨텍스트를 둘러싸고 있는 모든 컴포넌트가 리렌더링됨

=> 쉽게 얘기하자면 프로바이더 하위에서 context를 구독하는 모든 컴포넌트는 프로바이더의 value로 공유하는 prop이 바뀔 때마다 다시 렌더링됨

const MyContext = React.createContext();

funcrtion MyContextProvider({ children }) {
	const [state, setState] = useState("Context Value");
    
    return (
    	<MyContext.Provider 
        value={
            number, setNumber
        }
        >
        	{children}
        </MyContext.Provider>
    )
}

export default MyContextProvider;

import { useState, createContext, useContext, useEffect } from "react";
import "./styles.css";

const MyContext = createContext(null);

const ChildComponentOne = () => {
  useEffect(() => {
    console.log("Child Component 1 is Rendered");
  });

  return <ChildComponentTwo />;
};

const ChildComponentTwo = () => {
  const [number, setNumber] = useContext(MyContext);

  useEffect(() => {
    console.log("Child Component 2 is Rendered");
  });

  return <>
    <p>{number}</p>
    <button onClick={() => setNumber(prev => prev + 1)}>+</button>
    <button onClick={() => setNumber(prev => prev - 1)}>-</button>
  </>
};

export default function App() {
  const [number, setNumber] = useState(0);

  return (
    <MyContext.Provider value={[number, setNumber]}>
      <ChildComponentOne />
    </MyContext.Provider>
  );
}

<MyContext.Provider value={{ number, setNumber }}>
  <ChildComponent />
</MyContext.Provider>

// 액션 정의
const INCREMENT = 'INCREMENT';

// 액션 생성 함수
function increment() {
  return { type: INCREMENT };
}

// 리듀서
function counter(state = 0, action) {
  switch (action.type) {
    case INCREMENT:
      return state + 1;
    default:
      return state;
  }
}

Recoil

• 페이스북에서 만든 상태관리 라이브러리
• atom -> selector -> component로 전달되는 데이터 플로우를 가짐

장점

• useState와 비슷하게 사용하는 방식이라 러닝 커브가 낮음
• 사용법이 직관적임(사용법이 간단)
• 보일러 플레이트가 거의 없음
• 동시성 지원(concurrent mode) : 리액트에서 렌더링 동작의 우선순위를 정해 적절한 때에 렌더링을 해줌
  recoil에서는 비동기 selector를 만들고 suspense로 감싸면 리액트의 동시성 모드를 구현할 수 있음
• 캐싱 지원
• atom의 값이 변경될 때마다 selector가 변경됨 -> atom의 값이 같으면 리코일에서 내부적으로 반환값을 메모이즈하고 있기 때문에 캐싱된 값을 반환함

단점

• 데브툴이 빈약함
• recoil에서 제공하는 훅들이 아직 unstable한 경우가 있음

컴포넌트가 가질수 있는 상태이며 상태를 생성하고 업데이트 할 수 있습니다.
업데이트 될때마다 상태가 변경되어 화면이 재 렌더링 됩니다.

useState를 사용 하는 이유

DOM렌더링과 관련 있는 일반변수를 사용하게 되면 렌더링 될때 마다 초기화 되지만 state 를 사용하는 경우 값을 반영하여 업데이트 해줍니다.
기존의 컴포넌트가 새로고짐이 되는 것이 아니기 때문에 state의 최신상태로 새로운 컴포넌트로 갱신해 주는것에 더 가깝습니다.

기존에 state를 복사하여 새롭게 state를 갱신해 주기 때문에 객체의 불변성을 지킬 수 있고, 발생할 오류를 미리 방지할 수 있습니다.
또한 state가 변경되면 알아서 리렌더링 해주기 때문에 훨씬 간결하고 효율적인 상태 관리가 가능합니다.

상태 업데이트 방법

setState 함수를 사용하여 상태를 업데이트 할수 있는데, 새로운 상태 값을 인수로 받아 컴포넌트의 상태를 업데이트하고 컴포넌트를 재렌더링 합니다.