프론트엔드 면접 핸드북

 자바스크립트는 싱글 스레드 기반 언어이다. 스레드가 하나라는 말은 곧, 동시에 하나의 작업만을 처리할 수 있다는 말이다. 하지만 실제로 자바스크립트가 사용되는 환경을 생각해보면 많은 작업이 동시에 처리되고 있는 걸 볼 수 있다. 어떻게 된 일일까...

1. 모든 비동기 API들은 작업이 완료되면 콜백 함수를 태스크큐에 추가
2. 이벤트 루프는 '현재 실행 중인 태스크가 없을 때'(주로 콜스택이 비워졌을 때) 태스크큐의 실행가능한 첫 번째 태스크를 꺼내와 콜스택으로 보낸다.

• 마이크로 태스크 큐 - promise callback - async function - queueMicrotask - process.nextTick() - 마이크로 태스크 큐를 우선적으로 처리

 코드를 실행하기 전에 var 선언문과 function 선언문을 해당 스코프의 최상단으로 끌어올리는 것

 함수 호이스팅이 발생하는 원인은 자바스크립트 변수 생성과 초기화가 분리되어 진행되기 때문

• 실행할 코드에 제공할 환경 정보들을 모아놓은 객체

• 자바스크립트는 동일한 환경에 있는 환경 정보들을 모든 실행 컨텍스트를 콜스택에 쌓아올린 후 실행하여 코드의 환경과 순서를 보장할 수 있게 됨

• 전역 컨텍스트 하나 생성 후, 함수 호출 시마다 컨텍스트가 생김

• 컨텍스트 생성 시, 컨텍스트 안에 변수객체, scope chain, this가 생성됨

• 컨텍스트 생성 후 함수가 실행되는데, 사용되는 변수들은 변수객체 안에서 값을 찾고, 없다면 스코프 체인을 따라 올라가며 찾음

• 함수 실행이 마무리되면 해당 컨텍스트는 사라짐

• 페이지가 종료되면 전역 컨텍스트가 사라짐(클로저 제외)

• ==는 변수의 값 비교
• ===는 변수의 유형을 고려해 비교

• NaN은 숫자가 아님을 나타냄 (Not a Number)
• 다른 NaN과 같지 않음

자바스크립트 비동기 처리에 사용되는 객체

• Pending(대기)
  • new Promise() 메서드를 호출하면 이 상태
• Fulfilled(이행)
  • resolve()를 실행하면 then을 이용해 처리 결과 값을 받을 수 있는 상태
• Rejected(실패) - reject()를 호출하면 실패 상태가 되고, catch로 에러를 받을 수 있는 상태

 기존의 비동기 처리 방식인 콜백 함수와 Promise의 단점을 보완하고 개발자가 읽기 좋은 코드로 작성할 수 있게 도와줌

 메모리 할당을 추적하고 할당된 메모리 블럭이 더이상 필요하지 않게 되었는지를 판단하여 메모리를 회수하는 것

• 레퍼런스 카운팅
  • 메모리 할당과 해제가 한 블럭 이내에서 이뤄질 수 없는 경우 사용
  • 동적으로 할당된 메모리를 참조하는 객체의 수
  • 레퍼런스 카운트는 처음 선언을 할 때 값이 1이 되고 카운트 값이 0이 되는 순간 메모리에서 제거됨
• 순환 참조 문제
  • 두 객체가 서로 참조하는 속성으로 생성되어 순환 구조를 생성한 경우, 스코프를 벗어나더라도 두 객체가 서로를 참조하므로 레퍼런스 카운트가 0이 되지 않음
  • 레퍼런스 카운팅으로 해결할 방법이 없음
  • 메모리 누수의 원인이 됨
• Mark & Sweep - 자바스크립트 엔진에서 이 알고리즘을 사용 - 최적화 없이 구현 시, 전체 객체를 탐색하므로 엔진에 영향을 미침 - 시작하는 노드를 루트라고 하고 사용되는 메모리 공간과 출처를 연결, 루트가 참조하고 있는 모든 객체를 방문해 마크하고, 마크되지 않은 모든 객체를 메모리에서 삭제

• 자신이 속한 객체 또는 자신이 생성할 인스턴스를 가리키는 자기 참조변수
• 함수를 호출한 객체를 의미
• this는 어떤 위치에 있느냐, 어디서 호출하느냐, 어떤 함수에 있느냐에 따라 참조값이 달라지는 특성이 있어 사용 시 주의해야함
  • 일반 함수로 호출할 경우, 글로벌 객체(window)
  • 메서드로 호출할 경우 이를 호출한 객체
  • call, apply, bind 사용 시, 메서드에 첫 번째 인수로 전달하는 객체
• 바인딩이란? - 식별자와 값을 연결하는 과정 - 변수선언은 변수 이름과 확보된 메모리 공간의 주소를 바인딩 하는 것

 함수를 실행하고 함수의 첫 번째 인자로 전달하는 값에 this 바인딩

• call
  • 두 번째 인자부터 차례로 값을 전달
• apply
  • 인자를 배열로 전달
• bind
  • 함수를 실행하지 않고, 새로운 함수를 반환
  • 반환된 새로운 함수를 실행해야 원본 함수가 실행됨

• debounce
  • 이벤트를 그룹화하여 특정시간이 지난 후, 하나의 이벤트만 발생하도록 하는 기술
  • 검색어 자동완성에 많이 사용
• throttle - 이벤트를 일정한 주기마다 발생하도록 하는 기술 - 스크롤 이벤트에 많이 사용

• mutable
  • 변할 수 있음
  • 참조타입(객체, 배열, 함수)
  • 해당 데이터 주소를 찾아서 값을 변경함
• immutable - 불변 - 원시타입(String, Number, Boolean, Null, Undefined) - 해당 데이터 주소와 별개의 새로운 주소에 값이 할당

• 얕은 복사
  • 객체 복사 시, 원본 값과 복사된 값이 같은 참조(= 메모리 주소)를 가리키는 것
  • 얕은 복사 후, 해당 변수를 재사용하여 수정한다면 원본 값도 변하므로 주의
  • Object.assign(), 전개 구문
• 깊은 복사
  • 복사된 객체가 다른 주소를 참조하며 내부의 값만 복사
  • 재귀함수, JSON.parse(), JSON.stringify() 이용

 트랜스파일러로, 모던 자바스크립트 코드를 구 표준을 준수하는 코드로 변환해줌

 개발자가 특정 기능이 기원되지 않는 브라우저를 위해 사용할 수 있는 코드 조각이나 플러그인. 브라우저에서 지원하지 않는 기능들에 대한 호환성 작업을 채워넣는다고 해서 polyfill이라 칭함

1. 렌더링 엔진은 먼저 HTML을 파싱해서 DOM 트리 구축
2. CSS 파싱 CSSOM 트리 구축
3. 자바스크립트 실행
4. DOM + CSSOM 렌더 트리 구축
5. 화면에 배치(Layout + reflow)
6. 그리기(paint)

• 자바스크립트는 DOM을 변경시킬 수 있음
• 스크립트가 아직 그려지지 않은 DOM 트리 노드에 접근 시, 오류 발생 가능성이 있음
• body 태그 최하단에 script 태그 삽입 권장

1. 웹 브라우저가 해당 도메인의 IP 주소 탐색
   • 캐시 확인 후 없을 경우, DNS 서버에서 IP 주소 탐색
2. 웹 브라우저가 서버와의 TCP 연결 시작
3. 웹 브라우저가 HTTP 요청을 서버로 전송
4. 웹 서버가 요청을 수행하고 응답 전송
5. 웹 브라우저가 콘텐츠 렌더링

• reflow
  • 웹 페이지의 일부 또는 전부를 다시 처리하고 그려야 할 때
  • 생성된 DOM 노드의 너비, 높이 위치 등을 변경했을 때 영향을 받는 모든 노드의 수치를 계산하여 렌더트리 재생성
• repaint - 변경된 요소를 화면에 그리는 작업 - reflow 이후에 필히 실행됨 - repaint만 일어나는 작업 - visibility, background-color, outline, opacity - 다른 노드에 영향을 주지 않고 발생하기 때문

• 애니메이션은 position fixed 또는 absolute로 설정
• transform 속성은 reflow가 일어나지 않음
• 안 쓰는 노드는 렌더트리에서 제외시키기
• table 태그 지양
  • 테이블 컨텐츠는 컨텐츠 변경 시 테이블 너비가 다시 계산되고 모든 셀의 reflow가 발생
• inline style 최소화 - HTML 파싱 시 레이아웃에 영향을 미쳐 reflow 발생

• 쿠키
  • 저장공간이 4KB로 적음
• 세션 스토리지
  • 브라우저 종료 시 날아감
• 로컬 스토리지
  • 브라우저에 남아있음

• 일정 시간동안 데이터 보관
• 서버에 접속 시, 접속한 클라이언트 정보를 PC에 저장했다가 재사용
• 클라이언트에서 쿠키 설정하는 방법
  • document.cookie = "test=test"로 세팅
• 서버에서 쿠키 설정하는 방법
  • 응답 헤더에 'Set-Cookie' 설정
• 서버에서 쿠키를 세팅하면 XSS 공격에 취약한데 어떻게 해결?
  • 응답 헤더에 Set-Cookie 설정 시 HttpOnly 옵션 세팅

    response.setHeader("Set-Cookie", "test=test; HttpOnly");

• 서버 측에서 관리
• 사용자가 많아질수록 서버 메모리를 많이 차지하게 됨
• 동작 방식 - 클라이언트가 서버에 접속 시 세션 ID를 발급받음 - 서버가 쿠키를 통해 발급해 준 세션 ID를 클라이언트가 저장 - 클라이언트가 서버에 요청 시 세션 ID를 전달, 서버에서는 전달받은 세션 ID로 세션 정보를 조회

• 자주 사용하는 데이터를 미리 복사해두는 임시 저장소
• 저장 공간이 작고 비용이 비싼 대신 빠른 성능을 제공

• 요청 헤더의 origin과 응답 헤더의 origin 비교 -> origin의 프로토콜(http, https), 호스트, 포트 중 하나라도 다르면 CORS 에러 발생
• 발생 주체는 브라우저
• 서버에서 응답 헤더에 Access-Control-Allow-Origin에 허용 출처를 내려보내 해결
• Preflight
  • 본 요청 보내기 전에 안전한 요청인지 확인을 위해 브라우저에서 보내는 예비 요청
  • HTTP 메소드 중 OPTIONS라는 요청이 사용됨
  • preflight 요청을 캐싱시키는 방법
    • 응답 헤더의 Access-ControlMax-Age 캐싱 시간 명시

• 스레드
  • 프로세스가 할당받은 자원을 이용하는 실행의 단위
  • 프로세스 내의 Heap, Data, Code 영역을 공유
  • 각각 Stack과 PC 레지스터 값 보유
  • 프로세스 하나를 사용하기 위해 소요되는 시간을 줄이고 효율을 높이기 위해 등장
  • 별도의 Stack을 가지지만 Heap은 공유하므로 서로 다른 스레드에서 가져와 읽고 쓰기 가능
• 프로세스 - 프로그램이 돌아가고 있는 상태 - Stack, Heap, Data, Text 영역으로 구성되어 할당 - 메모리에 별도의 주소 공간에서 실행되기 때문에 다른 프로세스의 변수나 자료구조에 접근 불가

• 싱글스레드
  • 하나의 프로세스에서 하나의 스레드로만 실행
• 멀티스레드 - CPU의 최대 활용을 위해 프로그램의 둘 이상을 동시에 실행하는 기술 - 이는 컨텍스트 스위칭을 통해 이루어짐

• 장점
  • 컨텍스트 스위칭 필요없음
  • 자원접근 동기화 고려하지 않아도 됨
  • 단순히 CPU만을 사용하는 계산작업이라면, 오히려 멀티스레드보다 싱글스레드로 프로그래밍하는 것이 더 효율적
  • 프로그래밍 난이도가 쉽고, CPU, 메모리를 적게 사용
• 단점
  • 여러 개의 CPU를 활용하지 못함
  • 연산량이 많은 작업을 하는 경우, 그 작업이 완료되어야 다른 작업을 수행할 수 있음
  • 싱글 스레드 모델은 에러 처리를 못하는 경우 멈춤(멀티 스레드 모델은 에러 발생 시 새로운 스레드를 생성하여 극복)

• 장점
  • 프로그램의 일부분(스레드 중 하나)이 중단되거나 긴 작업을 수행하더라도 프로그램의 수행이 계속 되어 사용자에 대한 응답성이 증가
  • 프로세스 내 자원들과 메모리를 공유하기 때문에 메모리 공간과 시스템 자원 소모가 줄어듦(경제성)
  • 다중 CPU 구조에서는 각각의 스레드가 다른 프로세서에서 병렬로 수행될 수 있으므로 병렬성이 증가(멀티프로세서의 활용)
• 단점 - 컨텍스트 스위칭, 동기화 등의 이유 때문에 싱글 코어 멀티 스레딩은 스레드 생성 시간이 오히려 오버헤드로 작용해 싱글 스레드보다 느림 - 스레드는 힙, 데이터 영역을 공유하기 때문에 타 스레드가 사용 중인 값에 접근하여 이상한 값을 읽어올 수 있기 때문에 동기화가 필요함 - 멀티 스레딩을 위해서는 운영체제의 지원이 필요 - 멀티 스레드 모델은 프로그래밍 난이도가 높으며, 스레드 수만큼 자원을 많이 사용

• HTTP
  • Hypertext Transfer Protocol
  • 서로 다른 시스템들 사이에 통신을 주고 받게 해주는 가장 기본적인 프로토콜
• HTTPS - Hypertext Transfer Protocol Secure - HTTP에 데이터 암호화가 추가된 프로토콜 - HTTPS를 사용하기 위해서는 인증된 기관 CA(Certificate Authority)에 공개키를 전송하여 인증서를 발급받아야 함

• 클라이언트-서버 구조로 되어있음
• 무상태 프로토콜(Stateless)
  • 서버가 클라이언트의 이전 상태를 보존하지 않음
  • 이때문에 로그인 상태를 유지하려면 다른 방법을 이용해야함
• 비연결성(Connectionless) - 클라이언트가 서버의 응답을 받으면 연결을 끊어버림 - 서버의 자원을 효율적으로 관리

• HTTP/1.1
  • 연결(Connection) 하나 당 하나의 요청을 처리
  • 매 요청마다 중복된 헤더를 전송하게 되어 무거운 헤더가 단점
• HTTP/2
  • 연결 하나로 동시에 여러 개의 메시지를 주고 받을 수 있음
  • 클라이언트가 여러 번 중복 요청 시 HPACK 압축 방식을 이용한 헤더 압축 전송
• HTTP/3 - 1.1, 2.0과 달리 UDP 기반 프로토콜인 QUIC를 이용해 통신 - 안전하고 암호화된 방식으로만 수행될 수 있음

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

 UI 구축을 위한 자바스크립트 라이브러리

• 가상 돔의 사용으로 앱 성능 향상
• 클라이언트, 서버 사이드 렌더링 지원 가능
• 컴포넌트 기반 작업으로 효율적인 코드 분리 가능
• 가독성이 높아 유지보수가 비교적 쉬움
• 많은 커뮤니티

 virtual DOM이 변경될 때 실제 DOM을 변경하도록 되어있음(재조정)

• componentDidMount
• render
• componentDidUpdate
• componentWillUnmount

• 클래스형 컴포넌트
  • 여러 단계의 상속으로 이루어짐
  • 라이프 사이클을 가짐
• 함수 컴포넌트 - hook을 사용해 라이프 사이크에 따른 동작 - 가독성이 좋음

• CSR(Client Side Rendering)

  • 클라이언트쪽에서 렌더링이 일어남
  • 첨에 빈 페이지이다가 HTML, JS 다운로드 후 렌더링

• SSR(Server Side Rendering)

  • 서버쪽에서 렌더링이 끝난 후 클라에 전달
  • 서버에서 HTML 전달 -> 첨에 HTML 렌더링된 상태
  • 자바스크립트 다운로드, 컴파일 후 상호작용 가능

• 첫 페이지 로딩시간은 SSR이 평균적으로 빠름

• 다른 페이지로 이동 시, SSR은 처음과 동일한 과정 반복 -> CSR이 평균적으로 빠름

• SEO 대응은 SSR이 용이

  • 대부분의 웹 크롤러들은 JS를 실행시키지 못하고 HTML에서만 컨텐츠를 수집하기 때문

• state는 불변성을 유지해야함
• 얕은 비교를 통해 리렌더링을 실행하는데, state가 참조형일 때 동일 참조일 경우 리렌더링을 실행하지 않음

• 로직의 재사용
• 관리가 쉬움
• 가독성이 좋음
• 코드가 간결함

• useMemo
  • 메모이제이션된 값을 반환
• useCallback - 메모이제이션된 함수를 반환

 DOM을 가볍게 만든 자바스크립트 표현

 props를 오로지 하위 컴포넌트로 전달하는 용도로만 쓰이는 컴포넌트들을 여러개 거쳐 데이터를 전달하는 과정

• props
  • 부모에서 자식 컴포넌트로 전달하는 읽기 전용 데이터
• state - 본인 컴포넌트 내부에서 관리하는 변경 가능한 데이터

• state가 변경되었을 때, render 함수가 여러번 호출되는 것을 방지하기 위해 한 번만 호출하도록 하는 것
• 여러 개의 상태 변경을 한 번에 묶어서 처리

• state가 변경됐을 때
• props가 변경됐을 때
• 부모 컴포넌트가 리렌더링 될 때
• forceUpdate 함수가 실행될 때

• 뭐임?
  • 모든 리소스를 최초에 한 번 다운로드하고, 이후에 새로운 데이터 요청 시 필요한 데이터만을 전달받아 페이지를 갱신
  • CSR 방식으로 렌더링
• 장점
  • 빠른 페이지 이동 가능 및 깜빡거림이 없음
  • 필요한 리소스만 부분적으로 로딩
  • 모듈화 또는 컴포넌트별 개발이 용이
• 단점 - 처음에 모든 리소스를 한번에 다운로드 하기 때문에 초기 구동 속도가 느림 - SEO가 어려움(검색 엔진이 앱 로딩 전 빈 상태의 코드를 크롤링하기 때문) - 코드가 외부에 노출됨

 서버단에서 정적 페이지를 렌더링, JS파일 번들링 후 클라단에 보내주는데(SSR).. 그 DOM에는 이벤트가 하나도 없는 메마른 상태일 것. 그래서 인제 hydration(직역하면 수분 보충) 그 DOM 노드들에 이벤트 핸들러를 매칭시켜 동적으로 상호작용 하도록 촉촉하게 바꿔주는.. 수분 보충해주는 그런.. 그런 것

 React v16~ React.hydrate

 서버에서 생성한 HTML과 클라이언트에서 생성한 DOM 트리에 차이가 있을 때 발생

• React v16 전까지 재귀방식의 알고리즘을 virtualDom의 재조정에 사용
• 변경해야 할 노드가 너무 많은 경우 콜스택이 다 비게 될 때까지 메인 스레드가 다른 작업을 못함
• 재귀동작에서 체인형 링크드 리스트로 수정
• 특정 작업에 우선순위를 매겨 작업의 작은 조각들을 동시적으로 일시 정지, 재가동 할 수 있게 함

• 컴포넌트 Lazy Loading이나 Data Fetching 등의 비동기 처리를 하는 동안 fallback 화면을 띄워줌
• Relay, SWR, React-Query, Recoil 지원

• 오류를 잡아내기 쉬움(컴파일 단계에서 오류 잡기 가능)
• 생산성 향상
• 코드 유지보수성 향상

• any
  • 예외
  • 모든 타입의 변수에 any 타입 값을 할당 가능하고, any 타입의 변수에 모든 값을 할당 가능함
• unknown
  • 모든 타입의 상위 개념
  • unknown 타입의 변수에 모든 값을 할당 가능
• never
  • 최하위 개념
  • never 타입에 아무것도 할당 불가 그러나 아무 타입의 변수에 never 타입 변수 할당 가능
• void
  • undefined의 상위 개념
  • void 반환으로 선언한 함수에서 undefined를 반환해도 오류 발생하지 않음

• type
  • 원시 타입
  • 튜플 타입
  • 함수 타입
  • 유니온 타입
  • 매핑된 타입
• interface - 객체 타입 정의 또는 타입 사용할 필요가 없을 경우 - 자동 병합을 활용해야할 경우

 타입을 파라미터처럼 사용하는 것

• 이미 정의해 놓은 타입을 변환할 때 사용하기 좋은 문법
• Partial(부분집합)
• Pick(몇 개 찝어 쓰기)
• Omit(몇 개 버리고 쓰기)

• Props drilling 문제 해결
• devtool이 있음

• store
  • 상태가 관리되는 곳
• action
  • 앱에서 스토어에 보낼 데이터
• reducer
  • action을 reducer에 전달하면 reducer가 store의 상태를 업데이트
  • action을 reducer에 전달하려면 dispatch 메소드 사용

 사용자 입력을 기반으로 Action을 만들고, Action을 Dispatcher에 전달하여 Store의 데이터를 변경한 뒤 View에 반영하는 단방향 데이터 흐름

 참조값을 비교하여 상태변화를 감지하기 때문

1. 상태는 store에서 집중관리
2. 상태는 불변하며, action만이 상태교체를 요청할 수 있음
3. 변화는 순수함수(reducer)로 작성해야함

 vercel에서 개발한 리액트 프레임워크

• hot reloading
• automatic routing
• single file components
• server rendering
• code splitting

등등

 SSG는 빌드 시간에 만들어진 HTML을 요청에 따라 재사용한다(블로그, 마켓팅 사이트 등 요청에 따라 응답이 매번 변화하지 않는 사이트에 사용). 그에 반해 SSR의 경우, 요청에 따라 그때그때 HTML을 생성한다(실시간으로 요청에 따라 응답이 다른 사이트에 사용).

1. 디바이스 사이즈에 따른 이미지 크기 조정
2. 이미지가 로드될 때 레이아웃이 변경되는 것을 방지
3. lazy loading(placeholder 설정 가능)를 통한 빠른 페이지 로드

요청 헤더에 Accept로 지원하는 확장자를 실어보냄

1. A SDP 오퍼 생성 후 시그널링 채널을 통해 원격 피어에 전달
2. B 오퍼 수신 후 오퍼 설정, 시그널링 채널을 통해 답변 전송
3. A 답변 받은 후 setLocalDescription을 사용해 설정
4. STUN 또는 TURN 서버를 사용해 RTCPeerConnection 객체를 생성
5. peerConnection에 connectionstatechange 이벤트 받아서 connected 상태일 경우 성공적 연결

• NAT(Network Address Translation)
  • Private IP를 Public IP와 1:1로 대응시켜 변화하는 장치
• ICE(Interactive Connectivity Establishment)
  • ICE는 두 단말이 서로 통신할 수 있는 최적의 경로를 찾을 수 있도록 도와주는 프레임워크
  • ICE는 혼자 작동하지 않으며 STUN, TURN 서버 사용
• STUN(Session Traversal Utilities for NAT)
  • 해당 Peer의 Public IP 주소를 보내는 역할
  • 두 Peer가 같은 NAT 환경에 있을 경우나 NAT의 보안 정책이 엄격할 때는 좋지 않음
• TURN(Traversal Using Relays around NAT) - 각 Peer들이 TURN 서버를 경유하여 통신 - STUN에 비해 리소스 낭비가 심함

 connectionstatechange 이벤트에서 disconnected 떴다가 재접속되면 connected 이벤트가 날아옴

 Publisher, Broker, Subscriber 구조로 이루어져 Publisher가 Topic을 발행하고, Subscriber는 Topic을 구독한다. Broker는 중계자 역할을 하며, 1:1, 1:N 통신이 가능하다.

 서비스의 품질 단계 설정

• 0단계
  • 메시지를 보내고 잘 갔는지 확인 하지 않음
• 1단계
  • 메시지가 전달되었다는 신호를 받고, 신호가 안 오면 올 때까지 계속해서 메시지를 전송
  • 메시지를 중복으로 발행할 가능성이 있음
• 2단계 - 4way handshaking을 사용하여 정확히 한 번의 메시지 전송을 보장하는 방법

• LCP(Largest Contentful Paint)
  • 용량 젤 큰 컨텐츠 표시되는 시점
• FCP(First Contentful Paint)
  • 컨텐츠의 일부가 화면에 렌더링될 때까지의 시간
• TTI(Time To Interactive)
  • 웹 페이지가 완전히 상호작용 가능하게된 시간
• TTFB(Time To First Byte)
  • 페이지 요청 시, 서버에서 데이터의 첫 번째 바이트가 도착하는 시간

• 장애인이나 고령자분들이 웹 사이트에서 제공하는 정보를 비장애인과 동등하게 접근하고 이용 할 수 있도록 보장하는 것
• 적절한 대체텍스트
• 색에 무관한 콘텐츠 인식
• 키보드만으로 사용 가능하도록
• 응답시간 조절 가능하도록
• 정지 기능 제공
• 제목 제공

등등..

• Recoil
  • 장점
    • 리액트 훅과 유사하게 사용 가능(러닝커브가 가파름)
    • selector로 비동기처리가 가능
  • 단점
    • 아직도 1 버전이 출시되지 않음
    • devtool이 없음
• Redux
  • 장점
    • Flux 패턴으로 상태 변화를 더욱 예측하기 쉬워 유지보수에 용이
    • devtool이 있음
  • 단점
    • 보일러 플레이트 코드가 많음
    • 비동기 처리를 위한 별도의 라이브러리가 필요
• Jotai
  • 장점
    • 리액트 훅과 유사하게 사용 가능(러닝커브가 가파름)
    • Recoil과 비교했을 때, key를 지정하지 않아도 됨
  • 단점
    • 자료가 적고 커뮤니티가 작음
• Zustand - 장점 - Redux Devtools로 디버깅 가능 - 보일러플레이트가 적음 - 단점 - 자료가 적고 커뮤니티가 작음