리액트 애플리케이션 상태를 관리하기 위해 단방향 데이터 플로우(Unidirectional data flow)를 사용한다.
Flux는 페이스북에서 개발한 클라이언트 사이드 웹 애플리케이션을 위한 아키텍처이자 상태 관리 라이브러리다. 그러나 Flux의 컨셉을 구현한 다른 괜찮은 상태 관리 라이브러리가 많이 등장하면서, Flux는 상태 관리 라이브러리보다는 앱 아키텍처로 여겨지게 됐다. (flux 조차도 다른 라이브러리를 사용할 것을 권장하고 있다)
Flux 컨셉
- 뷰(리액트 컴포넌트)에서 이벤트가 발생하면, 액션이 생성된다.
- 액션은 Dispatcher에게 전달된다.
- Dispatcher는 Store에게 액션을 전달한다.
- Store가 가지고 있는 상태가 액션에 정의된 방식대로 갱신된다.
- Store의 상태가 갱신되었음을 뷰에 전파하고, 뷰는 상태에 맞게 다시 렌더링된다.
※ Flux에서는 Store가 상태와 비즈니스 로직을 모두 알고 있다.
그림의 화살표 방향처럼, 데이터는 한 방향을 향해서만 흘러간다. 뷰는 직접 Store의 상태를 변경할 수 없고, 액션은 직접 뷰를 변경할 수 없다.
어떻게 한 방향으로만 흐를 수 있을까?
Flux 패턴의 등장 객체(?)들은 모두 불변 객체 혹은 순수 함수이다.
- Store의 상태 값 → 불변 객체로 관리된다
- Action → 불변 객체로 관리된다
- Dispatcher → 순수 함수
- Component → 단방향으로 데이터가 흘러오게 되어 있다. 컴포넌트가 변경되는 것은 prop과 state가 변경되는 순간 뿐이다
따라서 이 객체들이 가지고 있는 값은 함부로 변경이 불가능하고, 미리 약속한 방법대로만 변경 가능하다.
- Store가 가지고 있는 상태 값을 변경하려면, Action 객체를 Dispatcher에게 넘겨줘야만 한다. 상태 값은 Store에 정의된 방식대로만 변경된다.
- Component가 그리는 UI를 변경하려면, 컴포넌트에 넘겨주는 prop이나 컴포넌트가 가진 state를 변경해줘야 한다.
왜 한 방향으로 흐르게 만들었을까?
페이스북에서는 Flux 패턴 이전에 MVC 패턴을 사용해 앱의 상태를 관리했다.
MVC 패턴. 출처:
https://youtu.be/nYkdrAPrdcw?t=694
MVC 패턴에서는 뷰와 모델, 컨트롤러 간에 수많은 의존성이 생긴다. 뷰가 컨트롤러나 모델을 조작하기도 하고, 컨트롤러나 모델이 뷰를 변경시키기도 한다. 혹은 모델끼리 서로 의존성을 가져서 연쇄적으로 변경을 일으키기도 한다.
이런 식으로 복잡한 의존성이 생기면 어떤 값이 변경되었을 때 그 변경 원인을 알기가 어렵다. 의존성이 꼬여서 의도치 않은 값이 변경될 수도 있고, 한 가지 변경을 위해 여러 군데를 수정해야 할 수도 있다.
그 외에 이런 단점이 있다.
- 확장성이 좋지 않다
- 앱이 커질수록 복잡해지고, 이해하기 힘들다
- 유지보수하기 힘들다
- 테스트하기 힘들다
페이스북 팀은 이러한 MVC 패턴에 한계를 느꼈고, 데이터가 한 방향으로만 흐르는 Flux 패턴을 도입했다.
데이터가 한 방향으로만 흐르면 좋은 점
예측 가능성
컴포넌트는 prop과 state가 변하는 순간에 다시 렌더링된다. 만약 그렇지 않고 컴포넌트를 자유롭게 조작할 수 있었다면, 컴포넌트가 어떤 순간에 어떻게 변할지 예측하기 어려울 것이고, 이것은 사이드 이펙트를 만들 것이다.
불변 객체로 관리된다는 것은, 예상치 못한 곳에서 임의로 객체의 값을 수정할 수 없다는 것이다. Store를 변경하는 것이 허락된 곳에서만 값을 수정할 수 있기 때문에, Store의 변경은 예측 가능해지고, 값의 변경을 추적하기가 편리하다.
단순성
Flux에서 데이터는 한 방향으로만 흐른다. MVC 패턴에서처럼 모델이 의존하고 있는 다른 모델을 트리거하고, 또 다른 모델을 트리거하는 것처럼 데이터가 다른 길로 새지 않는다는 것이다.
따라서 앱 내에 복잡한 의존성이 줄어든다. 의존성을 적게 유지하면 어느 부분을 수정했을 때 다른 부분에서 의도치 않은 변화가 생길 가능성이 낮다는 것을 보장할 수 있다. 그래서 새로운 기능을 추가하거나 앱을 유지보수하기에 편리하고, 좀 더 안정적으로 앱의 규모를 키울 수 있다.
