리액트의 Flux 패턴

MVC 패턴

보편적으로 사용하는 패턴으로는 MVC 패턴이 있다.
보다 구조적으로 프로그래밍 할 수 있도록 도와준다.

MVC 패턴이란 ?

• controller : 데이터를 다루는 로직
  ➡️ 프론트엔드에서의 controller 라고 하면 이벤트 가 있을 수 있다.

• model : 데이터

• view : 사용자 인터페이스
  ➡️ 프론트엔드단에서 실제 화면에 표시되는 HTML와 CSS의 결과물이다.

MVC 패턴의 문제점

• Model이 업데이트 되면 View는 화면에 반영한다.
• View가 또 다른 Model을 업데이트하게 되면 또 다른 View가 업데이트 된다.
  ➡️ 만약 업데이트 되는 model 이 많아지고 그 model이 전파하는 view가 많다면 문제를 예측하기 쉬울까?

MVC 패턴의 양방향 데이터 흐름은 어플리케이션이 복잡해진다면 일관된 데이터를 관리하기 어려워지게 만든다.

MVC 패턴 문제에 대한 예제로 facebook 알림 시스템이 있다. 알림이 왔다는 알림이 울렸지만 아이콘을 클릭해서 들어가면 아무런 메시지도 없던 경험이 있을것이다. 페이스북 자체에서 이를 보수했지만 다른 곳을 만지다가 또 같은 문제가 발생했고, 완전한 해결법을 원했다.

이 해결법이 단방향 데이터 흐름이었다.

단방향 흐름의 Flux 도입

Flux로의 카툰 안내서 를 요약한 내용입니다.

자기 맡은 바만 하고 전달해주면 되기 때문에 유용하다.

Redux === flux ?

데이터가 폭포수처럼 흘러내려 를 보고 요약한 내용입니다

Redux는 순수한 Flux 구현은 아니지만 Flux에서 영감을 얻은 것이다.

• Redux는 Dispatcher 개념이 없다
  ➡️ 대신 Reducer가 store + dispatcher 역할을 대신한다.
  ➡️ 모든 종류의 Reducer가 store 하나로 묶인다.
  ➡️ Redux는 리듀서가 관리하는 모든 상태를 immutable하도록 설정한다. 업데이트된 값은 기존의 상태에 overwrite되는 게 아니라 새로운 객체로 복사되어 리턴된다. 각 리듀서는 서로를 의존할 수 없고 완전히 고립되어 있다.

불변 데이터 컨셉으로 무결성을 보장하고 side-effect 없이 상태를 업데이트하도록 강제한 것은 분명 Redux의 장점입니다. 하지만 이를 위해 디스패쳐를 이용한 유연한 업데이트 방식을 포기하고, 중앙집중형 스토어를 구현함으로써 뷰가 데이터에 접근하는 방식을 무척 번거롭게 만든 것도 사실이죠.