리액트 인사이드 1
01장 프론트엔드 구성 요소와 발전 과정 돌아보기
📌 FE의 발전과정에서 어떠한 문제를 기술이 해결했는지에 집중해야 한다.
- JQuery: 브라우저 호환성을 해결하기 위한 JS라이브러리 레이어이다.
- 리액트: 웹UI가 복잡하게 동적으로 발전함에 따라, 상태관리가 어려워지고 리액트가 이를 해결해준다.
- *각 시대마다 문제점을 정의하고, 그 문제를 잘 해결할 프레임워크나 라이브러리를 선택한다.
- 여러가지 기술들이 많이 나오지만 고통의 크기가 많이 클 수록, 그 문제를 뾰족히 해결 해준다면 기술이 대체된다.
📌 초창기 웹프론트 엔드
- Html만 보여주는 시절, CSS로 스타일링을 넣어주는 시대
- DOM ( 문서를 Tree 자료구조로 표현하고, 이를 조작할 수 있는 JS를 제공하는 것.)이 나오면서 동적으로 웹콘텐츠를 변경 할 수 있다.
- XHR, AJAX ( 자바스트립트 비동기로 데이터를 가져와서 DOM으로 콘텐츠를 동적 업데이트 하는 개념 )이 정립되어 동적웹으로 발전.
- 하지만 사용자 인터렉션이 기하급수적으로 복잡해지는 문제가 발생
📌 MPA(Multi Page Applicaiton), 번들러의 등장, npm 등장
- MPA : 서로 다른 URL 페이지는 서로 다른 HTML 파일을 가진다.
- 브라우저는 URL 마다 html을 다시 가져와서 새로고침 해야한다.
- MPA에서 중복으로 사용되는 모듈은 공통 JS 모듈로 관리한다.
- 하지만 의존성 관리가 매우 어려웠다. script 태그 순서를 바꾸는데 하루종일 걸린적도.
- 이를 해결하기 위해서 번들러가 나옴.
- 1, 번들러 덕분에 import, export 순서를 고려하지 않아도 된다.
- 2, 트리쉐이킹, 코드스플릿, ESM/CJS 모듈 빌드, ES5등 하위 버전 JS지원 등 기능을 지원
- 3, 테스크 러너는 반복되는 사전 빌드, 컴파일, 트랜스 파일링 등 도와주는 서브테스크 도구이다.
- npm 패키지 매니저가 없다면 필요한 모듈을 직접 검색해서 JS파일을 직접 프로젝트에 넣어줘야 했다.
- npm을 이용해서 패키지 관리를 쉽게 해결 가능하다.
📌 템플릿 엔진의 도입
- 동적인 콘텐츠에 따라 html을 동적으로 만들 필요성이 있어 pug, ejs 등 템플릿 엔진이 도입되었음.
- html 템플릿을 바탕으로 번들링된 JS, CSS를 넣어주고 콘텐츠에 맞게 html을 동적으로 빌드한다. (템플릿 엔진의 서버사이드 렌더링)
📌 UI 로직에서 명령형 프로그래밍의 단점
- 어떠한 설계 원칙 없이, 명령형 프로그래밍으로 UI를 관리하면 UI 업데이트의 책임은 개발자에게 있다.
- UI 상태과 데이터의 상태 분리가 안되어 있을 수 있음.
- UI 업데이트 로직이 산재되어 있을 수 있음. (티어링 이슈)
- 재사용성, 확장성, 유지보수가 어렵게 된다.
- 결국 이를 해결하다 보면 리액트와 같은 시스템을 만들게 됨,
- *함수형 패러다임에서는 일급 함수를 주로 다루면서 선언형 방식으로 추상화 되는 방향성.
02장 싱글 페이지 애플리케이션 돌아보기
2.1 싱글 페이지 애플리케이션의 장점을 돌아봐야 하는 이유 2.2 네트워크 호출 빈도 2.3 성능 향상 2.4 생산성 향상 __2.4.1 프론트엔드와 백엔드 개발 영역의 엄격한 분리 __2.4.2 선언형 프로그래밍을 사용한 빠른 프로토타입 구현 학습 마무리 | 핵심 키워드 리마인드
SPA 장점을 깊이 알아야 한다.
- SPA는 하나의 index.html 파일을 가지면서, 컴포넌트 기반 UI 설계, 클라이언트 사이드 라우팅, 상태관리를 책임진다.
- MPA와 비교해서 성능상 이점으로 자연스러운 유저 인터렉션 경험 제공 가능.
- 1, a태그에 의해서 페이지가 변경되면 html을 다시로드하는 일, CSS, JS 등 네트워크 요청이 최소화 된다.
- 2, 단점으로는 SPA이므로 데이터를 한번에 가져와 초기 로딩이 느려진다.
- 지연 로딩 스킬이 필요하다. ( 번들 코드 스플릿, 이미지 지연로딩, 데이터 지연로딩 )