Redux

가장 많이 사용하는 리액트 상태 관리 라이브러리이다.

리덕스를 사용하면 컴포넌트의 상태 업데이트 관련 로직을 다른 파일로 불리시켜서 더욱 효율적으로 관리할 수 있다.
또한, 컴포넌트끼리 똑같은 상태를 공유해야 할때도 여러 컴포넌트를 거치지 않고 손쉽게 상태를 전달하거나 업데이트 할 수 있다.

context API로도 똑같은 작업을 할 수 있지만, v16.3이 릴리즈 되면서 context API가 개선되기 전에는 사용 방식이 매우 불편했어서 주로 리덕스로 전역 상태 관리를 했었다.

불변성을 유

장점

• 단방향 모델링이라 에러를 찾기 쉽다.
• 상태를 더욱 체계적으로 관리할 수 있다(프로젝트의 규모가 클 경우에는 리덕스를 사용하는 편이 좋다)
• 코드의 유지 보수성도 높이고, 작업 효율도 극대화 시킴.
• 미들웨어라는 기능을 제공해서 비동기 작업을 훨씬 효율적으로 관리.
• 상태관리 중앙화 store를 사용해서 한 곳에서 관리.
• 리덕스에서 상태는 읽기전용. 이전상태로 돌아가고싶으면 그냥 덮어쓰기 하면 된다.

단점

• 아주 작은 기능이여도 리덕스로 구현하는 리덕스의 구성요소들을 필수로 만들어야한다. 코드량 ⬆️
• 타임머신 기능을 사용하려면 불변성 개념을 지켜야 사용할 수 있으므로 매번 state라는 객체를 만들어줘야 함
• 취급만 읽기전용 실제 읽기 전용은 아니다. 상태를 직접 바꾸지 않도록 주의해야한다. (Immutable.js 라이브러리로 도움을 받을 수 있음)

기본 원칙

진실은 하나의 근원으로부터

• 애플리케이션의 모든 상태는 하나의 저장소 안에 하나의 객체 트리 구조로 저장된다.

상태는 읽기 전용이다.

• 상태를 변화시키는 유일한 방법은 무슨 일이 벌어지는 지를 묘사하는 액션 객체를 전달하는 방법뿐이다.

변화는 순수 함수로 작성되어야한다

• 액션에 의해 상태 트리가 어떻게 변화하는 지를 지정하기 위해 프로그래머는 순수 리듀서를 작성해야한다.

구성 요소

액션

상태에 어떠한 변화가 필요하면 액션이 발생

리듀서

변화를 일으키는 함수. 액션을 만들어서 발생시키면 리듀서가 현재 상태와 전달 받은 액션 객체를 받아옴.

스토어

한개의 프로젝트는 단 하나의 스토어만 가질 수 있다.

디스패치

스토어의 내장 함수. 액션을 발생 시키는 것

구독

스토어의 내장 함수 중 하나. 디스패치되어 상태가 업데이트 될때마다 호출

Flux 패턴

등장 배경

대규모 애플리케이션의 데이터 흐름을 일관성있게 관리하고자 함

어플리케이션 규모가 커지기 시작하면서, 양방향으로 흐르던 데이터들이 복잡도가 높아짐
모델의 갯수가 많아질수록 데이터 흐름을 파악하기 어려워짐을 느껴
단방향 데이터 흐름을 가지는 Flux 패턴이 등장.

Flux 패턴이란?

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

Action : 데이터를 변경하는 행위
Store : 상태 저장소로서 상태와 상태를 변경할 수 있는 메서드를 가지고 있는 곳.
Dispatcher : 모든 데이터의 흐름을 관리하는 중앙 허브
View : 리액트 컴포넌트

각 요소들은 단방향 흐름에 따라 순서대로 역할을 수행
View로부터 새로운 데이터 변경이 생기면 처음부터 순서대로 실행.
결과 -> 예외 없이 데이터를 처리 가능! 예측 가능한 데이터 흐름!

flux Redux 차이

flux 한 곳에서 관리되고
Redux는 상태랑 상태관리하는 곳이랑 따로 관리