flux는 flow에서 유래된 것인데
자기 스스로 반응하지 않으면서 다른 물질의 반응을 촉진시키는 촉매역할 이라고 볼 수 있다
flux를 사용하는 방식이 여러가지가 있는데
핵심은 자기 스스로 반응하지 않으면서 다른 물질의 반응을 촉진시키는 촉매역할이라는 것이다
핵심을 잘 파악해야한다
flow라는 흐름에서 유래된 것 처럼 지속적이라는 성질이 있다
흐름안에서 다른 요청에 의해 반응할 수 있다
이게 flux이다
그림처럼 어떤 흐름이 존재 할 때
유저 이름 ssar이라는 것이
위에도 존재하고 아래에 내용에도 존재하고
계속해서 존재한다고 했을 때
RestController 기준으로 데이터를 응답해주는데
자바스크립트 관점에서는 각 데이터를 가져와야할 경우
우리는 저것을 가져와야하는데 MVC패턴으로보면
유저이름 ssar은 user라는 컨트롤러에 있을 것이고
내용이라는 것은 Board라는 컨트롤러에 있을텐데
두개의 MVC가 다른 것이다
우리는 그것을 fetch라는 함수를 이용해서 요청을 통해서 가져와야한다
그 주소는 각자 다른 주소를 가지고 있다
/user
/board
이렇게 다르다고 할 때
최초의 이 데이터를 다 받아오는데
2번의 요청을 통해 해당 데이터를 다 받아오는데
fetch -> 요청 -> /user /board
만약우리가 유저이름 ssar을 cos라는 이름으로 수정하고 한다면
컨트롤러에 함수가 하나 더 필요한데
/user/1/cos 이렇게 변경을 하기위해서는 컨트롤러에 함수가 필요한데
이걸 post로 요청을 하는 것이다
최초에는 get을 2번해서 데이터를 가져와서 완성을 했고
수정은 post가 필요하다고 이해하면 된다
post를 통해서 자바스크립트에서 응답을 받아서 cos로 변경하는데
cos로 내용을 바꾸려면 어떻게 해야할까?
유저이름 ssar -> cos 이렇게 변경만 하고 끝내면될까?
아니다
밑에있는 ssar들도 전부 cos로 변경해야한다
그림을 보면 아래에 있는 내용에 있는 ssar도 전부 바꿔줘야한다
그렇지않으면 데이터의 동기화가 일어나지 않는다
이게 기존 MVC이다
이 MVC를 설계할 때 어려운점은 연관되어있는 모든 ssar을 다 찾아내서
가장 위에있는 ssar뿐만 아니라 아래에있는 모든 ssar을 다 바꿔줘서
UI동기화를 시켜야한다
연관된 모든 데이터를 찾아내서 전부 바꿔주기 위한 방법을 알아봐야한다
만약 데이터가 1억개라고 하면 1억개를 전부 찾아내서 바꿔줘야 동기화가 일어난다
그걸 하지 않으려면
post수정을 요청하면 자동으로 모든 ssar을 전부 select를 해줘야한다
mvc패턴에서 mvvm패턴이라고 다른 패턴이 있다
뷰모델이라는 모델 개념인데
mvvm패턴에서
뷰모델한테 아까처럼 /user /board 이렇게 2번 요청하는 것이 아니라
/feed라고 했을 때 /feed를 통해 한번에 전부 다 데이터를 주는 방식을 써야한다
누가? 뷰모델이
그럼 그걸 받아서 post수정하고 이런 방식이 있는데 안드로이드에서 자주 사용된다
위 내용에 특징은 요청을 해야 준다는 것이다
요청하지 않으면 반응하지 못한다
요청을 하면 어디에 필요한지 하나하나 찾아서 요청해야지 받을 수 있다
위 그림을 보면 ssar이라는 것을 cos로 바꾸려고 할 때
만약 바꿔야하는 개수가 3개라고 하면 request를 각각 요청해서 총 3번을 요청해야한다
하지만 모든 ssar들이 구독이라는 것을 하게 만들어서
ssar과 연결이 되어있다면? 이것이 바로 flow흐름이라는 것인데
그 흐름을 타고 있으면 ssar하나를 cos로 request 즉 요청을 때리면
연결되어 있는 모든 구독자들이 하나의 요청으로 전체가 변경되게 된다
즉 ssar-> cos 이것이 바로 촉매역할이다 촉매가 일어나서
모든 값이 한번에 변경되는 것이다 촉매제가 되는 것!
이것이 flux 패턴이다
한번에 요청에 촉매되는 모든 애들이 반응하는 것
계속해서 요청하는 것 보다 구독하고 있는 방식을 쓰면
훨씬 편하다
단순한 ui에서는 각각 요청하는게 편하다
왜냐면 구독하는 방식을 짜는게 더 복잡하기 때문인다
늘 장단점이 존재하는데 복잡한 ui에서는 애초에 구독을 설계하는게 훨씬 이득이다
이걸 web관점에서 webFlux로 생각하고 여러 화면이 있다고 하면
3개의 화면이 모두 같은 데이터를 가지고 있다고 해보자
모두 ssar이라는 데이터를 가지고 있다고 가정 했을 경우
a가 요청을 하고 a에 있는 모든 구독하고 있는 것들을 하나의 요청으로
한번에 변경하면 되는데 문제는 나머지 두 화면은 바뀌지가 않고 있다면
이럴 경우에는 3개의 response를 끊지말고 그대로 두는 것이다
이 response들이 해당 데이터를 구독하고 있으면 된다
그림처럼
이렇게 3개의 response를 끊지않은 상태로 해당 response가 전부 데이터를 구독하게되면된다
flux를 어떻게 설계하느냐에따라 활용도는 무궁무진하다
결국 flux는 어떤 요청에 의해서 반응하는 촉매역할을 한다는 것을 계속 기억해야한다
내가 flux를 설계할 수도 있지만 내가 하는 것 보다는
facebook에서 만들어놓은 아름다운 인터페이스 패턴을 쓰는 것이 훨씬 효율적이다
그걸 쓰기위해서 우리는 리액트에서 redux라는 것을 사용할 것이다
이 redux를 이용해서 flux를 할 수 있는 것이다
사용자가 요청을 하면 -> 그 요청을 누가받냐? dispatcher가 받고 -> 그 요청을 다 분리하고
-> 어떤 스토어로 갈지 결정을 하고 각 스토어로 뿌린다 -> 그걸 각 스토어에서 받는다
예를 들어 요청이 4개가 있다고 했을 경우
a라는 요청을 하면 디스패쳐가 a라는 요청을 찾는 것이 아니라
각 스토어에 전부 던지고 그걸 받은 스토어에서 나에게 맞는 스토어를 찾아낸다
그걸 브로드캐스팅 하는 것이다
그 요청을 스토어가 받아서 나에게 맞는 요청을 골라내고 그 데이터를
예를들어 ssar->cos 변경 요청을 골라내서 그 요청을 스토어가 응답해주는 것이다
모든 구독하고 있는 데이터를 응답해서
그 데이터를 구독하고있는 모든 것들에게 영향을 끼치는 것이다
어렵지만 계속해서 정리해나가면서 이해하면 될 것 같다
그림을 통해서 한번 더 이해하기 쉽게 정리해두고 이해가 안갈 경우 계속 찾아보자
해당 state 즉 상태가 변경이되면 그 스토에서 변경된 상태를 구독하는 모든 데이터가 변경된다
a라는 요청 즉 촉매를 통해 모든 것들이 반응하는 것이다
리액트는 부모에서 자식을 컨트롤 할 수 있는데
자식이 부모를 컨트롤 할 수는 없다
또한 다른 줄기 즉 우측에 있는 버튼을 클릭해서
좌측 아래에 있는 데이터에 값을 변경하거나 수정하는 것을 불가능하다
이럴 경우 우리가 할 수 있는것이 redux를 통해서 flux패턴을 적용하는 것인데
흐름을 아래로 뻗어가게 한다고 했을 경우
각 데이터 즉 ssar이라는 이름을 cos라는 이름으로 변경하기 위해서
그 데이터를 따로 store라는 곳에서 관리를 하는 것이다
그렇게 되면
그 스토어를 구독하고 있는 모든 데이터는 실제로 요청을 하지 않았지만
버튼을 통해서 스토어에 있는 이름을 변경하게 되면
그 변경된 이름을 구독하고 있는 모든데이터는 동시다발적으로 수정이 되는 것이다
이것을 redux를 통해서 flux화 하는 것이라고 할 수 있다
그림처럼
해당 파일에서 버튼을 만들고 버튼을 눌러서 수정을 하면
그 파일 안에서만 데이터가 수정되고
다른 곳에서 그 데이터를 거슬러서 컨트롤 할 수 없는데
store에 데이터를 넣어두면
그 스토어를 모든 데이터가 구독하고 있게 설계하고
버튼을 통해서 그 스토어의 값을 변경해주면
구독자들은 자동으로 수정된다고 생각하면 된다
