Node.js
react는 node의 환경에 의해 실행
구글 크롬의 v8엔진을 활용하여 브라우저 밖에서도 자바스크립트를 컴파일 혹은 실행 할 수 있는 일종의 런타임(실행환경)
React란?
복잡한 사용자 인터페이스(UI)를 쉽게 구축하기 위해 페이스북에서 제작한 javascript로 만든 라이브러리
라이브러리는 모듈(코드 덩어리)의 집합!
프레임워크와 라이브러리 차이점
프레임워크 코드를 만들 때 필요한 뼈대와 틀을 제공해주는 것 따라서 프레임워크에서 개발을 할 때는 해당 프레임워크가 가지고 있는 규칙에 의해서 작성, 즉 제어권이 프레임워크가 가지고 있다.
라이브러리는 제어권이 개발자에게 있다. 코드를 작성할 수 있는 환경을 제공한다. 사용자는 특정 규칙이 아닌 필요로 하는 라이브러리를 선택해서 사용할 수 있다.
→ 프레임워크는 기계, 따라서 정해진 사용법에 의거하여 사용한다. 라이브러리는 도구함, 내가 원하는 도구를 선택해서 사용한다.
React의 핵심 컨셉
- re-render와 component
component
- 하나의 페이지를 한 가지 기능을 수행하는 UI 단위로 분리한 것
- 재사용이 용이하고 관리 및 유지 보수에 효율적
Virtual Dom
- react가 가지고 있는 가상 돔, 진짜 돔의 복사본
- react의 상태가 바뀌면 가상돔의 상태를 진짜 돔에 리랜더링하는 것
- 바뀐 컴포넌트만 랜더링을 시킨다.
key point
리액트의 상태(state), 컴포넌트(분리), 가상돔(re-render)
CSR vs SSR
CSR(Client Side Rendering)
사용자가 페이지를 그린다.
사용자가 웹 사이트에 접속 → 서버에 페이지에 필요한 리소스(code, asset) request
페이지가 로드될 때 상품에 관한 정보를 백엔드 서버에 달라고 요청
사용자는 전달받은 리소스를 js까지 모두 로드한 후 화면에 표현
→ 사용자가 랜더링 부담
사용자가 랜더링 부담
(html, css, js 등 페이지 랜더링에 필요한 리소스가 모두 로드된 후 사용자가 화면을 확인 가능)
장점
필요한 자바스크립트를 사전에 미리 불러와 초기 랜더 이후의 속도는 빠르다. 특히 사전에 백엔드와 통신하는 부분이 없다면 SSR을 사용할 이유가 없다.
단점
초기 페이지 로딩이 SSR보다 느리다.
사용자가 페이지를 랜더하는 동안 빈화면을 보게되므로 UX가 좋지 않다. 사용자에게 랜더링을 부담 → 사용자 하드웨어에 의존
SSR(Server Side Rendering)
서버에서 페이지를 그린다.
사용자가 웹 사이트 접속 → 서버에 필요한 페이지 요청 → 서버에서 그려진 페이지 전달
js가 로드 되기 전에 완성된 페이지를 사용자가 먼저 확인
서버가 랜더링 부담
(페이지 랜더링에 필요한 최소한의 리소스를 서버에서 그린 후 전달, 사용자는 다른 부가적인 리소스가 적용되기 전에 화면을 확인가능)
장점
SEO(검색 엔진 최적화) : 웹 사이트를 검색엔진이 크롤링하여 사용자에게 제공, 해당 과정을 최적화하여 더 많은 사용자에게 웹 사이트를 노출
- 빠른 첫페이지 로딩속도
- 서버에서 랜더를 부담하기 때문에 사용자가 느끼는 부담이 덜하다.
단점
- 서버의 부담(생산 비용 증가 → 단 SSG로 완화 가능)
- 무거운 페이지라면 오히려 초기 페이지로딩이 오래걸려 UX를 해칠 가능성이 높음
- CSR보다 더 많은 생산비용(코드를 많이 쳐야함, 인력) 추가 러닝 커브
SPA(Single Page Aplication)
말 그대로 페이지가 하나인 애플리케이션(.html 파일이 1개)
react는 SPA 개발에 최적화, 사용자가 웹 사이트에 접속하면 접속 당시 단 한번만 페이지에 필요한 리소스(html, css, js)를 전부 전달하고 이를 캐싱(저장)해두었다가 url가 달라짐에 따라 html의 내부를 수정(리랜더)해서 사용자에게 보여주는 것이다. 따라서 react의 통상적인 파일 구조에는 index.html 파일 하나만 존재
→ 리엑트는 CSR로 로드시 필요한 리소스 모두 가져오고, html이 하나로 url이 달라짐에 따라 다른 리소스를 보여준다.
MPA(Multi Page Aplication)
SPA와 반대로 페이지가 여러개인 애플리케이션(.html이 여러개)
SSR 방식으로 요청마다 리소스를 받아온다.
spa는 한번에 페이지 랜더링에 필요한 리소스를 받아오는 것이고 mpa는 요청마다 페이지에 필요한 리소스를 전달 받는 것으로 이해
React는 CSR에 SPA다.
패키지(라이브러리)관리 툴
라이브러리를 관리하고 설치할 수 있는 도구
npm, npx, yarn, yarn2(yarn berry)
npm
node.js에서 기본적으로 설치되어 있는 패키지 관리 툴
사용법
- npm i(install) 라이브러리명
- npm rm(remove) 라이브러리명
- npm -v : 확인
- npm i -g 라이브러리명 : 해당 라이브러리를 전역으로 설치, npm 자체에서 설치
- npm i -d 라이브러리명 : 개발자용으로만 사용할 라이브러리를 설치
e) 디버깅하는 툴(콘솔) → 사용자에게 보이면 안된다.
npx
npm과 달리 설치하지 않고 라이브러리를 실행 시켜주는 도구
사실 개발하는 입장이라면 npm과 npx 차이를 느끼기가 애매하다.
단, npx를 사용하면 react project를 생성할 때 굉장히 무거운 패키지를 사용한다. 이를 설치하지 않고도 프로젝트 생성
→ 설치해서 사용하는 것이 아닌 실행해서 사용할 수 있는 라이브러리들을 사용할 때
ex) npx create-react-app 프로젝트명 : 리엑트 프로젝트를 만드는 명령어(CRA)
yarn
과거 npm보다 속도, 안정성, 보안 모두 뛰어나 이목을 끌었다가 현재는 npm과의 차이가 거의 없다. 따라서 yarn 만을 사용하는 것은 npm과 차이가 없기 때문에 사용하는 의미가 없다.
설치방법
- npm i -g yarn
- yarn add 패키지명
- yarn remove 패키지명
yarn berry
라이브러리가 설치되면 npm과 yarn의 경우는 node_modules라고하는 파일에 저장, 따라서 node_modules 파일은 무겁다.
pnp 방식을 도입 zero install
알집으로 파일을 관리하고 있기 때문에 프로젝트 자체가 가볍고 빨라진다.
모노레프 → 워크페이스를 통해 하나의 프로젝트의 여러개의 프로젝트를 담고 관리할 수 있음, yarn을 사용했을 때는 turbo 라이브러리의 도움이 필요하다. 하지만 yarn berry은 더이상 turbo 라이브러리의 도움 없이도 모노레프 구성이 쉽게 가능하다.
그러나, 파일 및 폴더 구조가 복잡하고 신경써야하는 부분이 그만큼 더 늘어난다. 따라서 초기에 적용하기에는 적합하지 않으니 훗날 react를 npm과 yarn으로 프로젝트를 한가지 이상 끝내본 후에 적용하는 것을 추천
React 프로젝트 생성
- 터미널 명령어를 통해 폴더 경로를 맞춰준다.
cd 폴더명, cd 절대경로, cd ..
- 명령어
npx create-react-app 프로젝트명(CRA)
- react에서 권장하는 react 패키지 설치 라이브러리, npx로 실행
- CRA가 없어도 react 프로젝틑 생성이 가능, 그러나 리액트에 필요한 라이브러리를 따로 모두 설치해야하고 조건과 설정 파일을 직접 써야하는 단점
- CRA는 react에 필요한 모든 설정 파일을 대신 설정해준 라이브러리(웹팩, 바벨)
-단점은 설치된 설정 파일의 커스텀 조작이 힘듬, 따라서 설정을 커스텀해야는 경우에는 해당 파일을 모두 설정해줘야 한다.
- cd ex01 → npm start
기본 포트를 3000번이나, 현재 3000번 포트가 실행 중 일경우 자동으로 3001, 3002, ...
localhost라는것은 개인 컴퓨터 환경
