SSG (스태틱 사이트 제네레이션)
이미 만들어진 html을 보내 주는 것
(음식이긴 한데, 편의점에서 처럼 만들어진 음식만을 먹는 것)
Ex. 쇼핑몰 (요청 적음)
SSR (서버 사이드 렌더링)
서버에서 요청에따라 동적으로 html을 만들어서 제공함
단, 클릭시 페이지가 깜빡임, html이 새로 전송되니까
(오마카세처럼 원하는 요리를 요청해서 먹는 것)
Ex. 요청이 많은 페이지 (네이버?)
CSR (클라이언트 사이드 렌더링)
클라이언트에서 요청을 보내면 div태그 한 개 있는 html을 보내는데
여기에서 JS로 쫙 쏘기 때문에 별도로 요청을 하지 않아도 됨
받은 JS 내에서만 동작하므로 별도 깜빡임 X (리액트)
단점 : 무거움, 검색엔진에 적용이 X (div태그만 보내니까 상단 노출이 되지 않으므로 기업이 손해 그래서 다시 진보되기 보다 SSR, SSG를 사용하는 것)
Next를 쓰면 SSG, SSR을 지원하기 때문에 리액트 같은 CSR과 함께 사용하여 CSR + SSR 둘 다를 가능케 하는 것임 (Next - 리액트 기반 프레임워크)
프레임워크 : 일종의 규격이라 생각하면 되고 스프링처럼 틀이 정해져 있으며 우리는 그저 그 틀에 맞춰 사용할 뿐 그렇기에 자유도 없지만, 안전성이 많음
라이브러리 : 레시피를 보며 자기가 하는 것이라 생각하면 되고 자유도는 많지만, 안전성이 떨어짐
React는 단지 UI 컴포넌트를 만드는 라이브러리이고
Next는 프레임워크기 때문에 자유도는 많이 떨어지지만 안정성이 올라감
여러 관리 Hook
- useState : 상태관리
- useEffect : 종속성 관리 (비동기 처리)
- useReducer : 한 컴포넌트 내에서 객체로 여러 State를 관리 할 때
(ex. const [상태값, 디스팻치] = useReducer(리듀서함수, 초기상태)- Redux : 전역 상태관리
- ContextAPI : 전역상태 (절반?) - 굳이 전역으로 관리 하지는 않음
- dispatch : 상태변경함수 (setState)
전역이 아니라 중간부터 Props를 통해 전달을 한다면 props drilling 때문에 계속 전달해야 하는 사태가 벌어짐
그럴 때 쓰는 게 context API, 중간에 Context Api를 만들어 놓고 중간 단계부터 하위까지만 상태관리를 해주면 되지만, context를 쓰면 state를 넣은 곳들만 리렌더링이 되기 때문에 가운데 넣은 애도 불필요하게 리렌더링이 됨
압도적인 인풋을 넣는다면 불가능한 것은 없다. 🔥