본문 바로가기

Redux

[Redux] 1. 리덕스의 정의 및 특징

리덕스의 정의

리액트에서 가장 많이 쓰이는 상태(state)관리 라이브러리

리덕스가 필요한 이유

리액트로 프로젝트를 진행하다 보면 무조건 stateprops를 사용하게 되는데

컴포넌트끼리 state를 전달하고 관리하기가 쉽지 않다.

만일, 컴포넌트가 (부모)App- Sample1 - Sample2(자식) 순으로 있다면 

App의 state를 Sample2에서 사용하기 위해서는 다음과 같은 과정이 필요하다.

1. App의 state를 Sample1에게 props로 넘겨준다
2. Sample1의 props를 다시 Sample2에게 props로 넘겨준다

컴포넌트가 3개밖에 없을 때에도 2단계의 과정이 필요한데 프로젝트 규모가 더 커지고

컴포넌트 개수가 늘어나게 된다면 더 많은 단계가 필요해져 프로젝트가 상당히 복잡해질 것이다.

이러한 번거로움과 복잡도를 줄이기 위해 리덕스를 사용해서 state를 관리하는 것이다.

리덕스는 리액트뿐만 아니라 일반 Javascript 환경이나 Angular와 같은 다른 프레임워크에서도 사용될 수 있음!

필요 개념

본격적으로 리덕스를 사용하기 전에 반드시 숙지해야 하는 개념이 몇 가지 있다.

액션(Action)

상태에 변화가 필요할 때 발생시키는 것을 말한다.

하나의 객체로 표현되며, 다음과 같은 형식으로 이뤄져 있다.

{
  type: "TEST"
}

액션 객체는 type 필드를 무.족.권 가지고 있어야하고 그 외의 값들은 개발자가 임의로 넣을 수 있다.

{
  type: "TEST",
  data: {
    id: 0,
    text: "배고프다"
  }
}
{
  type: "TEST2",
  text: "오늘 점심은 뭐죠"
}

액션 생성함수(Action Creator)

말 그대로 액션을 만드는 함수이다. 파라미터를 받아와 액션 객체 형태로 만들어주는 역할을 한다

export function addTodo(data) {
  return {
    type: "TEST",
    data
  };
}

액션 생성 함수를 미리 만들어놓으면 특정 액션이 발생했을 때 해당 함수를 호출하기만 하면 된다.

그래서 보통 함수에 export 키워드를 붙여 다른 파일에서도 사용 가능하도록 한다.

하지만 액션 생성함수를 사용하는 것이 필수적이지는 않다

👉 액션 발생 시킬 때마다 직접 액션 객체를 작성할 수도 있다.

리듀서(Reducer)

변화를 일으키는 함수를 말한다. 두가지의 파라미터를 받아오는데 보통 이를 stateaction이라고 이름 붙인다.

리듀서는 현재의 상태와 전달 받은 액션을 참고해 새로운 상태를 만들어 반환한다.

만일, 카운터를 위한 리듀서를 작성한다면 다음과 같이 작성할 수 있다.

function reducer(state, action) {
  switch (action.type) {
    case 'INCREASE':
      return state + 1;
    case 'DECREASE':
      return state - 1;
    default:
      return state;
  }
}

스토어(Store)

리덕스에서는 한 애플리케이션 당 하나의 스토어를 만들게 된다.

스토어 안에는 현재의 앱 상태와 리듀서가 들어가있고, 추가적으로 몇 가지 내장 함수들이 들어가 있다.

디스패치(Dispatch)

디스패치는 스토어의 내장함수 중 하나로 액션을 발생 시키는 것이라고 생각하면 된다.

dispatch 함수한테 action을 파라미터로 전달하게 되면 스토어는 리듀서 함수를 실행시켜 해당 액션을

처리하는 로직이 있을 경우 액션을 참고해 새로운 상태를 만들어준다.

구독(Subscribe)

구독 또한 스토어의 내장함수 중 하나로 함수 형태의 값을 파라미터로 받아온다.

subscribe 함수에 특정 함수를 전달하면 액션이 dispatch 됐을때 마다 전달해준 함수가 호출된다.

리덕스의 특징

1. 컴포넌트 코드로부터 상태 관리 코드를 분리할 수 있다

리덕스를 사용하게 되면 컴포넌트들의 상태 관련 로직들을 다른 파일들로 분리시켜 프로젝트를 효율적으로 관리할 수 있다.

👉 글로벌 상태 관리를 손쉽게 할 수 있음

 

2. 미들웨어를 활용한 다양한 기능을 추가할 수 있음

리덕스에는 미들웨어(Middleware)라는 개념이 존재한다.

미들웨어: 클라이언트와 서버 간의 통신을 담당하는 시스템 소프트웨어 또는 컴퓨터와 컴퓨터의 연결을 담당하는 시스템 소프트웨어
👉 쉽게 말해 클라이언트와 서버 사이에 있는 소프트웨어

따라서, 데이터를 처리하는 중간과정에 로직을 넣어서 원하는 기능을 추가할 수 있다.

 

3. SSR(Server Side Rendering)시 데이터 전달이 간편하다

리덕스의 상태값은 하나의 객체로 표현이 가능하다. 따라서, 하나의 객체만 문자열로 변환해 서버에서 클라이언트로 전달하면 되기 때문에 데이터 전달이 매우 간편하다. 그리고 클라이언트는 받은 문자열을 하나의 객체로 만들어서 사용하면 된다.

 

4. 하나의 커다란 상태

리덕스에서는 글로벌 상태를 하나의 커다란 상태 객체에 넣어서 사용한다. 그렇기 때문에 Context를 매번 새로 만드는 번거로움을 덜 수 있다.

리덕스의 3가지 규칙

리덕스를 프로젝트에 적용하기 전에 꼭 지켜야 하는 규칙이 3가지 있다.

 

1. 하나의 애플리케이션 안에는 하나의 스토어가 있다.

하나의 애플리케이션에선 단 한개의 스토어를 만들어서 사용한다. 여러 개의 스토어를 사용하는 것도 가능은 하지만 권장되지는 않는다. 특정 업데이트가 빈번하게 일어나거나 애플리케이션의 특정 부분을 완전히 분리시킬 경우에 여러개의 스토어를 만들 수도 있긴 하다. 하지만 그러면 개발 도구를 활용하지 못하게 된다.

 

2. 상태는 읽기전용이다.

기존의 상태는 건드리지 않고 새로운 상태를 생성해 업데이트를 진행해줘야 한다. 그래야 이후에 개발자 도구를 통해 이전 상태로 되돌리거나 원래 상태로 복구할 수 있다. 리덕스는 내부적으로 데이터가 변경되는 것을 감지하기 위해 shallow equality 검사를 하기 때문에 불변성을 유지해야만 한다.

Shallow Equality: 비교 대상 객체의 키를 반복하여 확인하고 각 객체의 키 값이 모든 키에 대해 엄격하게 동일한지 확인하는 것

이를 통해 객체의 변화를 감지할 때 객체의 깊숙한 안쪽까지 비교를 하는 것이 아니라 겉핥기 식으로 비교를 해 좋은 성능을 유지할 수 있다.

 

3. 변화를 일으키는 함수, 리듀서는 순수한 함수여야 한다.

순수한 함수는 다음과 같은 조건을 만족한다.

1. 리듀서 함수는 이전 상태와 액션 객체를 파라미터로 받는다.
2. 이전의 상태는 절대로 건드리지 않고 변화를 일으킨 새로운 상태 객체를 만들어서 반환한다.
3. 똑같은 파라미터로 호출된 리듀서 함수는 언제나 똑같은 결과값을 반환해야 한다.

 

참고

벨로퍼트와 함께하는 모던 리액트 https://react.vlpt.us/redux/