(타입스크립트, 리액트, Next.js로 배우는 실전 웹 애플리케이션 개발) Ch1 Next.js와 타입스크립트를 활용한 모던 개발

브라우저 크래시 
제이쿼리가 지원했던 크로스 브라우저의 기능?
브라우저 라우터 히스토리(history API와 react-router의 차이?)

 

mvvm 

- model(데이터를 관리하는 model) /view(화면 표시와 관련된 view) / viewModel(데이터와 표시의 가교 역할을 하는 viewModel)
- MVVM에서는 모델로부터 뷰로 데이터를 연동하고, 뷰로부터 모델로 데이터의 양방향 바인딩을 수행하는 아키텍처
- 선언적 UI - https://react.dev/learn/reacting-to-input-with-state#how-declarative-ui-compares-to-imperative

 

React
 - 브라우저의 구현에 의존하지 않는 형태로 DOM을 삽입할 수 있어서 나중에는 서버 사이드에서의 컴포넌트 렌더링 등에 적용되었다.

NodeJS
 - 서버 사이드에서 자바스크립트를 실행할 수 있는 환경

트랜스파일
 - 한 언어를 다른 언어로 컴파일 하는 것을 트랜스파일이라 한다.

빌드 시스템
 - 소스 코드 상에 로딩한 모듈의 의존성을 해결하고, 실행 가능한 자바스크립트 형식으로 변환하는 구조.

프론트엔드 개발에서 웹팩을 활용하면 다음과 같은 장점을 얻을 수 있다.
 - 사용하는 의존 모듈의 버젼 관리와 해결을 자동화할 수 있다.
 - 파일 결합이나 코드 압축 등을 자동화할 수 있다.
 - 플러그인 메커니즘을 통해 다양하게 커스터마이즈 할 수 있다.
 - hot report 등 개발 효올화 도구를 포함하고 있다.

cf) 최근에는 ES 모듈 기반으로 라이브러리 배포 등에 사용되는 rollup.js이나 Next.js에서도 채용된 고속의 러스트(Rust) 기반 SWC라는 빌드 도구도 등장했다.

SSR
 - 리액트에서는 보통 사용자의 브라우저가 자바스크립트를 실행하고, JSON을 기반으로 페이지를 구축한다. 그에 반해 SSR은 서버 측에서 이를 수행하고, HTML을 생성해서 반환한다.
 - Node.js를 통해 서버 사이드에서 자바스크립트를 실행할 수 있는 환경이 보급되고, 리액트를 대표로 하는 프런트엔드 컴포넌트가 가상 DOM에 의해 구현 가능하게 됨에 따라, 서버 측에서 UI 컴포넌트를 렌더링해서 프런트엔드에 반환하는 구현 방법이 주목되었다.
 장점
  - 렌더링을 서버 사이드에서 수행한 결과를 반환하므로, 사이트를 빠르게 표시할 수 있다.
  - 서버 사이드에서 콘텐츠를 생성하므로, SPA에서는 복잡했던 SEO를 향상할 수 있다.
 단점
  - Node.js 등 서버 사이드 자바스크립트 실행 환경이 필요하다.
  - 서버 사이드에서 렌더링하므로 서버 CPU의 부하가 증가한다.
  - 서버와 클라이언트에서 자바스크립트의 로직이 분산될 가능성이 있다.

상황에 따라 SSR 혹은 SSG로 사이트를 만들어 사용해야한다.

NextJS
 - 웹팩 설정 은폐

PWA
 - 온라인 캐시
 - WebPush

SEO
 - GA
 - Search Console

DRY 프로그래밍 원칙 장점
 - DRY 란: Do not Repeat Yourself
  cf) https://blog.naver.com/finway/221163007357
 - 부품 재사용을 쉽게 할 수 있다(느슨한 결합이 된다)
 - 글로벌을 오염시키지 않는다
 - 코드 가독성이 높아진다
 - 테스트를 쉽게 할 수 있다.

좋은 컴포넌트 설계란?
 - 컴포넌트는 가능한 추상적이어야 한다. 개발하는 서비스에는 적든 많든 전문적인 비즈니스 로직과 그에 부합하는 데이터가 필요하다. 서비스나 기능 고유의 로직을 포함하는 UI 부품이 구현해버리면, 재사용성이 낮아져 컴포넌트의 장점을 얻을 수 없다.
 - 가능한 컴포넌트가 사용하는 상태를 다른 컴포넌트에서 의존하지 않는 형태로 구현하는 것이 중요하다.
컴포넌트 지향으로 구현한다는 것은 가능한 기초적인 컴포넌트 부분을 "재사용 가능한 형태"를 뜻하며, "애플리케이션의 콘텍스트에 의존하지 않는 형태"로 구현하는 것을 의식해야한다.

콜백의 버킷 릴레이

ContextAPI
 - 공유하기 위한 데이터를 포함하는 Context를 작성하고, Provider를 통해 Context를 적용할 범위를 지정한다.
 - 데이터를 사용하는 컴포넌트 안에서는 useContext를 호출해서 값을 얻을 수 있다.
 - 사용 목적은 props에 따른 버킷 릴레이를 피하는 것이다.
 - stackoverflow.com/a/32920459


아토믹 디자인 (atoms > molecules > organisms > templates > pages)
 - UI는 페이지 단위가 아니라 기능과 컴포넌트 단위로 구성해야한다는 개념