리액트의 구조
리덕스는 리액트를 위해서 만들어졌다고 해도 과언이 아니기에 일단 기본적으로 리액트의 구조를 알아야 한다. 리액트에서 데이터흐름은 단일 방향으로만 흐르고 있는데, 이는 직관적이고 간단하다. 그러나 컴포넌트 갯수가 증가됨에 따라 데이터 또한 매우 증가하므로 부모,자식간의 관계가 더욱 복잡성을 띄게 된다. 사진으로 보게되면
빨간색 컴포넌트가 파란색, 초록색 컴포넌트와 데이터를 교류해야하는 경우 ref등을 사용해서 데이터를 직접적으로 교류 할 수 있지만 리액트에서는 컴포넌트끼리의 직접교류는 절대적으로 권장하지 않는다. 그렇게 하다간 코드가 매우 복잡해지는, 스파게티 코드가 생성되기 때문이다. 따라서 리액트는 아래와 같은 사진의 구조를 통해 데이터가 교류된다.
하지만 이런 코드는 컴포넌트들의 변화는 상위 컴포넌트 를 거쳐 최상위 부모 컴포넌트를 지나는 과정이 필요하기때문에 위에서 서술한것처럼 시간이 지날수록 점점 복잡성을 띄게된다.
MVC패턴의 구조
리덕스가 등장하기 전에 프론트엔드에서 가장 널리 사용되는 디자인 패턴이다.
- Model: 데이터 형식이나 구조를 관리
- View: 실제 사용자에게 보여지는 부분을 관리
- Controller: 변화하는 데이터를 관리, view에서 발생하는 이벤트로 변경된 데이터나 서버에서 받은 변경된 데이터를 Model, View에 업데이트 해준다.
MVC패턴의 가장 큰 특징은 "양방향 데이터 흐름"이다. 즉 Model이 변경되면 View가 변경되고, 이벤트에 의해 View가 변경되면 Model또한 변경된다. 이 변경여부와 담당하는 역할은 Controller가 한다. 이런 양방향 데이터 흐름은 설계가 간단하고 코드 작성이 간결하나 문제점은 애플리케이션 규모가 커질수록 한개의 Model이 N개의 View를 조작하고, 한개의 View가 N개의 Model을 조작하는 경우가 발생하면서 데이터 흐름의 직관성과 유지보수가 힘들어진다. 에러라도 발생한다면 유지보수를 위해서 정말 많은 노력을 쏟아야 하는것이다. 😅
Flux 등장
이런 리액트의 문제와, MVC패턴의 데이터 흐름의 문제로 2014년 페이스북에서 Flux라는 새로운 아키텍쳐 패턴을 개발하였다. ( 페이스북은 이전에 알람정보가 제대로 업데이트가 되지 않아서 알람표시가 계속 유지되는 등의 문제가 발생하고 있었다 )
Flux는 "단방향 데이터 흐름"으로, 시스템에서 어떤 action을 받으면, dipatcher가 받은 action들을 통제하여 store에 있는 데이터를 업데이트 한다. 그리고 view는 변동된 데이터를 store를 통해서 전달을 받는다.
그리고 view에서 dipatcher로 action을 보낼수 있는데, MVC패턴과 달리 데이터를 변동시키지 않고 action을 넘겨주면서 dipatcher은 작업이 중첩되지 않도록 한다. 즉 어떤 action이 dipatcher를 통해서 store에 있는 데이터를 처리하고, 그 작업이 끝날 때까지 다른 action들은 대기를 시킨다.
이런 Flux는 기존의 MVC패턴,리액트에 있던 상태전이를 없애주고 예측가능하게 만들었다.
리덕스 등장
2015년에 Dan Abramov에 의해서 React + Flux의 구조에 'Reducer'를 결합한 'Redux'가 등장하게 된다.
리덕스는 위에서 설명한 Flux 아키텍쳐를 좀더 편하게 사용할수 있게 해준 라이브러리이다.
위 사진처럼 store에서 모든 데이터를 담고있어 컴포넌트끼리 직접교류하지않으며, 부모 컴포넌트를 거치지 않아도 store를 통해서 데이터 교류가 가능하다. dispatch는 store에 있는 데이터를 업데이트 하는 것을 가르키고,subscribe는 해당 컴포넌트에서 store가 변동이 있을시 바로 반영시키는 것을 가르킨다.
리덕스 3원칙
1: Single Source of Truth( 진실은 하나의 소스 )
리덕스는 어플리케이션의 상태를 위해서 단 한개의 store만을 사용한다. 때문에 state가 한곳에 있기에 Single Source of Truth 라고 부른다. (Flux에서는 여러개의 store를 사용한다)
2: State is read-only( 상태는 읽기전용 )
어플리케이션에서 state를 직접 변경할수는 없다는 의미이다. state를 변경하기 위해서는
action 객체를 dispatch를 통해 전달하는 방법을 통해 이루어 진다. action는 어떤 변화가 일어날지 알려주는 객체이다. 즉 view에서 일어나는 이벤트는 직접 state를 변경할수 없고, 이벤트는 action을 Reducer로 전달할 뿐이며 데이터의 변경은 reducer만 할수 있다. 나머지에서 state는 읽기 전용이다.
3: Changes are made with Pure Functions( 변화는 순수함수로 만들어져야 한다 )
action에 의해 상태트리가 어떻게 변하는지를 지정하기 위해서는 순수함수로 Reducer을 작성해야 한다.
순수함수란?
- 외부 네트워크, DB에 접근하지 않아야한다.
- return은 오직 파라미터값에 의존되어야 한다.
- 반드시 이전 상태와 action을 매개변수로 받는다.
- 순수하지 않은 api호출을 하지 말아야 한다. ( Date, Math 등 의 함수 )
- 동일한 입력값에는 동일한 결과값을 반환해야 한다.
참고
