57 :: 상태 관리, Flux Pattern, 상태 관리 Hooks

엘리스 SW 엔지니어 트랙 57일차

온라인 강의날

 

 

상태 관리

데이터를 저장하고 하나 이상의 컴포넌트에서 데이터 공유하는 것

컴포넌트 안, 여러 컴포넌트 간의 상태 등 모두 상태 관리라 그런다

 

MPA 상태 관리

서버의 데이터로 페이지 렌더링하기 때문에

클라이언트 데이터와 서버 데이터 큰 차이 없다

 

SPA 상태 관리

클라이언트 데이터와 서버 데이터가 많이 다르다

 

 

Why 상태 관리?

데이터가 많아지고, 유저와 상호 작용하는 데이터가 많아지며

백엔드와의 데이터 통신도 고려해야 한다(ex. GraphQL)

 

장점

높은 품질 코드 작성에 유리

성능, 네트워크 최적화

데이터 관리 고도화(예: localStorage 활용한 persist state)

 

단점

Boilerpate 문제

파악해야 할 로직, 레이어 많다

잘못 사용하면, 앱 복잡도 높이고, 성능 악화

(global state 잘못 사용하면 앱 전체 다시 렌더링된다)

 

 

상태 관리 이점

SPA에서 페이지 로딩할 때 마다 모든 데이터 가져오면 MPA 넘어서기 힘들다

변경이 많은 데이터 아니라면, 데이터 캐싱하고 재활용

변경이 많다면, 변경 시점 파악해서 최적화

(일정 시간마다 서버에 저장, 타이핑 5초 후 서버에 저장 등)

 

Prop Drilling

하위 컴포넌트에 데이터 보내기 위해 상위 많은 컴포넌트가 있다면

Prop들을 드릴링해서 들어가지 않고, Context API 사용할 수 있다.

컴포넌트간의 결합을 줄여주는 것

 

 

MVC Pattern

View에서 데이터 업데이트하면 연쇄적인 업데이트 일어난다

앱이 커지면 업데이트 흐름 따라가기 힘들다

 

 

Flux는 하나의 액션이 하나의 업데이트만 만들도록 한다

Flux Pattern

웹 애플리케이션 아키텍처 패턴

Unidirectional data flow(일방향 데이터 흐름)

redux, react-redux 라이브러리 전에 나온 패턴

 

Flux 구조

Action => Dispather => Store => View 데이터 흐름

• Store: 미리 dispatcher에 callback 등록, 처리할 action 정의
• Action creator: action 생성해서 dispatcher로 보낸다
• Dispatcher: action을 store로 넘긴다
• Store: action에 따라 데이터 업데이트하고, 관련한 view 변경 이벤트 발생
• View: 데이터 다시 받아와 새로운 UI 렌더링

유저 인터렉션 발생하면 View는 action 발생

 

Flux 구조 by elice

 

 

상태 관리에 사용하는 Hooks

 

useState

하나의 상태 관리하기에 적합

state 바뀌면 state 사용하는 컴포넌트 다시 렌더

useEffect와 state에 반응하는 Hook 만든다

 

state를 넘기기만 하는 컴포넌트 모두 다시 렌더링된다

상태 변화가 단순하거나, 작은 앱에 적합

 

 

useRef

상태가 바껴도 다시 렌더링하지 않는 상태 정의

UI 변경과 관계없을 때 사용한다

(setTimerout의  imerId 저장 등)

리렌더링 최소화 하는 관리에 사용

 

 

useContext

컴포넌트간 상태 공유할 때 사용

Context Provider 안에서 렌더링되는 컴포넌트는

useContext 이용해서 바로 context value 가져온다

context value 바뀌면 내부 컴포넌트 전부 리렌더링된다.

 

useReducer와 함께 복잡한 상태 관리

필요한 곳에만 state를 사용해서, 불필요한 렌더링 방지

 

 

useReducer

useState보다 복잡한 상태 다룰 때 사용

const [state, dispatch] = useReducer(reducer, initState)

flux pattern 기반한 상태 관리 구현