위 코드에서 `this.state`라는 부분이 나오는데 이 부분이 바로 현재 컴포넌트의 state를 정의하는 부분이다.
클래스 컴포넌트의 경우 `state`를 생성자에서 정의하고, 함수 컴포넌트는 `state`를 `useState()`라는 훅을 사용해서 정의한다.
`state`는 정의된 이후 직접적인 변경이 불가능하다. (`setState()` 함수를 통해 수정해야 함)
생명주기
Lifecycle method, 생명주기 함수
https://soldonii.tistory.com/113
Mounting (출생)
https://soldonii.tistory.com/113
컴포넌트가 생성되는 시점, 이 과정을 `Mount (마운트)` 라고 한다.
이때 컴포넌트의 `constructor(생성자)` 가 실행된다. 생성자에서는 컴포넌트의 state를 정의하게 된다.
또한 컴포넌트가 렌더링되며 이후에 `componentDidMount()` 함수가 호출된다.
Rendering(렌더링): 컴포넌트의 props와 state의 상태에 기초하여 UI를 어떻게 구성할지 컴포넌트에게 요청하는 작업, 쉽게 말해 해당 컴포넌트를 다시 실행한다고 생각하면 된다. 렌더링이 발생하면 선언부에서 초기화 한 값으로 변경되고, 렌더링의 발생 조건은 컴포넌트가 가지고 있는 값이 변경될 때이다. 그래서 `state`를 사용해야하고, 그 외에 다른 것들은 값이 고정되어 있어야 한다. (리액트의 순수성) https://react.dev/learn/keeping-components-pure
렌더링이 왜 필요한가? 1. UI 상태 관리의 복잡성 해결: 전통적인 방법으로는 DOM을 직접 조작하면서 모든 변경사항을 관리해야 함 2. 가상 DOM: 가상 DOM은 실제 DOM의 가벼운 복사본으로, 상태 변화가 있을 때마다 새 가상 DOM을 생성하고 이전 가상 DOM과 비교하여 실제 DOM을 최소한으로 업데이트 한다. (참고: https://namaniflow.tistory.com/292) 3. 컴포넌트 기반 아키텍처: 리액트는 UI를 재사용 가능한 컴포넌트로 분리해서 개발할 수 있게 하는데, 각 컴포넌트는 독립적인 상태와 렌더링 로직을 갖고 있다. 때문에 변경이 필요한 부분만 업데이트 되도록 한다. 4. 데이터 흐름과 상태 관리: 리액트는 단방향 데이터 흐름을 지향한다. 즉, 상태가 변경되면 그 상태를 기반으로 컴포넌트를 다시 렌더링하여 UI를 업데이트 한다. state와 UI가 항상 일치하게 유지된다. 5. 성능 최적화: 가상 DOM을 통해 불필요한 DOM 업데이트를 피하고, 최적의 방법으로 UI 업데이트 가능하다.
Updating
https://soldonii.tistory.com/113
컴포넌트의 props가 변경되거나 setState() 함수 호출에 의해 state가 변경되거나, forceUpdate()라는 강제 업데이트 함수 호출로 인해 컴포넌트가 다시 렌더링 된다.