리액트 불변성의 가지는 의의는 중요해서
velog에 적어보겠다.
리액트에서 리렌더링 기준
리액트에서는 화면을 리렌더링 할지 말지를 결정할 때
state의 변화를 확인한다.
state가 변했으면 리렌더링 하는것이고 state가 변하지 않았으면 리렌더링을 하지 않는다.
state 값의 변화 기준
그 때, state가 변했는지 변하지 않았는지 확인하는 방법이
state의 변화 전 후의 메모리 주소를 비교한다.
그래서 만약 리액트에서 원시데이터가 아닌 데이터를 수정할 때
불변성을 지켜주지 않고 직접 수정을 가하면
값을 바뀌지만 메모리 주소는 변함이 없기 때문에
리액트는 state가 변했다고 인지하니 못하게 된다.
그래서 결국 리렌더링이 일어나지 않는다.
원시 데이터의 경우 불변성을 가지기 때문에 문제가 되지 않지만
객체나 배열같은 경우에는 불변성을 가지지 않기 때문에
배열의 경우(객체 포함)
배열을 setState할 때 (내용을 바꾸게 된다면)
push() 라는 식으로 값을 추가하는게 아니라
불변성을 지켜주기 위해 전개연산자를 이용
let newArray = [...aray,추가할 값]이런 형태로
새로운 배열을 만들어 값을 추가하여야한다.
리액트에서 렌더링이란?
컴포넌트가 현재 props와 state의 상태에 기초하여 UI를 어떻게 구성할 지 컴포넌트에게 요청하는 작업을 의미한다.
랜더링 트리거
렌더링이 발생하는 경우
1. 첫 리액트 앱을 실행했을 때
2. 현재 리액트 내부에 어떤 상태에 변경이 발생했을 때
- 컴포넌트 내부 state가 변경되었을 때
- 컴포넌트에 새로운 props가 들어올 때,
- 상위 부모 컴포넌트에서 위의 두 이유로 렌더링이 발생했을 때 자식들의 컴포넌트도 렌더링이 발생한다(위에서 아래로 흐름)
리액트 앱이 실행되고 첫 렌더링이 일어나면 리액트는 컴포넌트의 root에서 시작하여 아래쪽으로 쭉 훑으며 컴포넌트가 반환하는 JSX결과물을 DOM요소에 반영한다.
만약 여러 상태가 변경됐다면 리액트는 이를 큐 자료구조에 넣어 순서를 관리한다.
추가로 리액트를 배우는 이유!
리액트의 탄생
- 당시 웹 개발에서는 복잡한 사용자 인터페이스 UI를 효과적으로 관리하는 것이 어려웠음
- 웹 자체의 크기가 커지면서 꽤나 많은 문제들이 생김
리액트 특징
기술적 관점
- 가상 DOM
- Routing 이점 => 브라우저 위에서 모바일앱처럼 동작
개발 경험 관점 - 컴포넌트 기반
UI를 독립적이고 재사용 가능한 여러 컴포넌트로 분리함으로써, 대규모 애플리케이션의 개발과 유지보수를 용이하게 한다. - 선언적 접근
명령형 프로그래밍은 '어떻게' 작업을 수행해야 하는지에 초점을 맞추지만
선연형 프로그래밍은 '무엇을' 작업해야하는지에 초점을 맞춘다.
작업의 목표에 초점을 맞추며, 내부 구현은 감추고 무엇을 해야 하는지만을 선언한다.
