220921 TIL 목표는 완성하기

뽀그로 타이머 과제 리뷰 중 useState로 상태 값을 관리하던 것을 store에서 관리해야 한다는 리뷰를 받았다.

즉 Flux Architecture를 직접 적용해야 할 때가 왔다는 뜻이다.

이번 주 강의를 들으면서 가장 이해가 안 되고 어려웠던 Flux Architecture.... 그리고 추가로 구독이라는 개념이 나오면서 Pub-Sub패턴도 배웠는데 이것 또한 이해하기가 쉽지 않았다.

 

일단 내가 지금까지 내가 이해한 Flux Architecture에 대해 먼저 정리해보자.

 

Flux Architecture

우선 Flux Architecture는 MVC패턴의 한계를 해결하기 위해 등장한 아키텍처라고 한다.

MVC패턴은 데이터 흐름이 양방향이기 때문에 애플리케이션의 복잡도가 높아 확장하기가 어렵다.

 

MVC패턴

 

반면에 Flux Architecture는 단방향 데이터 흐름을 통해 보다 예측 가능하게 상태를 관리할 수가 있다.

 

Flux  Architecture

 

Flux Architecture의 구조에 Action, Dispatcher, Store, View가 있다.

• Action : Dispatcher에 전달되는 데이터(상태 변경 요청 메서드)를 담은 객체
• Dispatcher : 모든 데이터 변경 요청이 경유하는 중앙 허브 (내부에 상태 변경 로직이 존재하지 않는다.)
• Store : 애플리케이션의 상태와 로직을 포함하며 상태를 변경하는 역할을 한다.
• View : 상태에 따라 화면을 그리는 뷰의 역할을 한다.

 

내가 이해한 Flux Architecture에서 데이터의 흐름은 아래와 같다.

• View에서 Action이 발생하면 Dispatcher가 이를 수신해 각각의 Store에게 전달한다.
• Action을 전달받은 Store는 관심 있는 Action에 대해 상태를 변경하고 변경된 상태를 View에게 알려준다.
• View는 변경된 상태에 따라 화면을 새로 그린다.
• 만약 View에서 다른 Action이 발생하면 위 사진과 같은 사이클이 반복이 된다.

 

간단하게 요약하면 action이 Dispatcher으로 전달이 되고 Dispatcher으로 전달된 Action들이 Store로 전달이 되고 Store에서 상태를 바꾸고 상태가 바뀌었음을 View에게 알려준다. 이후 view는 변경된 상태에 따라 화면을 다시 렌더링 한다.

 

그러면 과제에서 이 Flux Architecture를 어떻게 적용시킬 수 있을지는 다양한 실험을 해보면서 Flux Architecture를 씹고 뜯고 맛보자 하지만 그럴 여유가 없을 것 같다는 것을 시계를 본 순간 깨달았다... 벌써 목요일이 다 와가는데 과제를 반도 못한 거 같은 느낌이라...

금요일까지 과제를 다 완성시킬 수 있을지도 의문이다. 

 

일단 오늘 밤샘을 각오하고 어떻게든 완성시켜보자!

목표는 어떻게든 작동이 되는 뽀그로 타이머!!