React's One-way Data flow
단방향 데이터 흐름과 Flux 패턴
웹 앱 개발에 대해 다시 생각하다.
Facebook은 전통적인 디자인 패턴인 MVC가 그들의 필요에 맞게 확장되지 않는다는 결론에 도달했고, 대신 Flux 패턴을 도입 사용 했음을 발표했습니다. 시스템의 복잡성은 코드를 "깨지기 쉽고 예측할 수 없게 만든다" 이 문제를 해결 하려면 "예측 가능한 방식으로 코드를 구성" 해야 함을 강조했습니다.
이러한 그들의 생각은 Flux 아키텍처, 그리고 React로 이어졌습니다. Flux는 앱의 단방향 데이터 흐름을 촉진하는 시스템 아키텍처를 말합니다. 그리고 React는 Facebook이 웹 애플리케이션 개발에서 더 빠르게 작동할 수 있는 "예측 가능한", "선언적인" 웹 사용자 인터페이스를 구축하기 위한 JavaScript 프레임워크입니다.
Facebook 소프트웨어 엔지니어 Jing Chen은 MVC가 소규모 애플리케이션에 적합하지만, 슬라이드에 표시(아래 참고)된 것처럼 시스템에 많은 모델과 뷰가 추가되면 복잡성이 폭발적으로 증가한다고 주장했습니다.
Facebook의 MVC 해석 논란?
Facebook의 발표에 많은 개발자들은 Facebook에서 MVC 패턴에 대해 잘못 알고 있다고 생각했습니다. 아래 글은 문제가 있다고 말한 몇몇 개발자들의 생각입니다. (참고)
giveupitscrazy (현재 삭제 됨)
이것은 말이 되지 않습니다. 그들의 MVC 패턴 그림은 문제가 있습니다. 여러 모델을 처리하기 위해 단일 컨트롤러를 묘사하고 있습니다. 물론 그들이 설명한 설정은 문제가 있지만, 그것은 실제 MVC도 아닙니다. 실제 MVC 다이어그램과 비교하면 MVC에 본질적으로 문제가 없다는 것을 알 수 있습니다.
Flux 다이어그램은 MVC와 매우 유사합니다. 그들은 MVC를 다시 그려 새로운 이름을 붙였을 뿐입니다.
이에 발표자 Jing Chen으로 보이는 아이디 jingc09는 댓글을 남겨 발표의 진의에 대해 이야기했습니다.
문제는 MVC가 아니라, 양방향 데이터 흐름
전달이 쉽지 않은 발표였던 것 같습니다. 특히 "모델과 뷰, 양방향 데이터 흐름" 슬라이드가 말이죠. 아마도 MVC가 정확히 무엇인 지에 대한 합의가 없었기 때문이 아닌가 합니다. 그것에 대해 사람들은 각기 다른 생각을 가지고 있습니다. 우리가 정말로 반대하는 것은 MVC가 아니라 "양방향 데이터 흐름" 입니다. 하나의 변경 사항이 반복되면 연속적으로 악영향을 미칠 수 있기 때문입니다.
Flux와 MVC는 다름
명확한 것은 디스패처(Dispatcher)가 MVC의 컨트롤러와 같은 역할을하지 않는다는 것입니다. 디스패처에는 비즈니스 로직이 없으며 여러 애플리케이션에서 동일한 디스패처 코드를 사용합니다. 이벤트를 구독 중인 구독자(일반적으로 스토어(Store))에게 도달하는 중앙 허브일 뿐입니다.
MVC의 컨트롤러는 모델에 명령을 보내 모델의 상태를 업데이트 할 수 있습니다. 그리고 연결 된 뷰에 명령을 보내 모델의 뷰 표시를 변경할 수 있습니다.
하지만 Flux의 디스패처는 이를 수행 할 수 없으며, 명령은 다른 곳(뷰, 서버 응답, 라이브 업데이트)에서 시작하여 디스패처를 통과해야 합니다.
논란에 대한 왈가왈부(曰可曰否)
Facebook이 Flux 패턴을 소개하면서 꺼낸 MVC 패턴 이야기가 논란이 되었고, 이에 대한 생각은 국내 개발자 또한 동의하는 듯 보입니다. 다소 과장 된 비교로 인해 빚어진 일이라고 생각됩니다. MVC 패턴이 아닌, 양 방향 데이트 흐름에 문제가 있음을 Jing Chen이 해명했지만, 잘못된 비교로 진의가 제대로 전달되지 못한 것에 씁슬하지 않았을까요? 😩
마치며.
어쨌든 Facebook의 Flux 아키텍처는 React 그리고 Redux의 데이터 흐름의 핵심입니다. 잘못된 MVC 패턴과의 비교에 초점을 두지 말고, React는 "하향식 단방향 데이터 흐름"에 따라 작동 됩니다.
Last updated
Was this helpful?