리액트-Redux

Redux

• Flux

액션생성자

:변경사항과 상호작용이 거쳐가야 하는 액션의 생성을 담당하고 있다. 뷰를 업데이트 하려면 액션을 생성해야만 한다.

디스패쳐

:액션을 보낼 필요가 있는 모든 스토어를 가지고 있고, 액션 생성자로부터 액션이 넘어오면 여러 스토어에 액션을 보낸다.동기적으로 실행된다.

스토어

:모든 상태 변경은 반드시 스토어에 의해서 결정되어야 한다. 만약 스토어가 디스패쳐에 등록되어 있다면 모든 액션을 받게 될 것이다. 스토어에 상태 변경을 완료하고 나면,컨트롤러 뷰에 상태가 변경했다는 것을 알려주게 된다.

뷰

:발표자와 같다. 컨트롤러 뷰는 스토어와 뷰 사이의 중간관리자 같은 역할을 한다. 상태가 변경되었을때 스토어가 그 사실을 컨트롤러 뷰에게 알려주면, 컨트롤러 뷰는 자신의 아래에 있는 모든 뷰에게 새로운 상태를 넘겨준다.

• FLUX 흐름

1. 뷰는 액션 생성자에게 액션을 준비하라고 말한다.

2. 액션 생성자는 액션을 포맷에 맞게 만들어서 디스패쳐에게 넘겨준다.

3. 디스패쳐는 들어온 액션의 순서에 따라 알맞은 스토어로 보낸다. 각 스토어는 모든 액션을 받게 되지만 필요한 액션만을 골라서 상태를 필요에 맞게 변경한다.

4. 상태 변경이 완료되면 스토어는 자신을 구독(subscribe)하고 있는 컨트롤러 뷰에게 그 사실을 알린다.

5. 연락을 받은 컨트롤러 뷰들은 스토어에게 변경된 상태를 요청한다.

6. 스토어가 새로운 상태를 넘겨주면, 컨트롤러 뷰는 자신 아래의 모든 뷰에게 새로운 상태에 맞게 렌더링하라고 알린다.

http://bestalign.github.io/2015/10/06/cartoon-guide-to-flux/

에 위의 내용을 카툰으로 정리한 글인데 참고하면 매우좋다!

• Redux

1.간단한 그림

-> FLEX의 구현체이다.

2. 특징

1) 단 한개의 store를 사용

2) state is read - only

-어플리케이션에서 store의 state를 직접 변경할 수 없습니다. state를 변경하기 위해선 무조건 action이 dispatch되어야 합니다.

3)changes are made with pure function

-action 객체를 처리하는 함수를 reducer라고 부르는데, reducer는 정보를 받아서 상태를 어떻게 업데이트할지 정의 하게 됩니다. 

-reducer는 '순수함수'로 작성되어야 합니다.

즉. 네트워크 및 데이터베이스 접근 x,인수 변경x

같은 인수로 실행된 함수는 언제나 같은 결과를 반환

순수하지않은 api사용불가 (Date.now(), Math.random()등)

3. 요소

1.액션생성자

Flux에서 액션생성자를 그대로 가져왔다. 하지만 Flux와는 다르게 Redux의 액션 생성자는 디스패쳐(dispatcher)로 액션을 보내지는 않는다. 대신, 포맷을 바꾼 뒤 액션을 돌려준다.

2.store

Flux에서는 다수의 스토어를 가질 수 있다. 반면 Redux는 단 하나의 스토어만을 가진다. 만약 혼자서 모든 것을 처리하려고 한다면 아마 처리할 양이 너무 많을 것이다.대신, Redux의 스토어는 상태 트리(state tree) 전체를 유지하는 책임을 진다. 액션이 들어왔을 때 어떤 상태변화가 필요한지에 대한 일은 위임하며, 바로 다음에 이야기할 리듀서(reducer)가 그 일을 맡는다. 아마 디스패쳐(dispatcher)가 없다는 것을 눈치챘을지도 모른다. 이것은 스토어가 이 일을 넘겨받았기 때문이다.

    3.reducer

-스토어는 액션이 어떤 상태 변화를 만드는지 알 필요가 있을 때 리듀서에게 묻는다. 루트 리듀서(root reducer)는 애플리케이션 상태 객체의 키(key)를 기준 삼아 상태를 조각조각 나눈다. 이렇게 나누어진 상태 조각은 그 조각을 처리할 줄 아는 리듀서로 넘겨준다.

-아주 큰 애플리케이션이라면, 많은 리듀서를 가진 큰 리듀서 트리를 사용할 수도 있다. 이것이 Flux와 Redux의 또 다른 점이다. Flux는 스토어가 서로 연결될 필요도 없고 수평적 구조를 가졌다. 반면 Redux는 리듀서가 트리 모양의 계급구조 안에 존재한다. 이 구조는 컴포넌트 구조처럼 필요한 만큼의 레벨(트리의 높이)을 얼마든지 가질 수 있다.

     4.뷰 레이어 바인딩

스토어를 뷰에 연결하기 위해서 Redux는 약간의 도움이 필요하다. 그 둘을 함께 묶어줄 무언가가 필요한데, 이걸 해주는 것이 바로 뷰 레이어 바인딩이다. React를 사용한다면 react-redux가 그것이다.

뷰 레이어 바인딩은 세 개의 컨셉을 가지고 있다:

1. 공급 컴포넌트(provider component): 컴포넌트 트리를 감싸는 컴포넌트이다. connect()를 이용해 루트 컴포넌트 밑의 컴포넌트들이 스토어에 연결되기 쉽게 만들어준다.
2. connect(): react-redux가 제공하는 함수이다. 컴포넌트가 애플리케이션 상태 업데이트를 받고 싶으면 connect()를 이용해서 컴포넌트를 감싸주면 된다. 그러면 connect()가 셀렉터(select)를 이용해서 필요한 모든 연결을 만들어준다.
3. 셀렉터(selector): 직접 만들어야 하는 함수이다. 애플리케이션 상태 안의 어느 부분이 컴포넌트에 props로써 필요한 것인지 지정한다.

데이터 흐름(the data flow)

http://bestalign.github.io/2015/10/26/cartoon-intro-to-redux/ 참고

이제 사용자가 애플리케이션을 사용할 준비가 되었다. 액션을 하나 보내고 데이터 흐름을 확인해보자.

1. 뷰가 액션을 요청한다. 액션 생성자가 포맷을 변환한 뒤 돌려준다.

    

2. bindActionCreators()가 준비과정에서 사용되었으면 자동으로 액션이 보내진다. 그게 아니라면 뷰가 직접 액션을 보낸다.

    

3. 스토어가 액션을 받는다. 현재 애플리케이션 상태 트리와 액션을 루트 리듀서에게 보낸다.

    

4. 루트 리듀서는 상태 트리를 조각으로 나눈 뒤 알맞은 서브 리듀서로 상태 조각들을 넘겨준다.

    

5. 서브 리듀서는 받은 상태 조각을 복사한 뒤, 그 복사본을 변경한다. 루트 리듀서에게 변경된 복사본을 돌려준다.

    

6. 모든 서브 리듀서가 변경 된 상태 조각들을 돌려주면, 루트 리듀서는 이 상태 조각들을 한데 모아 상태 트리로 만든 뒤 스토어로 돌려준다. 스토어는 새로운 상태 트리를 옛날 상태 트리와 바꾼다.

    

7. 스토어는 뷰 레이어 바인딩에게 애플리케이션 상태가 변경되었다는 것을 알린다.

    

8. 뷰 레이어 바인딩은 스토어에게 새로운 상태를 보내달라고 요청한다.

    

9. 뷰 레이어 바인딩은 뷰에게 화면을 업데이트하도록 요청한다.