Redux 등장 배경 및 개념정리

Redux는 가장 사용률이 높은 리액트 상태 관리 라이브러리이다.

컴포넌트들의 상태 관련 로직들을 다른 파일들로 분리시켜서 더욱 효율적으로 관리할 수 있다.

컴포넌트끼리 상태를 공유하게 될 때 여러 컴포넌트를 거치지 않고도 손쉽게 상태 값을 전달할 수 있다.

컴포넌트의 상태를 store라는 곳에서 따로 관리하기 때문에 코드의 유지보수도 좋고, 글로벌 상태 관리를 하게 될 때도 굉장히 효과적인 장점 등이 있다.

하지만 리액트만을 위한 라이브러리는 아니다라는 것을 알고 있어야 한다.

 

🤔Redux 등장 배경

Redux가 등장하기 이전 프런트엔드에서 데이터 흐름을 관리하는 방식은 MVC패턴이었다.

• Model - 데이터의 형식이나 구조를 관리한다. 모델에 맞지 않는 데이터는 흐름을 제어받을 수 있다.
• View - 사용자에게 보이는 부분을 담당한다. 사용자에게 보여지는 모습과 형태를 관리한다.
• Controller - 변화하는 데이터를 관리한다. View에서 발생하는 이벤트로 변경되는 데이터나 서버로부터 받은 변경된 데이터를 Model과 View에 업데이트해준다.

출처 : http://aalmiray.github.io/griffon-patterns/

위 그림에서도 볼 수 있듯이, state가 변화하게 되면 View, Model, Controller에 이벤트가 발생하고 값이 변화하는 등, 복잡하고 데이터 흐름을 파악하기 힘든 구조로 되어 있었다.

MVC 패턴의 특징 중 하나가 '양방향 데이터 흐름'이다.

 

프로젝트가 커질수록 양방향 데이터 흐름을 제어하는 과정이 복잡하고, 개발자들에게 큰 불편성을 가져왔다고 한다.

이러한 state관리의 문제는 개발적인 측면뿐만 아니라, 사용자 측면에서도 발생하였다.

 

사용자와의 상호작용이 굉장히 많아지고 있는 요즘 웹사이트에서 state관리가 복잡해짐에 따라 실시간으로 구동되어야 하는 기능이 제대로 이뤄지지 않아, state 차이로 인한 버그가 발생하는 등 다양한 문제점이 존재하였습니다.

 

위와 같은 문제점을 해결하기 위해 '단방향 데이터 흐름'이라는 특징을 갖는 라이브러리를 개발하고자 했고, 2014년 페이스북에서 Flux를 개발하게 된다.

 

Flux 패턴? 구조?

Flux는 MVC패턴에서 겪는 양방향 데이터 흐름의 복잡한 상황을 개선할 수 있도록 단방향 데이터 흐름을 적용시켰다.

그래서 이제 View는 MVC 패턴과 달리 데이터를 직접 변경시키지 않고 Action만을 넘겨준 후, View에서 이뤄진 Action은 반드시 Dispatcher를 거쳐 데이터 변경을 진행하게 된다.

 

데이터 변경이 이뤄진 이후, Store에 값을 저장하는 과정을 통해 View는 변경된 데이터를 Store를 통해서 전달받게 된다.

 

위와 같은 과정을 통해 이뤄진 데이터 변경은 뷰와 모델 사이의 state 전이를 간편 화해 주고 기존에 흐름을 파악하기 어려웠던 관리에 예측이 가능하게 해 주어, 더욱 편리한 state 변경 방법을 제시하게 된다.

 

위와 같은 방식을 채택하여 최종적으로 2015년에 Dan Abramov에 의해서 React + Flux의 구조에 ‘Reducer’를 결합한 ‘Redux’가 등장하게 된다

 

'Redux = (Red)ucer + Fl(ux)'

Redux 기본 개념

Actions(액션)

상태에 어떠한 변화가 필요하게 될 땐, 우리는 액션이란 것을 발생시킨다.

하나의 객체로 표현된다.

액션 객체는 다음과 같은 형식으로 이뤄져 있습니다.

액션 객체는 type 필드를 필수적으로 가지고 있어야 하고 그 외의 값들은 개발자 마음대로 넣어줄 수 있다.

{
  type: "TOGGLE_VALUE"
}

Action Creator(액션 생성 함수)

액션 생성 함수는, 액션을 만드는 함수이다.

단순히 파라미터를 받아와서 액션 객체 형태로 만들어준다.

// 화살표 함수로도 만들 수 있습니다.
const changeInput = text => ({ 
  type: "CHANGE_INPUT",
  text
});

Reducer(리듀서)

리듀서는 변화를 일으키는 함수이다.

리듀서는 두 가지의 파라미터를 받아온다.

 

Store(스토어)

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

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

 

dispatch(디스패치)

디스패치는 스토어의 내장 함수 중 하나이다.

디스패치는, 액션을 발생시키는 것이라고 이해하면 된다.

dispatch라는 함수에는 액션을 파라미터로 전달한다.

dispatch(action) 형태로 액션 객체를 인자로 넣어 호출하면 된다.

그렇게 호출을 하면, 스토어는 리듀서 함수를 실행시켜서 해당 액션을 처리하는 로직이 있다면 액션을 참고하여 새로운 상태를 만들어준다.

 

subscribe(구독)

구독 또한 스토어의 내장 함수 중 하나이다.

subscribe 함수는, 함수 형태의 값을 파라미터로 받아온다.

subscribe 함수에 특정 함수를 전달해주면, 액션이 디스패치 되었을 때마다 전달해준 함수가 호출된다.

 

 

요약 (클릭해서 보세요)

출처 : https://ko.redux.js.org/tutorials/essentials/part-1-overview-concepts