StateManagement.md

React에서 상태란?

• 컴포넌트 간에 이동되는 props와 달리 컴포넌트 내부에서 관리되는 자바스크립트 객체
• 어플리케이션의 화면 렌더링에 영향을 끼친다
• 사용자의 인터랙션을 통해 동적으로 변하는 데이터

관리 해야 하는 상태의 기준은?

• 서로 다른 컴포넌트에서 동일한 데이터를 다룰 때!

그럼 이럴 땐 상태를 왜 관리해줘야 하나요

• 서로 다른 컴포넌트에서 동일한 데이터를 다룰 땐, 해당 데이터의 출처가 동일해야 한다. 그래야 서로의 변화에 동적으로 반응할 수 있기 때문이다.
• 즉 상태의 일관성 (=”데이터의 무결성”)을 잘 지켜야한다.
• “Single Source of Truth”이라는 방법론이 이러한 상태의 일관성을 유지하기 위해 등장한 방법론인데, 말그대로 신뢰할 수 있는 단일 출처를 말한다. 이 방법론이 React가 택한 방법론으로, 결국 React에서 상태관리가 필요한 이유는 데이터의 무결성을 위해서, 서로 다른 컴포넌트에 분포되어있는 하나의 데이터가 서로 일치할 수 있도록 관리해주기 위함이다.

상태의 종류

• 지역 상태 : 컴포넌트 내부에서만 관리되는 상태
  • ex) Input을 통해 사용자 입력을 받아 상태를 업데이트하는 경우
• 컴포넌트 간 상태 : 여러 컴포넌트를 넘나들며 관리되는 상태
  • 부모 컴포넌트에서 자식 컴포넌트로 prop를 통해 전달한다 → 연속될 경우 “Prop Drilling”
  • ex) Modal창
• 전역 상태 : 프로젝트 전체에 영향을 끼치는 상태

Prop Drilling?

• props를 다른 컴포넌트로 전달하기 위해서 여러가지 컴포넌트를 거치는 방식을 말한다.
• 부모 컴포넌트 → 중간 컴포넌트1 → 중간 컴포넌트 2→ … → 최종 컴포넌트
• 부모 컴포넌트에서 최종 컴포넌트로 props를 전달하기 위해 중간 컴포넌트들을 거친다.
• 이 depth가 깊어질 수록 상태를 추적하기 어려워지기 때문에 무조건 Prop Drilling으로 props들을 불필요한 컴포넌트들을 거치도록 하지 않고 별도의 상태관리가 꼭 필요하다.

상태관리 라이브러리 분석

1. Context API

• 리액트의 컴포넌트 트리 내에서 전역 상태를 공유할 수 있는 방법
• 중간 컴포넌트에게 props를 넘기지 않고도 최종 컴포넌트에게 상태를 전달할 수 있다 (prop drilling 방지)
• 구성요소
  • Context : 전역 상태 저장소.
    • Context에 Provider와 Consumer가 저장되어있음
    • Consumer에는 Context를 통해 접근 가능
  • Provider : 전역 상태 제공자.
    • 저장소인 Context에 상태를 제공해주는 역할을 함
    • 상태를 제공받고자 하는 컴포넌트는 Provider 하위에 있어야함
    • 따라서 전역 상태로 쓸 경우, Provider는 App.jsx같은 루트 컴포넌트가 된다.
  • Consumer : 전역 상태 사용자
• 단점 :
  • 범위를 잘 정의해주지 않으면 불필요한 렌더링을 일으킨다

2. Redux

• 중앙 집중식 Storage와 상태 업데이트를 위한 Reducer를 사용함

• 단방향 데이터 흐름을 따른다.

• 장점 :

  • 오래된 만큼 탄탄한 커뮤니티와 개발자 풀 존재
  • 개발을 처음 시작할 때 참고할 수 있는 보일러플레이트가 굉장히 다양할 뿐만 아니라, 개발 중에 있어서도 버그가 생길 경우 해결하기가 쉬움
  • 미들웨어를 활용하여 여러 비동기, 로그 작업 등을 처리할 수 있는데 이 때 Redux를 위한 라이브러리를 사용하여 더 쉽게 구현 가능
  • 단방향 데이터 흐름을 따라서 Reducer 등의 단위 테스트가 비교적 쉬움

• 단점 :

  대부분 구조가 너무 복잡해서 문제가 생김

  • 간단한 웹앱을 만들 때에도 Action, Reducer, Action Creator 등의 코드를 모두 작성해야 함.
  • Recoil, MobX와는 달리 State가 변경 될 때 Component를 업데이트 해주는 반응형 메커니즘이 기본적으로 탑재되지 않아서 React의 자체 메커티즘을 활용하거나 추가적인 외부 라이브러리를 사용해야 함

3. Recoil

• 비교적 최근에 나온 새로운 상태 관리 라이브러리
• Facebook사에서 개발
• 가장 React스러운 상태관리라는 철학을 갖고있음
• 장점 :
  • Redux, MobX에 비해 더 간단한 구조를 가져서 초심자가 시작하기에 적당하며, 작은 프로젝트를 시작하는 데 과도한 보일러 플레이트가 필요하지 않음
  • component가 렌더링 되는 시기, 상태 등을 세밀하게 제어 가능 (성능 최적화 등에도 활용 가능)
  • Redux와는 달리 Reactive 메커니즘을 탑재하고 있기에, 동적인 기능을 조금 더 쉽게 구현 가능
• 단점 :
  • 최신 라이브러리이다 보니, 사용자 커뮤니티가 비교적 빈약함 → 이슈가 생겼을 때, 홀로 해결해야 하는 경우가 생길 수도.
  • Recoil의 상태관리 자체가 굉장히 세분화 되어 있기에 초심자가 시작하기엔 쉽더라도, 디버깅 하거나 테스트를 진행하기에 어려울 수도 있습니다.

4. MobX

• Redux의 여러 점을 보완하여 나온 상태관리 라이브러리
• Redux보다 조금 더 객체 지향적이며, Immutable.js 와 같은 불변성을 유지하기 위한 라이브러리를 굳이 사용할 필요가 없다는 특징
• 장점 :
  • Redux에 비해 전체적으로 조금 더 쉬운 러닝커브를 가짐
  • 객체 지향적이고 캡슐화를 지원하기에 개발자 친화적인 편
  • Redux에서 제공하지 않는 반응형 메커니즘을 제공하기에 조금 더 쉽게 동적 웹앱 제작 가능
• 단점 :
  • 웹앱 규모가 커지면서 로직이 MobX의 자동 업데이트에 의존하기에 디버깅이 조금 더 어려워질 수 있음
  • Redux 만큼 커뮤니티가 크지 않음
  • Validation 구현에 있어 코드가 조금 번잡스럽다고 알려져 있음

---

리액트 렌더링을 관리하여 성능을 최적화하는 방법 알아보기

1. useMemo

• useMemo는 종속 변수들이 변하지 않으면 함수를 굳이 다시 호출하지 않고 이전에 반환한 참조값을 재사용 한다.
• 즉, 함수 호출 시간도 세이브할 수 있고 같은 값을 props로 받는 하위 컴포넌트의 리렌더링도 방지할 수 있다.

2. React.memo 컴포넌트 메모이제이션

• React hook이 아니라서 클래스형 컴포넌트에서도 사용할 수 있다.
• React.memo를 통해 컴포넌트의 props가 바뀌지 않았다면, 리렌더링하지 않도록 설정하여 함수형 컴포넌트의 리렌더링 성능을 최적화 해줄 수 있다.
• 콜백함수를 이용해 메모이제이션을 적용할지 여부를 판단할 수도 있다

3. useCallback

• useMemo가 리턴되는 값을 memoize 시켜주었는데, useMemo와 비슷한 useCallback은 함수 선언을 memoize 하는데 사용된다
• useCallback으로 함수를 선언해주면, 종속 변수들이 변하지 않는 이상 굳이 함수를 재생성하지 않고 이전에 있던 참조 변수를 그대로 하위 컴포넌트에 props로 전달하여, 하위 컴포넌트도 props가 변경되지 않았다고 인지하게 되어 하위 컴포넌트의 리렌더링을 방지할 수 있다.

4. 자식 컴포넌트의 props로 객체를 넘겨줄 경우 변형하지말고 넘겨주기

• props의 값으로 객체를 넘겨주는 경우 새로 생성된 객체가 props로 들어가므로 컴포넌트가 리렌더링 될 때마다 새로운 객체가 생성되어 자식 컴포넌트로 전달된다.
• props로 전달한 객체가 동일한 값이어도 새로 생성된 객체는 이전 객체와 다른 참조 주소를 가진 객체이기 때문에 자식 컴포넌트는 메모이제이션이 되지않는다.
• 생성자 함수나 객체 리터럴로 객체를 생성해서 하위 컴포넌트로 넘겨주는 방식이 아닌, state를 그대로 하위컴포넌트에 넘겨주어 필요한 데이터 가공을 그 하위컴포넌트에서 해주는 것이 좋다.

5. 컴포넌트를 매핑할 때에는 key값으로 index를 사용하지 않는다.

• 리액트에서 매핑을 할때 반드시 고유 key를 부여하도록 강제하고 있는데, 배열의 index값으로 key값을 부여하면 좋지 않다.
• 왜냐하면, 어떤 배열에 중간에 어떤 요소가 삽입될때 그 중간 이후에 위치한 요소들은 전부 index가 변경된다.
• 이로 인해 key값이 변경되어 React는 key가 동일 할 경우, 동일한 DOM Element를 보여주기 때문에 예상치 못한 문제가 발생한다. 또한, 데이터가 key와 매치가 안되어 서로 꼬이는 부작용도 발생한다.

6. useState의 함수형 업데이트

• setState를 사용할 때 새로운 상태를 파라미터로 넣는 대신, 상태 업데이트를 어떻게 할지 정의해 주는 업데이트 함수를 넣을 수도 있는데,

이렇게 하면 useCallback을 사용할 때 두 번째 파라미터로 넣는 배열에 값을 넣어주지 않아도 된다.

// 예시) 삭제 함수 
const onRemove = useCallback(
  id => {
    setTodos(todos.filter(todo => todo.id !== id));
  },
  [todos],
);

// 예시) 함수형 업데이트 후
const onRemove = useCallback(id => {
  setTodos(todos => todos.filter(todo => todo.id !== id));
}, []);

7. Input에 onChange 최적화

• 보통 input 태그에 onChange 이벤트를 줄때 타이핑을 할때마다 해당 컴포넌트가 렌더링 되어, 최적화 방법을 많이 찾곤한다.
• lodash 라고 최적화 라이브러리를 쓰기도 하는데, 아래 코드는 라이브러리를 쓰지 않고 최적화 시킬수 있는 방법이다.

// 예시) 최적화 전(X)
//UserList.jsx
function UserList() {
 {...}
  return (
      <div>
       <input
         type="text"
         value={text}
         placeholder="아무 내용이나 입력하세요."
         onChange={(event) => setText(event.target.value)}
        />
   {...}
      </div>
  );
}

export default UserList;

// 예시) 최적화 후(O)
//UserList.jsx
function UserList() {
 {...}
  return (
      <div>
       <input
          ref={searchRef}
          type="text"
          placeholder="아무 내용이나 입력하세요."
          onKeyUp={() => {
            let searchQuery = searchRef.current.value.toLowerCase();
            setTimeout(() => {
              if (searchQuery === searchRef.current.value.toLowerCase()) {
                setText(searchQuery);
              }
            }, 400);
          }}
        />
   {...}
      </div>
  );
}

export default UserList;