💡 물어보는 이유?

JavaScript는 디버깅과 관려된 내용때문에 물어보는 것이 많았다.
React는 진짜 실무를 잘 할 수 있는지 평가하는 내용들이 많다.

1. 기술적 지식과 이해도 : 지원자가 React와 관련된 핵심 개념을 이해하고 있는지 확인하기 위함입니다. 이는 기본적인 state와 props의 이해에서부터 더 복잡한 개념인 컴포넌트 라이프사이클, React Hooks, 또는 상태 관리 라이브러리의 이해도를 확인하는 데 필요합니다.
(내가 프로젝트에 사용한 라이브러리에 대해서 리드미를 보면 이 라이브러리가 왜 나왔는지를 알 수 있다. 미리 알고 가자)
2. 문제 해결 능력 : 실제 개발 시나리오를 기반으로 한 질문을 통해, 지원자가 복잡한 문제를 어떻게 해결하는지, 어떤 접근 방식을 사용하는지 파악하기 위함입니다. 신입 개발자라고 해도, 실제 문제를 해결하는 데 필요한 기본적인 능력과 새로운 것을 배우고 적용하는 능력이 중요합니다. 이런 능력을 평가하기 위해 기본적인 문제 상황을 제시하고, 어떻게 해결할 것인지 물어볼 수 있습니다.
3. 경험과 학습 능력 : 지원자가 이전에 특정 기술을 사용한 경험이 있는지, 새로운 기술을 배우고 적용하는 능력이 있는지를 확인하기 위함입니다. 신입 개발자라면, 주어진 학습 자원 및 시간을 어떻게 활용하여 기술을 습득하고 발전시켰는지 확인하는 것도 중요합니다. 이를 통해 지원자의 자기 주도적 학습 능력과 열정을 파악할 수 있습니다.
4. 성능 최적화 이해도 : React를 이용한 웹 개발에서 성능은 중요한 이슈입니다. 지원자가 이에 대한 이해도를 가지고 있으며, 필요한 경우 성능을 최적화하는 방법을 알고 있는지를 확인하기 위함입니다.

들어가기 전

React를 포함한 모든 기술 (react-query, redux, mobx, babel, vite, etc ...)은 필요에 의해 만들어 졌다.
사실 Reac를 알기 위해 알아야 할 것들이 너무 많지만, 어떤 이유에서 React가 시작되었는지를 이해하면 그 후의 과정들을 학습하는 데 더 깊게 이해할 수 있을 것이다.

React는 사용자 경험을 향상시키기 위해 만들어진 라이브러리이다. 그 이유는 화면을 갱신하는 작업을 효율적이고 빠르게 하기 위함인데, React는 Virtual DOM을 도입하여 이 문제를 해결했고, 이로 인해 우리는 페이지 전체를 다시 로드 하지 않고도 사용자 인터페이스를 부드럽게 업데이트할 수 있게 되었다.

학습목표 : React와 그 주변 생태계

• 어떻게 사용하는지
• 왜 이런 기술이 필요했는지
• 이 기술이 어떤 문제를 해결하려고 했는지에 대한 배경

이 항목들을 이해하는것이 중요하다. 추후에 적절한 상황에 잘 적용하게 될 것이다.

VDOM (짝꿍 SPA ~ DOM API)

• React 팀 입장에서 DOM으로 변환 될 간단한 객체를 만들기 위해 VDOM (객체) 개발
• 헬퍼함수 createElement를 만들었는데 그대로 사용하면 사용자가 없을거 같아 익숙한 구조의 새로운 표현 방법을 개발
• createElement 함수 호출 구문으로 변환이 되게 해주는 프로그램을 이용해서 변환

(Context) Frontend의 발전 과정

1. 정적 웹페이지(HTML, CSS)

웹의 초기에는 HTML과 CSS가 주를 이루었습니다. 이 시기에는 웹 페이지가 정적이었으며, 사용자와의 상호작용이 거의 없었습니다.

2. 동적 웹페이지(JS의 등장!!)

JavaScript의 등장으로 웹페이지에 동적인 요소가 추가되었습니다. 이 시기부터 웹페이지는 사용자와 상호작용할 수 있게 되었습니다.

3. AJAX(비동기적인 통신을 할수 있다구?)

<!-- 옛날식 fetch -->
<form action="...api주소" method="post">
</form>

이 시기에는 AJAX(Asynchronous JavaScript And XML)의 등장으로 웹페이지가 부분적으로 업데이트될 수 있게 되었습니다. 이로 인해 페이지 전체를 다시 로드하지 않고도 사용자와 상호작용하는 웹 애플리케이션이 가능해졌습니다.

Google Maps가 약간 선두주자 느낌인데, 인터랙티브한 웹 애플리케이션의 가능성을 열어준 서비스입니다.

4. jQuery와 같은 라이브러리(2000년대 후반)

이 시기에는 jQuery와 같은 라이브러리가 등장하였습니다. 이 라이브러리들은 브라우저 간의 차이를 추상화하고, JavaScript를 더 쉽게 사용할 수 있도록 도와주었습니다. (DOM API를 사용하기가 너무 힘들었음)

5. MVC 프레임워크(2010년대 초반)

이 시기에는 AngularJS, Backbone.js와 같은 MVC(Model-View-Controller) 프레임워크가 등장하였습니다. 이 프레임워크들은 웹 애플리케이션 구조를 체계화하고 코드의 재사용성을 높이는데 도움이 되었습니다.

6. 컴포넌트 기반 프레임워크(2010년대 중반 ~ 현재보다 쪼금 전)

이 시기에는 React, Vue.js와 같은 컴포넌트 기반의 프레임워크 및 라이브러리가 등장하였습니다. 이들은 웹 애플리케이션을 재사용 가능한 컴포넌트로 분리하고, 상태 관리를 보다 쉽게 할 수 있도록 도와주었습니다.

7. 뭔가 다시 역행해버린듯한.. 신흥강자 Next의 등장? (현재 ~ )
Frontend챕터 Modern Rendering Patterns에서 더 알아봅니다

CSR(Client Side Rendering) 은 모든 렌더링을 클라이언트 측에서 처리합니다. 이는 서버의 부하를 줄이고 동적인 웹 애플리케이션을 만드는 데 유리하지만, 초기 페이지 로딩 속도가 느릴 수 있으며 SEO 문제가 있을 수 있습니다. 그래서 요즘에는 CSR과 SSR, SSG, ISR을 적절히 조합하여 사용하는 경우가 많습니다.

1. SSR(Server Side Rendering): SSR은 초기 페이지 로딩 속도를 빠르게 만들고, SEO 최적화에 좋습니다. 서버에서 페이지를 완전히 렌더링한 후에 HTML을 클라이언트에게 보내줍니다. 그래서 사용자는 빠르게 완성된 페이지를 볼 수 있습니다. 또한, 크롤러가 콘텐츠를 쉽게 파싱할 수 있어 SEO에 좋습니다.
2. SSG(Static Site Generation): SSG는 빌드 시점에 모든 페이지를 미리 생성합니다. 그 결과, 서버에 부담을 주지 않고 빠른 페이지 로딩 속도를 제공할 수 있습니다. 또한, 생성된 정적 파일을 CDN(Content Delivery Network)에 배포할 수 있어 전 세계 어디서나 빠른 속도로 콘텐츠를 제공할 수 있습니다.
3. ISR(Incremental Static Regeneration): ISR은 SSG의 장점을 유지하면서, 동적 콘텐츠를 효율적으로 처리할 수 있는 방법을 제공합니다. ISR은 필요에 따라 정적 페이지를 재생성하여 최신 상태를 유지하며, 이 과정은 백그라운드에서 이루어져 사용자 경험에 방해를 주지 않습니다. (SWR 방식 캐싱 무효화 전략)

DOM API는 SPA에 좋아 보이지 않는다

DOM (Document Object Model) API : 웹 초창기(1990년대 중반)부터 등장했다. 이는 웹 페이지의 내용을 프로그래밍적으로 조작할 수 있도록 해주는 인터페이스를 제공한다.

DOM API는 HTML과 XML 문서의 구조를 표현하는 표준 모델이며, 이를 통해 문서의 구조, 스타일, 내용 등을 동적으로 변경할 수 있다. JavaScript와 결합되면, 웹 페이지와 사용자의 상호작용을 가능하게 한다. (jQuery 등장전까지 좋았다)

1. DOM의 여러가지 문제점을 개선하기 위한 시도

• JQuery
  • DOM API를 사용하기 단순하게 만들어줄게 라고 하는 컨셉
  • 기본적으로 DOM을 쉽게 포장했을 뿐 근본적인 문제를 해결하진 못했다.

    여기서 React는 1타 n피를 위한 컨셉을 발견!
    DOM 자체를 쓰지 않는 것 ➡️ (VDOM 개발)웹 애플리케이션 개발의 패러다임이 획기적으로 바뀜

2. 작게 시작하기 (Minimum Viable Product)

많은 기능들을 담으려고 하지 않고 기본 틀만 작게 시작하자

• React는 DOM을 없애서 문제를 해결 함
• DOM의 문제점을 해결했다는 컨셉의 제품을 개발
• React의 MVP
  - DOM을 완전히 없애진 않고 mock이라는 가짜 DOM을 제공해서 real DOM과의 연결성 최소화

  초기 React의 목적 :
  SPA를 만듦에 있어서 모든 것을 제공하려는것이 아니라 user interface(UI) 부분만의 문제점을 해결하고 싶었음

3. 지금 문제점을 분석 해 보자!

위의 코드를 어떻게 하면 사용하기 쉽게 만들 수 있을까 지금 코드의 특징을 살펴보면?

• html
  • 모든 html 태그는 태그명, props들, n개의 자식들이 있다!
  • 태그와 attribute 그 안에 n개의 자식요소가 있다.
  • 문자열로 이루어져있다.
  • 문자열을 브라우저가 읽어서 DOM을 만든다.
• JS
  • DOM API를 이용해서 런타임중에 DOM을 그린다 (html을 생성한다)
  • DOM API를 가지고 조작할 떄에는 구조가 한눈에 들어오지 않는다.

    DOM API 불편하다. 구조가 한 눈에 들어오지 않는다.
    하지만 대체제가 없잖아요?

4. DOM 버리기

그렇다면 React개발자들은 어떤 생각을 했을까…?
DOM API를 모두 버릴 순 없지만 그럼에도 불구하고 버려보자!
어떻게?
➡️ 개발자에게는 ‘DOM’을 주지 말자
➡️ 우리가 DOM을 조작하는 것을 제공(VDOM)해주고 실질적인 제어는 React가 하자

본래 DOM 같은 경우도 그냥 문자열이었던 html파일을 Object로 만든 것이다. 브라우저 입장에서 다루기 까다로운 문자열로 되어있는 파일을 어떻게 하면 화면에 효과적으로 렌더링 시킬 수 있을지 생각했을 때, 문자열을 다루지 말자 라는 결론을 내렸고 문자열을 훨씬 다루기 쉬운 객체로 만들어 보자라는 아이디어에서 시작했다

• 다루기 까다로운 것을 다루기 쉬운 포맷으로 바꿔서 그 쉬운 포맷을 다루자!

5. 다뤄보자

DOM은 굉장히 복잡한 객체인데 어떻게 다뤄야 할까

1. 복잡한것은 간단한 것으로 바꾼다
복잡한 DOM 객체를 간단한 객체로 바꾸자
2. 간단한 객체를 다시 복잡한 DOM으로 바꾸는 무언가를 만들자

• html 마크업
  • tag는 n개의 자식을 가질 수 있다
  • tag는 n개의 attribute(props)를 가지고 있다
    • 각각의 attribute는 key value로 이루어져 있다
  • 각 tag는 이름이 있다

html 마크업을 객체로 변환해 보자
복잡한것은 간단한 것으로 바꾼다

// 이 객체 안에 어떤 모양으로 만들 것인가?
const vdom = {
  tag: 'ul',
  props: {},
  children: [],
};

// children안에는 vdom이 또 들어가질 것이다.
// 이 객체 안에 어떤 모양으로 만들 것인가?

<ul>
	<li><a><span></span></a></li>
</ul>
const vdom = {
  tag: 'ul',
  props: {},
  children: [
    {
      tag: 'li',
      props: {},
      children: [
        {
          tag: 'a',
          props: {},
          children: [{ tag: 'span', props: {}, children: [] }],
        },
      ],
    },
  ],
};

간단한 객체를 다시 복잡한 DOM으로 바꾸는 무언가를 만들자 : createDOM function

html :: <h1 className="greet">hello world</h1>
node : { tag: 'h1', props: { className: "greet" }, children: ['hello world'] }

function createDOM(node) {
// DOM은 트리구조 이므로 재귀함수 조건이 필요하다
//  if (typeof node === 'string') {
//    return document.createTextNode(node);
//  }

  const element = document.createElement(node.tag);
  // h1으로 된 element를 create

  node.children
    .map(createDOM)
    .forEach(element.appendChild.bind(element));

  return element;
}

• map 함수에게 재귀호출 패턴이라 createDOM을 그대로 준다
• createDOM은 element를 return 한다
• map 순회에서 돌려받은 element는 바깥 scope element의 자식요소가 되어야 한다
• appendChild 해줘야 하는데 map 에서 return 받은 element에 대한 context를 유지시켜주기 위해 bind를 사용한다

VDOM 만으로는 좀 불편해 보인다
➡️ element 뽑아주는 공장을 만들자 (createElement)

객체 생성 함수

VDOM 객체의 구조가 세개의 속성을 가지는 객체의 단순 반복이라는 생각에서 파보자.
결국 그 세개의 속성을 갖고 있는 객체를 생성하는 함수를 하나 만들면 그 함수를 반복 호출 하면서 구조를 만들어 낼 수 있다.

createElement('h1', {className: "hi"}, children : ['hello'])
export function createElement(tag, props, ...children) {
  return { tag, props, children };
}

children은 실제로 배열이 되어야 하기 때문에 createElement 자체에 가변인자를 만들어준다.

• 기존코드

const vdom = {
  tag: 'div',
  props: {},
  children: [
    {
      tag: 'h1',
      props: {},
      children: ['Hello, React!'],
    },
    {
      tag: 'ul',
      props: {},
      children: [
        {
          tag: 'li',
          props: {},
          children: ['첫 번째 아이템'],
        },
        {
          tag: 'li',
          props: {},
          children: ['두 번째 아이템'],
        },
        {
          tag: 'li',
          props: {},
          children: ['세 번째 아이템'],
        },
      ],
    },
  ],
};

• createElement를 통해 만든 VDOM

const vDom = createElement(
  'div',
  {},
  createElement('hi', {}, 'Hello, hi'),
  createElement(
    'ul',
    {},
    createElement('li', { style: 'color: blue' }, '첫 번쨰 가게 ㅋ'),
    createElement('li', { style: 'color: red' }, '두 번쨰 가게'),
    createElement('li', { style: 'color: yellow' }, '세 번쨰 가게')
  )
);

<ul>
  <li>1</li>
  <li>2</li>
  <li>3</li>
</ul>

const vDom = createElement(
  'ul',
  {}, // props
  createElement(li, {}, 1) // children
)

createElement 자체가 가변 인자를 처리하는 방법으로 되어있다보니, UI가 많아지면 굉장히 복잡해 질 것이다.
더 편리한 사용성을 제공하기 위해서 어떻게 해야할까? ➡️ JSX 등장

JSX

1. createElement 숨기기

초기에 개발시에 createElement 태그와 prop, children 객체를 만드는 함수를 하나 만 만들었을 것이다.
그러나 이 방식은 익숙치 않아서 잘 안쓰이게 될 것 같으니 익숙한 포맷으로 만들어 보자.

함수 호출 방법, markup 방법
형태는 html 태깅하듯이 코딩하면 내부적으로는 createElement 함수가 동작하는 식으로 만들기

2. React가 없어요

markup 방식을 사용해 만든 코드이다.

const vdom2 = (
  <p>
    <h1>React 만들기</h1>
    <ul>
      <li style="color: red">첫 번째 아이템</li>
      <li style="color: blue">두 번째 아이템</li>
      <li style="color: yellow">세 번째 아이템</li>
    </ul>
  </p>
);

// render(App, document.getElementedById('root'))
render(vdom2, document.querySelector('#root'));

• React is not defined
  webpack.config 를 보면 세팅이 다 되어있는데, js 파일은 babel-loader라고 하는 loader에게 전달 되게끔 되어있다.

@babel/preset-react란? 실제 바벨 플러그인 중 하나로, 자바스크립트 파일안에 포함되어 있는 JSX 즉, markup은 아니지만 실제로 같은 구조를 갖고있는 문법을 바꿔준다.
JSX ➡️ createElement

실제 변환된 코드를 보면 React.createElement라고 되어있는것을 확인할 수 있는데, 우리는 React를 import 해주지 않아서 위와 같은 오류가 나는 것이다.

• 그렇다면 어떻게 해결해야할까?
  import React from 'react'; 를 꼭 기입 해주어야 한다.

3. 호환성 맞추기

여전히 runtime 오류가 나는 상황에서 어떻게 해결해야 할까?
오류를 살펴보면 null이나 undefined를 convert 하지 못한다고 나와있다. 우리는 props를 빈 객체{}로 보내줘야 하는데 현재는 null로 보내지고 있는 상태이다.

• 우리가 만든 createElement 함수의 default 파라미터를 바꾸면 될까? No

  export function createElement(tag, props = {}, ...children) {
   return { tag, props, children };
  }

  이때 props의 값이 없을 때 {} 빈객체로 값을 설정하는 것은 props의 값이 undefined 일때만 잡을 수 있다. 따라서 현재는 null(object 취급)이 되어 작동하지 않는다.
• 방어 코드

  export function createElement(tag, props, ...children) {
   props = props ?? {};
   return { tag, props, children };
  }

  이 코드 처럼 방어 코드를 만들어 작동하게 했다.
  

4. 구조에 기인한 제약사항

createElement 라고 하는 함수를 호출하는 ‘코드’로 변환하는 방식에 기인한 제약사항 체크

import React from 'react';
import { /**createElement**/, render } from './react';

• createElement를 삭제하면 코드상에서 사용되고 있지 않지만, 런타임 에러가 난다.
• 트랜스파일러를 통해 JSX가 createElement 함수로 바뀌기 때문이다.

React에서도 이러한 예가 있다.

import React from 'react' 
// 항상 React를 import 해오지 않으면 문제가 생긴다.
// 왜 ? Build 된 파일에서 React.createElement 를 찾지 못하기 때문에

QnA

1. Virtual DOM이란 무엇인가?

Virtual DOM은 실제 DOM을 추상화한 개념으로서, 메모리에 가상으로 존재하는 DOM의 표현입니다. 이는 JavaScript 객체로서 존재하며, 실제 DOM과는 별도로 존재합니다.

2. Virtual DOM은 어떻게 작동하나요?

상태가 변경될 때(props나 state가 변경될 때) 마다 새로운 Virtual DOM 트리가 생성됩니다. 이 새로운 트리와 이전 트리를 비교하여(이를 Diffing 이라함), 실제 DOM에서 필요한 최소한의 변경사항만을 계산합니다. 이후, 이 변경사항을 실제 DOM에 반영하는 과정을 Reconciliation이라고 합니다.

3. Virtual DOM은 왜 필요한가? 이를 도입해서 어떤 문제가 해결되었나?

DOM 조작은(바닐라 자바스크립트) 비용이 많이 드는 작업이며, 특히 자주 발생할 경우 성능에 부정적인 영향을 미칠 수 있습니다.
Virtual DOM은 이런 문제를 해결하기 위해 도입되었습니다. 이를 통해, 실제 DOM에 직접적인 변경이 아니라,
Virtual DOM에 변경을 먼저 적용하고(렌더과정), 그 결과를 실제 DOM에 한 번에 반영함(커밋과정)으로써 성능을 향상시킵니다.

4. Virtual DOM과 Real DOM의 차이는 무엇인가요?

Real DOM은 웹페이지의 구조를 표현하는 실제 구조이며, 웹페이지에 직접적으로 반영되는 내용입니다.
반면 Virtual DOM은 메모리상에 존재하는 JavaScript 객체로서, 실제 DOM의 복사본 같은 역할을 합니다.

5. Reconciliation(조정)과 Diffing(차이 비교) 과정에 대해 설명해주세요.

Diffing은 두 개의 Virtual DOM 트리(커밋과정과 렌더과정의 Virtual DOM)를 비교하여 두 트리 간의 차이를 찾는 과정입니다.
이 차이는 diff라고 부르며, 이 diff를 사용해 실제 DOM을 업데이트하는 것이 Reconciliation 과정입니다.

6. VDOM은 어떤식으로 diffing 하나요?

React 에서 컴포넌트의 업데이트는 주로 두 가지 방법으로 트리거됩니다. 상태(state)의 변경과 속성(props)의 변경입니다.

• 상태의 변경 : useState 또는 this.setState(클래스 컴포넌트의 경우)를 사용하여 상태를 변경하면, React는 해당 컴포넌트를 리렌더링 합니다.
• 속성의 변경 : 부모 컴포넌트로부터 전달받은 속성이 변경되면, 해당 속성을 전달받은 자식 컴포넌트가 리렌더링 됩니다.

React 내부에서 이러한 변경을 감지하고, 필요한 컴포넌트를 재렌더링하기 위해 Reconciliation 프로세스를 수행합니다. 이는 새로운 Virtual DOM 트리와 이전 트리를 비교하여 둘 사이의 차이를 찾아내는 과정(렌더과정)인데, 이를 통해 실제 DOM에는 필요한 최소한의 변경만이 적용(커밋과정)되게 됩니다.

React의 Reconciliation 과정은 매우 효율적입니다. 이는 두 가지 가정에 기반합니다 :

1. 두 개의 다른 타입의 요소는 서로 다른 트리를 생성할 것이다.
2. 개발자는 key prop을 통해, 여러 렌더링 사이에서 어떤 자식 요소가 변경되지 않아야 할지 표시할 수 있다.

이러한 가정들을 React가 Diffing 알고리즘을 O(n)의 복잡도로 만들어, 성능을 향상시킵니다.
즉, React는 상태와 속성의 변경을 통해 컴포넌트의 업데이트를 트리거하고, 이를 통해 높은 효율성과 빠른 사용자 인터페이스를 제공합니다.

7. Virtual DOM이 항상 Real DOM보다 효율적인가요? 그 이유는 무엇인가요?

항상 그렇다고 말할 수는 없습니다. Virtual DOM이 성능을 향상시키는 경우는 여러 번의 작은 변경사항이 많이 발생할 때 입니다.
하지만 변화가 많이 없는 경우는 실제 DOM을 직접 조작하는 것이 더 효율적일 수 있습니다. (React를 사용하지 않을 때)
근데 React 쓰면 VDOM 다루는게 맞다.

8. Virtual DOM이 성능 향상에 어떤 역할을 하는지 설명해주세요.

Virtual DOM은 필요한 최소한의 변경만을 실제 DOM에 반영함으로써 성능을 향상시킵니다. 즉, 모든 변경사항을 즉시 실제 DOM에 반영하는 대신, 변경사항을 한꺼번에 모아서 처리함으로써 성능을 향상시킵니다.

re-rendering과 밀접한 관련이 있다

re rendering을 하는 과정

렌더링의 과정은 크게 세 가지 단계(Trigging, Render Phase, Commit Phase)로 나눌 수 있다. 그러나 기억할 점은 이 모든 과정이 동기적으로 이루어지지 않고 비동기적으로 이루어진다는 점이다. 이것은 React의 성능 최적화에 중요한 역할을 한다.

그렇다고(비동기라고 해서) Promise는 아님
➡️ 단지 해당 작업이 즉시 완료되지 않고, 시스템의 다른 부분이 해당 작업을 완료할 수 있도록 일부 시간을 기다린다는 것을 의미함

React의 Concurrent Mode에서는 렌더링 작업이 비동기적으로 이루어지도록 스케줄링 된다. 즉, 이 작업은 메인 스레드에서 끊어질 수 있고, 필요한 경우에 다시 시작될 수 있다. 이를 통해 브라우저가 동시에 다른 작업을 수행할 수 있는 시간을 확보하게 된다.

이러한 비동기 처리는 React의 Fiber 아키텍처에 기반합니다. Fiber는 React의 내부적인 유닛으로, 컴포넌트에 대한 작업을 나타낸다. React는 이런 Fiber들을 통해 렌더링 작업을 여러 작은 부분으로 나누고, 이를 병렬 처리하도록 스케줄링 할 수 있다.

그러나 이러한 비동기 처리는 사용자 코드 측면에서는 직접 관리하거나 제어할 수 있는 것이 아니다. 사용자는 setState나 useEffect와 같은 React API를 사용하여 상태 변경을 요청하고, 그러면 React는 이를 적절하게 스케줄링하여 처리합니다.

Fiber가 무엇인가?

• Fiber Node: Fiber는 React 애플리케이션의 각 컴포넌트를 나타내는 JavaScript 객체입니다. 이는 컴포넌트의 상태, 라이프사이클 등의 정보를 담고 있습니다. Fiber Node는 컴포넌트의 작업 단위를 나타냅니다.
• Fiber Tree: Fiber Node들은 Fiber Tree를 형성하게 됩니다. 이는 DOM 트리와 비슷하지만, 각 노드가 작업 단위인 Fiber로 이루어져 있습니다.
• Reconciliation and Rendering: Fiber 아키텍처는 두 단계로 작업을 나눕니다. 첫째, Reconciliation 단계에서는 새로운 Fiber Tree를 생성하고 diffing을 수행합니다. 둘째, Commit 단계에서는 실제 DOM에 변경사항을 반영합니다.
• Cooperative Scheduling and Concurrent Mode: Fiber는 작업을 중단하고 다시 시작하는 능력을 가지고 있습니다. 이를 Cooperative Scheduling이라고 하며, 이는 브라우저가 동시에 다른 중요한 작업을 처리할 수 있도록 합니다. 또한, 이를 통해 여러 개의 작업을 동시에 처리하는 Concurrent Mode가 가능해집니다.

1. Trigging

트리깅 단계는 상태 또는 속성의 변화를 감지하고 React에게 컴포넌트를 다시 렌더링하도록 지시하는 단계이다.
이는 setState 메서드 또는 useState 훅을 통해 수행될 수 있다. 또한, 부모 컴포넌트에서 새로운 props를 전달 받을 때도 이 트리깅 단계가 발생한다.

2. Render Phase

렌더 단계에서는 React가 컴포넌트 트리를 새롭게 생성하거나 갱신하게 된다. 이 때 생성되는 것은 실제 DOM이 아니라 Virtual DOM이다. 새로운 Virtual DOM 트리는 이전 트리와 비교될 것이며, 이는 변경사항(diff)을 파악하기 위함이다. 이 단계에서는 실제 DOM에 어떤 변화도 발생하지 않는데 이는 아직 변경사항을 계산하는 중이기 때문이다.

3. Commit Phase

커밋 단계에서는 실제 DOM이 업데이트 된다. 이 단계에서는 Reconciliation 과정을 거쳐 계산된 변경사항들이 실제 DOM에 반영된다. 이 과정을 통해 사용자는 UI의 변화를 볼 수 있게 되고 또한, 이 단계에서는 필요한 경우 라이프사이클 메서드들이 호출된다.

이 과정을 통해 React는 성능을 최적화하며, 빠른 사용자 인터페이스를 제공하게 됩니다. setState나 useState를 호출하거나 부모 컴포넌트에서 새 props를 전달받는 것으로 시작하여, 새로운 Virtual DOM 트리를 생성하고, 이전 트리와 비교하여 변경사항을 찾아내고, 그 변경사항을 실제 DOM에 반영하는 과정을 거칩니다. 이렇게 하여 React는 변화가 많은 애플리케이션에서도 뛰어난 성능을 유지합니다.