[WEB] React, Flux Architecture

아!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

이번에 강의 들으면서 Redux 배웠는데, 굉장히 깔끔한것 같더라구요.

일단 그에 앞서서 Flux 에 대해서 알아보겠습니다.

​

Facebook을 만들때 여기도 디자인패턴이 있었겠죠? MVC, MVVM 등등.. 있겠지만,

페이스북은 MVC의 단점에 대해서 알게 되었습니다.

중앙화되어있지 않은 변경과, race condition, cascading update등등.. 여러 문제가 발생했습니다.

​

MVC에서 V는 model,controller랑 둘다 연락합니다.

이런거대신에 Unidirectional Flow를 생각해냈습니다.

​

폭포수가 양방향으로 흐르진 않잖아요? 한국어로하면 유량 아키텍처 이런느낌인데;; 쩝 이걸 어케 알아먹습니까?

단방향으로 흐릅니다.

​

근데 왜쓰냐고요?

1.

Redux때도 말하겠지만, 일단 data가 centralized 되어있습니다. Model처럼 활용이 되고있어요. 굉장히 프로그램이 커지면 중앙 데이터 센터가 있는게 관리가 더 편할 것 입니다.

2.

어디가 잘못되면 data의 변화를 찾기가 훨씬 좋습니다. 양방향이면 이게 어디서 바뀐지 찾는게 쉽지 않겠죠?

마음으로 이해해봅시다.

 

Flux Architecture
페이스북이 선택한 아키텍처

* 그림과 순서는 지금은 알 수 없습니다. 지금 한번 보고 아래의 용어 설명을 보고나서 최종적으로 이해를 해보세요.

순서 :

1. View에서 어떤 Action(Event 내용)가 발생합니다.

2. Action은 Dispatcher(배달원)에게 보냅니다

3. Dispatcher(배달원)이 Store로 배달을 해줍니다.

4. 그다음 Store에서 Action의 내용에 맞게 수정을 해주고, change event를 발생시킵니다.

5. (subscribe 했다는 가정하에) View는 new data를 받아서 re-render을 합니다.

​

페이스북의 공식 github에서 가져온 내용입니다.

일단 저것만 보고는 알 수 없습니다. 용어에 대해서 알아봅시다

​

1. Action

-> 이벤트라고 라고 생각하면 됩니다. 어떤 행동을 할건지? 어디에 할건지? 이런 내용이 담겨있습니다.

js object형태로 보냅니다.

참고로 type은 좀 구체적인 기능으로 담겨있어야 합니다.

// descriptive 하지 않은 type
{
   type : 'delete-user',
   payload : '1345'
}

// descriptive
{
   type : 'delete-user-name',
   payload : '1345',
}

첫번째꺼는 뭘 지울건지 정확히 안나와있습니다. 이름을 지울지, 전체 데이터를 지울지 등등 .. 정확하게 써야합니다.

​

​

2. Dispatcher

Action이 직접 store로 가서 값을 바꿀수는 없습니다. 배달기사에게 요청을 해야합니다.

store로 가져가 주는 배달원이라고 생각하면 됩니다.

Action을 Dispatcher에게 주면 dispatcher가 Store로 가지고 간답니다.

​

Store에서는 모든 action을 디스패처로부터 받는답니다.

​

3. Store

Store는 말 그대로, data 저장소라고 보시면 됩니다. Dispatcher로 부터 받아온 action을 통해서 data를 수정합니다.

그리고 data는 반드시 action에 의해서만 수정이 되어야 합니다. (data는 read-only 입니다)

따라서 setter는 없고, getter만 있습니다.

store의 data가 수정되면 change event를 발생시켜야 합니다.

​

4. View

Store에서 받아온 Data를 보여주는 장소입니다. 만약 view가 store의 data를 받아서 사용할때는 store의 change event를 subscribe 하고 있어야 합니다.

(마치 유튜브에서 누가 새로운 동영상 올리면 구독을 하면 알림이 오는 느낌입니다. 오우 비유 좋았고)

store에서 값이 변하면 change event를 보낸다고 했죠? 그러면 그걸 받으면 view는 new data를 받고 re-render을 한답니다.

​

만약 구독을 안하면 사소한 버그들이 발생할 수 있다고 합니다. 제가 구독을 안해본적은 없어서 잘 모르겠네요^^.

​

결론 :

user의 input에 의해서 값이 변경되거나 그러면 직접 Store의 값을 바꿀 순 없고 action을 보내야만 가능하다.

​

순서 :

1. View에서 어떤 Action(Event 내용)가 발생합니다.

2. Action은 Dispatcher(배달원)에게 보냅니다

3. Dispatcher(배달원)이 Store로 배달을 해줍니다.

4. 그다음 Store에서 Action의 내용에 맞게 수정을 해주고, change event를 발생시킵니다.

5. (subscribe 했다는 가정하에) View는 new data를 받아서 re-render을 합니다.

https://github.com/facebook/flux/tree/master/examples/flux-concepts

GitHub - facebook/flux: Application Architecture for Building User Interfaces

 

​

아.. 근데 Flux 패키지가 있긴 한데..

이걸 왜 안쓰냐면.. 실제로 큰 프로그램에서 쓸만큼 잘 되어있지 않고, 저런 아키텍처를 흉내낸 정도라서 대중화 되지 못했답니다.

​

대신에 Redux라는 js state container가 생겼습니다.

flux-like -architecture를 실제화 한 것 이라고 보면 됩니다.

*완전히 flux-architecture은 아닙니다. 이 친구는 dispatcher도 없고, react뿐만이 아니고 엄청나게 많은 프레임워크들에서 쓰일 수 있습니다.

​

아 ㅋ 1편 더 뽑아먹기 위해서 Redux는 내일로 미뤄야겠습니다.

쓰다보니까 양이 많네요 ㅎㅎ;;

죄송함당

-끝-