리덕스에 대하여

리덕스 왜 쓰지?

우리는 이때가지 리덕스라는 라이브러리를 사용하지 않고도 리액트 앱을 잘 만들어 냈습니다.

하지만 프로젝트의 크기가 커질수록 전역적으로 관리해야하는 상태의 수가 많아질 수도 있으며 프로젝트가 복잡해 질수 있습니다.

다음은 리덕스 공신문서에서 언제 리덕스를 사용해야하는지 명시해 놓은 것 입니다.

 

https://ko.redux.js.org/introduction/getting-started/

어쩌면 리덕스는 당신에게 필요없는 라이브러리 일지도 모릅니다.

오히려 코드가 복잡해지고 빙 돌아간다는 느낌을 받을 것 입니다.

 

https://medium.com/lunit/%EB%8B%B9%EC%8B%A0%EC%97%90%EA%B2%8C-redux%EB%8A%94-%ED%95%84%EC%9A%94-%EC%97%86%EC%9D%84%EC%A7%80%EB%8F%84-%EB%AA%A8%EB%A6%85%EB%8B%88%EB%8B%A4-b88dcd175754

당신에게 Redux는 필요 없을지도 모릅니다.

 

위 글을 보면 리덕스는 등가 교환을 가져온다고 되어있습니다.

• 앱의 상태를 평범한 객체와 배열로 만듭니다.
• 시스템 내의 변경사항을 평범한 객체로 만듭니다.
• 변경을 다루는 로직을 순수함수로 만드세요

이렇게 앱에 제약을 걸면서 얻을수 있는 교환은 다음과 같습니다.

• 로컬 스토리지에 상태를 영속적으로 저장하고 시작할 때 다시 불러오는 데 특히 뛰어납니다.
• 상태를 서버에서 미리 채워서 HTML에 담아 클라이언트로 보내고 앱을 시작 할 때 다시 불러오는데 특히 뛰어납니다.
• 사용자의 액션을 직력화 해서 상태와 함께 자동으로 버그 리포트에 첨부할 수 있습니다.개발자들은 이를통해 에러를 재현할 수 있습니다.
• 액션 객체를 네트워크를 통해 보내면 코드를 크게 바꾸지 않고도 협업 환경을 구현할 수 있습니다.
• 실행취소 내역의 관리나 낙관적인 변경을 코드를 크게 바꾸지 않고도 구현할 수 있습니다.
• 개발할 때 상태 내역 사이를 오가고 액션 내역에서 현재 상태를 다시 계산하는 일을 TDD스타일로 할 수 있습니다.
• 개발자 도구에게 완전한 조사와 제어를 가능하게 해서 개발자들이 자신의 앱을 위한 도구를 직접 만들 수 있게 해 줍니다.
• 비즈니스 로직 대부분을 재사용하면서 UI를 변경할 수 있게 해 줍니다.

리덕스에 들어가기전 MVC와 Flux 패턴에 대해 알아보자

일단 우리가 익히 들어본 MVC패턴에 대해 알아 봅시다.

MVC패턴

MVC는 Model,View,Controller의 약자입니다.

Model에 데이터를 저장하고, Controller를 이용하여 Model의 데이터를 관리합니다.

모델의 데이터가 변경되면 view로 전달되어 사용자에게 보여집니다.

view를 통해 데이터를 입력하면 view역시 model을 업데이트 할 수 있다는 점입니다.

 

view가 다양한 상호작용을 위해 여러 개의 model을 동시에 업데이트하고 model 역시 여러 개의 view에 데이터를 전달하는 상황이 발생합니다.한 Model이 업데이트되면 그에 따라 view가 업데이트되고, 업데이트된 view가 또 다른 model을 업데이트하는 식의 복잡한 데이터 흐름을 가지데 됩니다.

-> 예측이 어려워집니다.

 

페이스북은 이러한 MVC의 복잡성때문에 Flux패턴을 고안했습니다.

 

Flux패턴이란

Flux는 사용자 입력을 기반으로 Action을 만들고 Action을 Dispatcher에 전달하여 Store(model)의 데이터를 변경한 뒤 View에 반영하는 단방향의 흐름으로 애플리케이션을 만드는 아키텍처입니다.

 

Action

action이란 데이터를 변경하는 행위 로서 Dispatcher에 전달되는 객체를 말합니다.

Action creator 메서드는 새로 발생한 Action의 타입과 새로운 데이터를 묶어 Dispatcher에게 전달합니다.

 

Dispatcher

Dispatcher는 모든 데이터의 흐름을 관리하는 중앙 허브입니다.

Dispatcher에는 Store들이 등록해놓은 Action타입마다의 콜백 함수들이 존재합니다.

Action을 감지하면 Store들이 각 타입에 맞는 Store의 콜백 함수를 실행합니다.

Store의 데이터를 조작하는 것은 오직 Dispatcher를 통해서만 가능합니다.

또한 Store들 사이에 의존성이 있는 상황에서도 순서에 맞게 콜백 함수를 순차적으로 처리할 수 있도록 관리합니다.

 

Store(Model)

Store는 상태 저장소로서 상태와 상태를 변경할 수 있는 메서드를 가지고 있습니다. 어떤 타입의 Action이 발생했는지에 따라 그에 맞는 데이터 변경을 수행하는 콜백 함수를 Dispatcher에 등록합니다.

Dispatcher에서 콜백 함수를 실행하여 상태가 변경되면 View에게 데이터가 변경되었음을 알립니다.

 

view

view는 리액트 컴포넌트로 생각하면 됩니다. Store에서 View에게 상태가 변경되었음을 알려주면 최상위 View는 Store에서 데이터를 가져와 자식 View에게 내려보냅니다.새로운 데이터를 받은 view는 화면을 리렌더링 합니다.

또한 사용자가 view에 어떠한 조작을 하면 그에 해당하는 Action을 생성합니다.