리액트 플럭스 패턴( Flux Pattern )[20221203-TIL]

Flux 패턴

 

 페이스북에서 알림이 와있다고 표현되고 있지만 막상 알림을 클릭하게 되면 어떠한 알림도 오지 않았던 버그가 있었는데 이러한 버그가 지속적으로 나타자 이러한 문제들을 명확하게 해결하고자 나온 것이 바로 Flux 패턴이다.

Flux 패턴은 기존에 사용되던 mvc패턴의 단점을 보완하고자 등장한 패턴이라고 한다.

 

MVC 패턴

 

 MVC (Model - View - Controller) 패턴은 사용자 인터페이스와 비즈니스 로직 처리를 하는 구간이 명확히 나누어져 있기 때문에 여러 사람들과 개발할 때 각자 맡은 부분에 대해서만 개발할 수 있다는 장점을 가지고 있어서 많이 사용되어왔다.

하지만 model과 view가 서로 양방향으로 의존되어 있는 관계 때문에 프로젝트의 규모가 점점 커짐에 따라 프로젝트의 복잡도도 같이 커지게 된다는 단점을 가지고 있다.

 

MVC 패턴

 

• Model이란 어플리케이션의 데이터를 관리해주는 부분을 말한다.
• View란 어플리케이션이 사용자에게 어떻게 보여지는지에 대한 관리를 말한다.
• Controller는 Model의 자료와 View의 인터렉션을 총괄하는 어플리케이션 로직을 관리한다.

 

MVC패턴의 문제

그러다가 페이스북에서 Flux라는 패턴에 대해 발표하게 되었다. Flux 패턴은 어떤 액션이 발생하면 dispatcher에 의해 store에 변경된 사항이 저장된다. 그리고 그 저장된 데이터들에 의해 view가 변경되는 단방향 패턴이다.

dispatch 함수란?

dispatch라는 함수에 단순 객체일 뿐인 action을 넣어서 action을 발생시키도록 만든다.

dispatch(action) => reducer 동작하게됨 => store의 state 변경 => 변경된 state가 state를 subscription하고 있는 component에 정보 전달 이런 로직으로 상태 변화가 일어난다.

즉, 아무 기능도 없는 객체일 뿐인 event를 dispatch가 동작시키도록 도와주는 역할을 한다.

Flux 패턴을 쓰게되면, 개발 흐름이 단방향으로 흐르기 때문에 파악하기 용이하고 코드의 흐름이 예측 가능해진다고 한다.

 

 

 

Flux 패턴

 

아까의 MVC 패턴은 어떤 action이 발생하면 데이터 상태가 변경되고 그에 따라 디스플레이를 변경하는데 상태가 변경되었다는 정보를 View와 Model이 서로 양방향으로 주고받는 형태이다.

 

그러나 Flux 패턴은 action이 발생하면 dispatcher에 의해 store에 변경된 사항이 저장되고 그 저장된 사항에 의해 view가 변경되는 단방향 패턴을 보이고 있다. 여기서 dispatcher란 어플리케이션에서 발생한 action들을 정리해주는 역할을 하며 Store란 어플리케이션의 데이터들이 저장되는 장소이다.

 

이러한 패턴의 가장 큰 장점은 개발 흐름이 단방향으로 흐르기 때문에 훨씬 파악하기 쉽고 코드의 흐름이 예측 가능(Predictable)하다는 것이다.

 

 

상태 관리

 

상태 관리라고 하는 것은 하나의 저장소에서 데이터를 관리하는 것을 의미하는 것으로 컴포넌트에서 필요한 데이터가 있을 시 저장소에서 한 번에 가져다 사용할 수 있도록 도와준다.

 

만약 리액트에서 상태 관리를 사용하지 않는다면 다음과 같은 상황이 발생할 수 있다.

 

상태 관리를 사용하지 않을 경우

 

 

A컴포넌트에서 소유하고 있는 데이터를 D컴포넌트에서도 사용하고 싶을 때 props를 통해 부모-자식간 데이터를 전달하며 D컴포넌트에서 사용할 수 있도록 할 수 있다.

 

하지만 만약 프로젝트의 규모가 점점 커진다면 이런 데이터 전달 방식은 프로젝트에 복잡함을 가져오고 유지보수도 힘들어지게 된다고한다.

 

이런 상황을 해결할 때 상태 관리를 활용하면 된다.

 

상태 관리를 활용할 경우 다음과 같이 단순하게 D컴포넌트는 저장소에서 한 번에 데이터를 가져다 사용할 수 있게 된다.

 

상태 관리를 사용할 경우

 

 

결국 부모-자식간의 관계가 유지되고 있더라도 D컴포넌트가 데이터를 사용하기 위해 props를 줄줄이 전달받을 필요가 없어지게 된다.

 

내가 하는 간단 비유 요약

기존에는 props를 주고 받을때는 여러 곳에서 props를 넘겨 받아 복잡성이 커지고 위의 그림처럼 의존성을 가진 컴포넌트끼리에서는 props를 계속 주고받아야하는 관리의 어려움이 생기는데 이를 store라는 공용(?)관리소를 두어 이것의 관리를 용이하게하고 복잡성을 낮추어 준다고 생가하면 편할 것 같다.

 

비유를 하자면 한 학급에서 가위를(props)사용하는데 모든 학생이 이것을 사용하기때문에 어디서 가위가 더러워졌는지 혹은 누가 들고 있는지 항상 헷갈려서 가위를 재사용하고 다른 학생들이 사용하기에 어려움이 있었다면 이 가위는(props) 교탁(store)에서 반드시 위치하도록 하도록하여 가위를 사용하고하자는 학생(component)들이 가위를 찾고 사용하는데 어려움과 복잡성을 낮추어 준다고 비유하면 조금이나마 이해하기가 쉬울 것 같다.

 

 

이러한 Flux 패턴의 혁신적인 탄생과 함께 2015년 7월 React Europe 컨퍼런스에서 Dan Abramov라는 사람에 의해 Flux 패턴과 Reducer 개념을 도입한 Redux가 세상에 태어났다.

 

Flux 패턴은 위 그림에서 볼 수 있듯이 어떤 Action이 발생하면 dispatcher에 전달되고 Store에 저장되며 그것에 의해 View가 변경되는 일련의 과정이 끊임없이 발생한다. 이런 방식이 마치 Reduce 함수와 비슷하다고 생각하여 Reducer 함수의 개념을 도입한 것이 Redux이다.

 

참고자료

[React] Flux와 상태관리, 그리고 Redux

[React] 리덕스 (Redux) 이해하기