State는 뭘까?
state는? = 변화하는 데이터?
- 화면에서 눈에 보이는 모든 데이터
- 눈에 보이지 않지만 기능을 작동시키기 위해 숨겨진 저장되어있는 데이터
- 데이터의 호출이 로딩/성공/에러 등등의 상태
- 리액트는 data binding을 대신 해주기 때문에 직접 DOM에 접근하지 않아도 됨
- UI에 동적으로 표현되는 데이터, 사용자의 액션에 따라 변경될 수 있는 컴포넌트의 부분을 나타내는 자바스크립트의 객체
- state를 사용하면, 자동으로 관련된 화면을 리렌더링 해줄 수 있음
cf) 데이터 바인딩: 제공자와 소비자로부터 데이터 원본을 결합시켜 이것들을 동기화 시키는 기법 그러니깐, 데이터를 화면(view)에 넣어주는 역할, 자바스크립트 객체와 화면에 있는 데이터를 일치
그. 런. 데 데이터는 계속 변경됨
그래서 상태관리가 필요함
상태관리란?
여러 컴포넌트간의 데이터 전달과 이벤트 통신을 한 곳에서 관리하는 것을 의미
- 사용하는 컴포넌트는 다른데, 사용하는 데이터가 서로 연결되어 있는 경우가 많음
- 프론트엔드 개발자는 유저에게 UI/UX를 제공하고, 유저와 데이터를 주고 받기도 함
따라서 - 유저와의 상호작용(interacton)을 위해, 상태를 조작하고 다루는 모든 작업을 상태 관리라고 함
상태관리가 중요한 이유?
언제든지 유저의 상호작용과 화면의 변화에 따라 지속적으로 변화가 가능 서비스가 방대해진다면 상태가 '언제, 어디에서, 왜'를 알기어려움 따라서 상태관리가 필요함
상태관리를 하지 않을경우?
- 불필요한 리렌더링의 발생
- 의도하지 않은 UI/UX
- 유지보수가 어려워짐
나아가 유저들은 즉각적인 상호작용과 더 나은 UX를 원하게 되면서, SPA가 등장(single page application)
- DOM에 접근없이도 데이터가 변경되면 값이 변경
- 따라서 DOM 중심이던 상태관리 로직이
- 데이터 중심의 상태관리 로직으로 변경
- 따라서 어디에서 상태가 변경되었는지 추적이 유리
cf) UI/UX 도대체 그게 얼마나 중요하지?
user interface: 눈에 보이는 디자인
user experience: 사용자가 겪는 다양한 경험
- 사용자가 편리하도록 UI를 디자인해서 더 나은 사용자 경험을 제공하는 것리액트 이전에는 상태관리가 없었나? 상태관리 했음
- 과거에도 'data-'속성을 사용해서 상태관리를 하긴 했음
- 그러다보니, DOM 중심의 상태관리 로직이 되는데 이는 상태의 변화를 추적하기 어려워짐
이왕 리액트 데이터 흐름을 보자 !
리액트는 단방향(하향식) 데이터 흐름
상위 컴포넌트 state -> 하위 컴포넌트 props-
하위 컴포넌트는 props를 전달받으면서, 누구로부터 어떤방식으로 전달되는지 전혀 알 필요가 없음
-
그래서, state = 캡슐화 (=> state를 가진 컴포넌트 외에는 접근이 어렵기 때문)
cf) 왜 상위 컴포넌트는 state고 vs. 하위 컴포넌트는 props일까?
state는 state를 가지고 있는 해당 컴포넌트에서 관리
props는 state를 자식 컴포넌트에 넘겨주면 그게 props가 됨(즉, 읽기전용 데이터)일반적으로 state를 생성하고, state를 갱신하기 위해(new state) setState를 사용함
Q) 어? 근데 데이터(state)를 변화시키는 것과 state가 무슨상관?(근본적인 의문이었어야 함)
- state가 변경되면 re-render가 되기 때문
- state가 setState를 통해 데이터를 변경할 때 re-render됨
Q) 그러니깐 왜 하필 setState야?
- state를 직접적으로 변경하는 경우, 새로운 state로 화면이 업데이트 되지 않기 때문
Q) 왜?
(리액트 라이프 사이클 흐름이...그렇게...)
- 화면이 업데이트 되려면, reder함수가 실행되어야 하는데, setState는 component update process를 trigger함
- 따라서, setState를 사용해서 state를 변경해야 리액트가 state가 변경된 것을 인식
setState?
- setState를 통해 state를 변경
- 리액트가 state가 변경되었다는 사실을 감지
- 이제서야 화면을 리렌더
setState의 비하인드 스토리
state를 바로 갱신하지 않음(바로 업데이트 되지 않음)
- state 변경사항을 대기열에 넣어뒀다가 컴포넌트에게 '새로운 state를 사용해야되니깐 리렌더 해야해!' 라고 알림(요청) - 알고보니 비동기적
cf) setState가 동기적이라면?
- 이벤트가 발생하고, 자식 컴포넌트 리렌더, 부모컴포넌트 리렌더, 부모컴포넌트 리렌더 됐으니까 또 자식컴포넌트 리렌더
- 성능저하ㅠㅠ
- 따라서 리액트는 성능향상을 위해 일부로 setState의 실행을 지연시키고 여러 컴포넌트를 한번에 갱신함(=배치처리 함)
즉, setState를 연속적으로 호출하면, setState를 모아서 배치처리하고 리렌더!
const [state, setState] = useState(initialState);- useState는 리렌더시 갱신된 배열의 첫번째 요소인 최신 state를 반환
Q) 엇...? 근데, const는 상수 = 값이 변경되지 않는거 아님?
- setState를 통해 state를 변경하는 것이 아니라, useState함수 안에서 접근할 수 있는 변수 값을 변경
- useState내부에는 접근할 수 있는 변수의 값을 update해주고, 이를 배열에 나눠서 반환해 줌
리액트에서 하위 컴포넌트로 state를 props로 전달을 무한 반복하기 때문에 prop drilling이 발생했고, 이 때문에 Redux등장
ㅋㅋㅋㅋㅋㅋ상태관리 라이브러리 공부하게 만든게....상태 너였꾸나 ! 짜식....잡았다 요놈
[출처]
