1. 상태관리
✍ 전역 상태 관리
상태란?
- 변하는 데이터
- UI에 동적으로 표현될 데이터
Side Effect란? (상태를 다룰 때 Side Effect는 주요 고려 대상)
- 함수(또는 컴포넌트)의 입력 외에도 함수의 결과에 영향을 미치는 요인을 사이드 이팩트라 한다.
- 대표적으로 네트워크 요청(API 요청)이 있다.
- Side Effect를 최대한 배제하고 컴포넌트를 만들어야 한다.
상태의 2가지 구분
- 로컬 상태 :
- 특정 컴포넌트 내에서만 관리되는 상태.
- 컴포넌트 내에서만 영향을 끼치는 상태.
- 다른 컴포넌트와 데이터를 공유하지 않는 폼(form) 데이터는 대부분 로컬 상태이다.
- ex) input box, select box, radio button 등
- 전역 상태 :
- 프로덕트 전체 or 여러 컴포넌트에서 관리되는 상태
- 다른 컴포넌트와 상태를 공유하고 영향을 끼치는 상태.
- 전역 변수를 남용하는 것은 좋지 않지만, 경우에 따라 전역 상태가 필요하다.
- 서로 다른 컴포넌트가 사용하는 상태의 종류가 다르면 서로 다른 출처가 있어도 상관 없으나, 서로 다른 컴포넌트가 동일한 상태를 다룰 때에는 하나의 출처(=전역 공간)이어야 한다.
- ex) 로딩(Loading), 로그인 유무, 라이트 모드/다크 모드, 국제화(Globalization) 등
전역 상태에서 데이터 무결성
- 데이터 무결성이란? : 데이터의 정확성을 보장하기 위해 데이터의 변경이나 수정 시 제한을 두어 안정성을 저해하는 요소를 막고 데이터 상태들을 항상 옳게 유지하는 것.
- Single source of truth(신뢰할 수 있는 단일 출처) : 동일한 데이터는 항상 같은 곳에서 데이터를 가지고 온다.
✍ 상태 관리를 위한 각종 툴
상태 관리 툴
- React Context
- Redux
- MobX
상태 관리 툴을 사용하면 좋은 점
- 전역 상태 저장소를 제공
- Props drilling(프로퍼티 내려꽂기) 이슈를 해결
✍ Props Drilling
상위 컴포넌트의 state를 props를 통해 하위 컴포넌트(전달하고자 할 컴포넌트)에 전달할 때, props를 전달하는 용도로만 쓰이는 컴포넌트들을 거치면서 데이터를 전달하는 것을 말한다.
Props Drilling 문제점
- 코드 가독성이 나빠진다.
- 코드 유지보수가 힘들어진다.
- React는 state를 변경할 때 리렌더링이 된다는 특징이 있는데, state가 변경될 시 props 전달 과정에서 불필요하게 관여된 컴포넌트들 또한 리렌더링이 발생한다. 👉 웹 성능에 악영향을 미칠 수 있음
Props Drilling 해결법
- 컴포넌트와 관련있는 state는 될 수 있으면 가까이 유지.
- 상태관리 라이브러리를 사용. 상태관리 라이브러리를 사용하게 되면 전역으로 관리하는 저장소에서 직접 state를 꺼내쓸 수 있기 때문에 Props Drilling을 방지할 수 있음.
2. 리덕스(Redux)
✍ Redux란?
리덕스는 리액트 상태 관리 라이브러리로, 가장 많이 사용되고 있는 상태 관리 라이브러리이다.
✍ Redux의 구조
- 상태가 변경되어야 하는 이벤트가 발생하면, 변경될 상태에 대한 정보가 담긴 Action 객체 생성.
- Action 객체: Dispatch 함수의 인자로 전달.
- Dispatch 함수: Action 객체를 Reducer 함수로 전달.
- Reducer 함수: Action 객체의 값을 확인하고 그 값에 따라 전역 상태 저장소 Store의 상태를 변경. 상태가 변경되면 화면을 리렌더링.
(1) Store
상태가 관리되는 오직 하나뿐인 저장소
- createStore 메서드로 Reducer를 연결해서 Store를 생성
import { createStore } from 'redux';
const store = createStore(rootReducer);(2) Reducer
Dispatch에서 전달받은 Action 객체의 type 값에 따라서 상태를 변경시키는 함수
- Reducer는 순수함수여야 한다. 외부 요인으로 인해 원하는 값이 아닌 다른 값으로 상태가 변경되는 일이 없어야하기 때문이다.
- 여러 개의 Reducer를 사용하는 경우, Redux의 combineReducers 메서드를 사용해서 하나의 Reducer로 합쳐 사용할 수 있다.
const count = 1
// Reducer를 생성. 인자로는 초기상태와 액션이 있음.
const counterReducer = (state = count, action) => {
// Action 객체의 type 값에 따라 분기
switch (action.type) {
case 'INCREASE':
return state + 1
case 'DECREASE':
return state - 1
case 'SET_NUMBER':
return action.payload
// 해당 되는 경우가 없을 땐 기존 상태를 리턴
default:
return state;
}
}(3) Action
어떤 액션을 취할 것인지 정의해 놓은 객체
- type 은 필수로 지정
- 액션 객체는 대문자와 Snake Case로 작성
- 필요에 따라 payload 를 작성해 구체적인 값을 전달
// payload가 필요 없는 경우
{ type: 'INCREASE' }
// payload가 필요한 경우
{ type: 'SET_NUMBER', payload: 5 }- 보통 Action을 직접 작성하기보다는 Action 객체를 생성하는 함수를 만들어 사용하는 경우가 많다.
- 이러한 함수를 액션 생성자(Action Creator)라고도 한다.
// payload가 필요 없는 경우
const increase = () => {
return {
type: 'INCREASE'
}
}
// payload가 필요한 경우
const setNumber = (num) => {
return {
type: 'SET_NUMBER',
payload: num
}
}(4) Dispatch
Reducer로 Action을 전달해주는 함수
- Action 객체를 전달받은 Dispatch 함수는 Reducer를 호출
// Action 객체를 직접 작성하는 경우
dispatch( { type: 'INCREASE' } );
dispatch( { type: 'SET_NUMBER', payload: 5 } );
// 액션 생성자(Action Creator)를 사용하는 경우
dispatch( increase() );
dispatch( setNumber(5) );✍ Redux Hooks
- useDispatch(): Action 객체를 Reducer로 전달해 주는 Dispatch 함수를 반환하는 메서드
- useSelector(): 컴포넌트와 state를 연결하여 Redux의 state에 접근할 수 있게 해주는 메서드
✍ Redux의 세 가지 원칙
-
Single source of truth
동일한 데이터는 항상 같은 곳에서 가지고 와야 한다. 즉, Redux에는 데이터를 저장하는 Store라는 단 하나뿐인 공간과 연결되어 있다는 것. -
State is read-only
상태는 읽기 전용이다. React에서 상태 갱신 함수로만 상태를 변경할 수 있었던 것처럼, Redux의 상태도 직접 변경할 수 없다. 즉, Action 객체가 있어야만 상태를 변경할 수 있다는 것. -
Changes are made with pure functions
변경은 순수함수로만 가능하다. 상태가 다른 값으로 변경되는 일이 없도록 순수함수로 작성되어야하는 Reducer와 연결된다는 것.
UI·UX Designer/Frontend Dev