🟩 Overview
🔶 Introduction to React
🔸 선언형(Declarative)
const LoginView = () => {
return (
<article>
<p>ID</p>
<input name="id" type="text" />
<p>PASSWORD</p>
<input name="password" type="password" />
</article>
);
}
내가 원하는 로그인 화면의 결과 값만을 반환(return)하고 있으며, 이를 어떻게 UI에 렌더링할 것인지에 대한 부분은 작성되어있지 않다. 즉, UI를 렌더링하는 부분은 React에 위임하여, 개발자는 결과에만 초점을 맞출 수 있다. 🔸 JavaScript 라이브러리
🔸 Component-Based Architecture 사용하여 재사용 가능한 UI 구축
Component-Based : 재사용이 가능한 각각의 독립된 모듈 🔶 Key Feature of React
🔸Component-Based
🔸Virtual DOM
DOM(Document Object Model) https://www.tpointtech.com/
웹에 접속하면 보이는 각각의 요소(Element)들이 모여 하나의 문서(Document)를 구성한다. 이러한 문서의 구조를 Javascript가 사용할 수 있도록 표현한 것이 DOM이다. DOM 구조는 위에서 보다시피 트리(Tree) 형태로 표현되며, 각 요소에 해당하는 노드들이 존재한다. 웹 페이지의 특정 요소의 색상을 변경하려면 해당 요소를 찾아 색상을 변경한 후 그 변경 사항을 적용하기 위해 해당 요소부터 하위 요소까지 브라우저가 화면 렌더링을 하는데 가장 많은 비용이 발생한다. → 리플로우(Reflow) 및 리페인트(Repaint)에 대한 많은 비용 발생
리플로우(Reflow) : DOM구조나 레이아웃 변경 시 브라우저는 새로운 레이아웃을 계산하고 화면을 다시 그린다. 리페인트(Repaint) : 요소의 색상이나 테두리 등이 변경되면 브라우저는 해당 요소를 다시 그린다. 리플로우와 리페인팅 문제를 해결하기 위해 도입된 개념. React는 렌더링 발생 시, 새로운 화면에 들어갈 내용이 담긴 가상 DOM을 생성한다. 가상 DOM은 실제 DOM의 가벼운 복사본으로 메모리상에 존재하며, Javascript 객체 형태로 존재한다. React는 항상 렌더링 이전 화면 구조와 렌더링 이후 화면 구조를 가진 두 개의 Virtual DOM 객체를 유지하고 있다. 이 두 Virtual DOM을 비교하여 변경된 부분만 실제 DOM에 반영한다. https://www.tpointtech.com/
가상 돔의 비교 과정에서는 diffing 알고리즘이 사용된다. 이전 Virtual DOM Tree와 새로운 Virtual DOM Tree를 비교해 Root 노드에서 시작해서 이전과 새로운 노드를 비교한다. 두 노드가 다른 유형이면 새 노드를 생성하여 기존 노드를 대체한다. 두 노드가 같은 유형이면 속성을 비교해 변경된 것이 있는지 확인하고 변경된 속성이 있는 경우에만 속성을 업데이트한다. 위와같은 방식으로 자식노드를 재귀적으로 비교한다. → 이러한 과정을 재조정(reconciliation)이라고 한다.
재조정을 통해 변경 사항이 파악되면, 해당 변경 사항만 실제 DOM에 반영하여 업데이트한다. 이 방식은 전체 DOM Tree를 재구축하지 않고, 필요한 부분만 빠르게 업데이트할 수 있다. 또한, React는 여러 상태 업데이트를 한 번에 수행할 수 있는 Batch Update 메커니즘을 통해 더욱 효율적인 렌더링을 가능하게 한다. 즉, Virtual DOM은 실제 DOM을 직접 조작하는 대신 간접적으로 조작하면서 렌더링 성능을 향상시킨다. 🔸 One-Way Data Binding
단방향 데이터 흐름을 통해 UI 상태를 예측할 수 있다. Javascript Web Application의 복잡도가 증가하면서 브라우저 메모리에 있는 여러개의 Javascript 객체와 화면에 있는 데이터를 일치시키기 매우 어려워짐. 화면에 보이는 데이터와 브라우저 메모리에 있는 데이터를 일치시키는 기법 Javascript(Model) → HTML(View)로 한 방향으로만 데이터를 동기화 HTML(View) → JS(Model)로의 직접적인 데이터 갱신은 불가능. 이벤트 함수(onClick, onChange, ...)를 통해 Javascript에서 HTML로 데이터를 변경해야 한다. 컴포넌트 간 단방향 데이터 바인딩은 부모 → 자식 컴포넌트로만 데이터가 전달되는 구조이다.(props) 🔸Hooks
함수형 Component에서 State와 생명주기 기능을 사용할 수 있도록 지원. 클래스형 컴포넌트애서 사용되는 생명주기 메서드 함수형 컴포넌트에서는 위의 생명주기 기능을 useEffect()로 대체 가능 Hook은 class 안에서는 동작하지 않으며, class없이 React를 사용할 수 있음. 반복문이나 조건문 혹은 중첩된 함수 내에서 hook을 호출하면 안된다. 만약 조건문이나 반복문안에서 훅을 사용하면, 특정 조건에따라 실행되지 않는 경우가 발생할 수 있고, 이는 렌더링 때마다 제일 처음 함수가 실행될 때 React가 기억해놓은 hook의 호출 순서가 꼬여서 실행될 것이고 이는 버그를 초래한다. React hook은 호출되는 순서에 의존한다. React 함수 내에서만 Hook을 호출해야한다. hook은 일반적인 js 함수에서는 호출하면 안된다. 함수형 컴포넌트나 custom hook에서는 호출 가능하다. 현재 상태를 나타내는 state 와 상태를 변경하는 setState 를 같이 제공. state는 초기값을 설정할 수 있으며, 초기값은 첫 렌더링 때 한번 사용. state는 여러 타입의 값을 넣을 수 있다. 기존 클래스형 컴포넌트에서 사용했던 componentDid{Mount, Update, Unmount}를 하나의 API로 통합한 것. useEffect(function, deps)의 형태를 사용 function에는 실행시킬 함수, deps에는 의존성 배열 의존성 배열이 어떤 것인지에 따라 부수적 효과 함수가 실행된다. 의존성 배열 없이 useEffect를 실행시키게 되면 페이지가 렌더링 될 때마다 데이터를 불러온다. 의존성 배열에 빈배열을 담아주면, 첫 렌더링 시에만 함수를 실행한다. 의존성 배열에 state 값이나 props로 상속받은 데이터 값 등을 담아주게 되면 해당 값이 변할 때마다 함수를 실행한다. action → 함수형 프로그래밍에서 코드내에서 자주 바뀌는 것(effect) data → 함수형 프로그래밍에서 코드내에서 자주 바뀌지 않는 것 코드에서는 data의 조합이 많을수록 코드를 읽기 쉽고 변경에 용이하다. 항상 코드를 작성할 때 action을 꼭 사용해야 하는지에 대한 고민은 필수 특정 DOM에 접근하여 DOM 조작을 가능하게 하는 hook. js에서는 getElementById, querySelect, querySelectAll 등을 사용하는 반면, React에서는 ref를 사용해 특정 DOM을 선택할 수 있다. 메모이제이션과 관련이 있어, 성능 개선을 위해 많이 사용된다. 메모이제이션 → 기존 수행 결과를 어딘가에 저장해두었다가, 동일한 입력이 들어오면 재활용. useMemo는 메모이제이션된 값을 반환하는 hook useCallback은 메모이제이션된 함수를 반환하는 hook 만약, useEffect의 사용이 잦은 경우 어떤 effect가 mount되었을 때 사용되는지 혹은 어떤 effect를 참조하는지 코드를 추적하기 어려울 수 있다. custom hook은 반드시, 함수의 이름에 use를 붙여야한다. 🔸React Server Components(RSC : React 18+)
CSR(Client Side Rendering) 페이지 진입 시 HTML, JS 그리고 모든 데이터가 로드되고 컴포넌트 렌더링이 끝나기 전까지 사용자는 아무런 기능이 없는 빈 화면만 보게 된다. js bundle의 용량이 크거나 사용자의 네크워크 속도가 느릴수록 더 심하다. SSR(Server Side Rendering) 클라이언트 애플리케이션의 js 파일을 서버에서 먼저 HTML로 렌더링 한다. 페이지가 정상적으로 동작하기 위해서는 js bundle이 모두 다운로드되고, hydration(서버에서 미리 렌더링된 HTML을 클라이언트에서 React가 다시 활성화하는 과정)이 완료되어야 한다. 하지만, SSR은 빈 화면 대신 데이터가 존재하는 HTML을 제공함으로써 무거운 js 파일이 다운로드되는 동안 사용자에게 의미 있는 콘텐츠를 제공할 수 있다. 즉, SSR의 가장 큰 목적은 상호작용이 필요없는 클라이언트 컴포넌트를 최대한 빠르게 브라우저에 전달해, 초기 페이지 렌더링 속도를 향상시키는 것. RSC의 컴포넌트 코드는 클라이언트로 전달되지 않는다. SSR의 모든 컴포넌트 코드는 js bundle에 포함되어 클라이언트로 전송된다.
RSC는 페이지 레벨에 상관없이 모든 컴포넌트에서 서버에 접근할 수 있다. SSR은 가장 최상위 레벨의 페이지에서만 서버에 접근할 수 있다.
RSC는 클라이언트 상태를 유지하며 refetch될 수 있다. RSC는 HTML이 아닌 특별한 형태로 컴포넌트를 전달하기 때문에 필요한 경우 포커스, 인풋 입력값 같은 클라이언트 상태를 유지하며 여러 번 데이터를 가져오고 리렌더링하여 전달할 수 있다. SSR은 HTML로 전달되기 떄문에 새로운 refetch가 필요한 경우 HTML 전체를 리렌더링 해야하며 이로 인해 클라이언트 상태를 유지할 수 없다.
🔶 JSX(Javascript XML)
반드시 부모 요소가 하나 감싸는 형태여야 한다. Javascript 표현식을 작성하기 위해서는 JSX 내부에서 {}로 감싸주면 된다.
React
