면책 조항 : 저는 redux-observable의 저자 중 한 명이므로 100 % 공평하기가 어렵습니다.

현재 redux-saga보다 redux-observable이 더 좋은 이유는 없습니다. 😆

tl; dr 둘 다 장단점이 있습니다. RxJS (redux-observable) 또는 제너레이터 / “데이터의 영향”(redux-saga)을 모른다면 둘 중 하나는 다른 것보다 직관적 인 것이지만 둘 다 다른 방식으로 학습하기가 복잡합니다.

그것들은 똑같은 문제를 매우 비슷한 방식으로 해결하지만, 일단 충분히 사용하면 분명하게 드러나는 근본적인 차이점이 있습니다.

redux-observable은 거의 모든 것을 관용적 RxJS로 연기합니다. 따라서 RxJS에 대한 지식이 있거나이를 얻는다면 redux-observable을 배우고 사용하는 것은 매우 자연 스럽습니다. 이는 또한이 지식이 redux 이외의 것으로 옮겨 질 수 있음을 의미합니다. MobX로 전환하기로 결정한 경우 Angular2로 전환하기로 결정한 경우, 향후 핫 니스 X로 전환하기로 결정하면 RxJS가 도움을 줄 수있는 가능성이 매우 높습니다. 이는 RxJS가 일반적인 비동기 라이브러리이기 때문에 여러면에서 전체 “반응 형 프로그래밍”패러다임 자체가 프로그래밍 언어와 비슷하기 때문입니다. RxJS는 2012 년부터 존재했으며 Rx.NET 포트로 시작했습니다 (거의 모든 주요 언어로 “포트”가 있으므로 유용합니다 ).

redux-saga는 시간 기반 연산자 자체를 제공하므로이 프로세스 관리자 스타일의 생성기 및 부작용 처리에 대한 지식은 이전 할 수 있지만 실제 연산자와 사용법은 다른 주요 라이브러리에서 사용되지 않습니다. 그래서 그것은 약간 불행한 일이지만, 그 자체로 거래 차단기가되어서는 안됩니다.

또한 “데이터로 효과”( 여기에 설명 )를 사용하여 처음에는 머리를 감쌀 수 없지만 redux-saga 코드는 실제로 부작용 자체를 수행하지 않습니다. 대신, 사용하는 도우미 함수는 부작용을 수행하려는 의도를 나타내는 작업과 유사한 개체를 만든 다음 내부 라이브러리가이를 수행합니다. 이것은 조롱 할 필요없이 테스트를 매우 쉽게하고 일부 사람들에게 매우 매력적입니다. 그러나 나는 개인적으로 단위 테스트가 사가의 논리를 상당 부분 다시 구현한다는 것을 알았습니다.이 테스트는별로 유용하지 않습니다. (이 의견은 모든 사람이 공유하지는 않습니다)

사람들은 종종 redux-observable을 사용하여 왜 그런 일을하지 않는지 묻습니다. 나에게 그것은 일반적인 관용적 Rx와 근본적으로 호환되지 않습니다. Rx에서는 .debounceTime()디 바운스에 필요한 로직을 캡슐화하는 것과 같은 연산자를 사용 하지만 실제로 디 바운싱을 수행하지 않고 의도적으로 태스크 객체를 생성하는 버전을 만들고자한다면 Rx의 힘은 오퍼레이터가 실제 작업 결과가 아니라 해당 태스크 객체에서 작동하기 때문에 더 이상 체인을 연결할 수 없기 때문입니다. 이것은 우아하게 설명하기가 정말 어렵습니다. 접근 방식의 비 호환성을 이해하려면 Rx에 대한 많은 이해가 필요합니다. 당신이 경우 정말 그런 일을하려면, 체크 아웃 REDUX 사이클을cycle.js를 사용하고 대부분 그 목표를 가지고 있습니다. 나는 그것이 내 취향에 너무 많은 의식을 필요로한다는 것을 알지만, 관심이 있다면 회전하도록 권유한다.

ThorbenA가 언급했듯이, redux-saga가 현재 redux의 복합 부작용 관리 분야에서 (10/13/16) 확실한 리더임을 인정하지 않습니다. 이전에 시작되었으며보다 강력한 커뮤니티가 있습니다. 따라서 새로운 어린이에 대한 사실상의 표준을 사용하는 데 많은 매력이 있습니다. 사전 지식없이 사용하면 혼란스러워하는 것이 안전하다고 생각합니다. 우리는 둘 다 일단 “이득”하면 복잡한 부작용 관리를 훨씬 쉽게 만들 수 있지만 그 때까지는 많은 우연히 발견되는 상당히 고급 개념을 사용합니다.

내가 줄 수있는 가장 중요한 조언은 라이브러리를 필요로하기 전에 가져 오지 않는 것입니다. 간단한 아약스 호출 만하는 경우에는 필요하지 않을 것입니다. redux-thunk는 배우기가 간단하고 기본 사항을 충분히 제공하지만, 비동기가 복잡할수록 redux-thunk가 어려워 질 수도 있습니다. 그러나 여러 가지면에서 redux-observable / saga의 경우 비동기가 가장 복잡합니다. 같은 프로젝트에서 redux-thunk를 다른 것들 중 하나 (redux-observable / saga)와 함께 사용하면 많은 장점이 있습니다! 일반적인 간단한 것들을 위해 redux-thunk를 사용하고 복잡한 것들을 위해 redux-observable / saga 만 사용하십시오. 그것은 생산성을 유지하는 좋은 방법이므로 redux-thunk로 사소한 일을 위해 redux-observable / saga와 싸우지 않습니다.

답변

// Redux-Saga

import axios from 'axios'

function* watchSaga(){
  yield takeEvery('fetch_user', fetchUser) // waiting for action (fetch_user)
}

function* fetchUser(action){
    try {
        yield put({type:'fetch_user_ing'})
        const response = yield call(axios.get,'/api/users/1')
        yield put({type:'fetch_user_done',user:response.data})
  } catch (error) {
        yield put({type:'fetch_user_error',error})
  }
}

// Redux-Observable
import axios from 'axios'

const fetchUserEpic = action$ =>
    action$
        .ofType('fetch_user')
        .flatMap(()=>
          Observable.from(axios.get('/api/users/1')) // or use Observable.ajax
            .map(response=>({type:'fetch_user_done', user:response.data}))
            .catch(error => Observable.of({type:'fetch_user_error',error}))
            .startWith({type:'fetch_user_ing'})
        )