내가 사용하고 돌아 오는-사가 . JS 생성기 함수가 때때로 내 머리를 망쳐 놓는 것을 제외하고는 지금까지 작성된 코드가 추론하기 쉽습니다. 내 이해에서 Redux-Observable 은 부작용을 처리하지만 생성기 기능을 사용하지 않고 비슷한 작업을 수행 할 수 있습니다.

그러나 Redux-Observable의 문서는 왜 Redux-Saga보다 우수한 지에 대한 많은 의견을 제공하지 않습니다. 발전기 기능을 사용하지 않는 것이 Redux-Observable을 사용하는 유일한 이점인지 알고 싶습니다. 그리고 Redux-Saga 대신 Redux-Observable을 사용할 때의 단점, 단점 또는 타협은 무엇입니까? 미리 감사드립니다.

면책 조항 : 저는 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와 싸우지 않습니다.

고려해야 할 사항이 있다고 생각합니다.

1. 복잡성
2. 코딩 스타일
3. 학습 곡선
4. 테스트 가능성

API에서 사용자를 가져오고 싶다고합시다.

// 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'})
        )

또한 Redux-saga와 Redux-Observable의 차이점을 자세히 비교하기 위해이 기사를 작성했습니다. 체크 아웃 이 여기 링크 또는 프리젠 테이션을 .

Redux-Saga보다 Redux-Observable을 사용합니다. 발전기보다 Observable을 사용하는 것을 선호하기 때문입니다. RXJS와 함께 사용하는데, 이는 데이터 스트림 작업을위한 강력한 라이브러리입니다. 비동기를 위해 lodash처럼 생각하십시오. 단점 중 하나를 선택하는 데있어 단점과 단점 은 Jay Phelps의 다음 답변 을 살펴보십시오 .

프로젝트로서의 redux-saga는 redux-observable보다 오래 존재했기 때문에 확실히 하나의 주요 판매 포인트입니다. 더 많은 문서, 예제를 찾을 수 있으며 지원을받을 수있는 더 나은 커뮤니티가있을 수 있습니다.

redux-saga에서 배우는 연산자와 API는 RxJS를 배우는 것만 큼 거의 양도 할 수 없다는 것이 문제입니다. redux-observable은 내부적으로 매우 간단합니다. RxJS를 사용하는 자연스러운 방법입니다. 따라서 RxJS를 알고 있거나 원하는 경우 매우 자연스럽게 맞습니다.

대부분의 사람들에게 내 충고는 당신이 사용해야 할 것이 있으면 redux-saga를 선택해야한다는 것입니다.

Redux-Observable은 놀라운 라이브러리이며 지금까지 아무런 문제없이 1.5 년 동안 프로덕션 환경에서 사용하며 완벽하게 테스트 가능하며 모든 프레임 워크와 쉽게 통합 할 수 있습니다. 우리는 병렬 소켓 채널에 과부하가 걸렸으며 동결로부터 우리를 구하는 유일한 것은 Redux-Observable입니다.

여기에 언급하고 싶은 3 점이 있습니다.

1. 복잡성과 학습 곡선

Redux-saga는 여기서 쉽게 redux-observable을 능가합니다. 인증을 받기 위해 간단한 요청이 필요하고 어떤 이유로 redux-thunk를 사용하고 싶지 않은 경우 redux-saga를 사용하는 것이 좋습니다. 이해하기 쉽습니다.

Observable에 대한 사전 지식이 없다면 고통스럽고 팀이 당신을 도울 것입니다 :)

2. Observable 및 RxJS가 제공 할 수있는 것은 무엇입니까?

비동기 로직에 관해서 Observable은 스위스 칼이며, Observable은 문자 그대로 거의 모든 것을 할 수 있습니다. 약속이나 발전기와 비교하면 안됩니다. 옵티머스 프라임과 시보레를 비교하는 것과 같습니다.

RxJS는 어떻습니까? lodash.js와 비슷하지만 비동기 논리의 경우 일단 다른 것으로 전환하지 않습니다.

3. 반응성 확장

이 링크를 확인하십시오

http://reactivex.io/languages.html

리 액티브 확장은 모든 현대 프로그래밍 언어에 대해 구현되며 기능 프로그래밍의 핵심입니다.

따라서 시간을 현명하게 RxJS를 배우고 redux-observable을 사용하십시오 :)

Rx의 언어와 런타임 간의 전송 성을 높이 평가합니다. 앱에서 언어가 변경되지 않더라도 경력이 커질 수 있습니다. 학습에 최대한 활용할 수 있지만 자신을 위해 크기를 늘리십시오. 특히 .Net LINQ에 대한 훌륭한 게이트웨이입니다.

여기에 redux 관찰 가능한 이야기가 많이 있기 때문에, 나는 논쟁의 사가 측면을 줄 것이라고 생각했을 것입니다. 나는 redux-observable 또는 RxJS를 사용하지 않기 때문에 나란히 비교할 수는 없지만 sagas를 사용하여 큰 효과를 얻었습니다.

그 가치에 대해서는 웹 응용 프로그램에서 프로덕션 환경에서 sagas를 사용하고 있습니다.

사 가스 대 썽크

사가가 승리합니다. 나는 펑크가 액션 제작자에게 논리를 넣는 방식이 마음에 들지 않았다. 또한 몇 번의 요청을 한 번에 번거롭게했습니다. 나는이 일에 대한 redux-observable을 간단히 보았지만 Sagas에 정착했습니다.

Sagas를위한 학습 곡선

발전기가 무엇이고 왜 중요한지 이해하는 것이 사가를 이해하는 열쇠입니다. 하지만 난 당신 이하지 스트레스 발전기를 안팎으로 알 필요 . yield 문을 사용하여 제어권을 넘기고 비동기 코드가 해결 된 후 saga가 제어권을 다시 전달한다는 사실 만 알면됩니다. 그 후, 사가에서 무슨 일이 일어나고 있는지 이해하기가 그리 어렵지 않습니다.

핵심 사가 방법은 다음과 같습니다.

• call-임의의 코드를 호출하고 반환 값을 얻습니다. 약속을지지합니다. 비동기 처리와 sagas 사이의 큰 시너지 효과.
• select-셀렉터에게 전화하십시오. 이 비트는 다소 훌륭합니다. 선택기는 redux의 핵심 요소이며 100 % 지원됩니다!
• put-일명 dispatch행동. 실제로 원하는만큼 파견하십시오!

다른 기능도 있지만이 세 가지를 마스터 할 수 있다면 정말 좋은 위치에있게됩니다.

결론

내가 사가를 선택한 이유는 사용의 용이성 때문이었습니다. redux-observable은 도전적인 것처럼 보였다. 나는 사가에 100 % 만족합니다. 내가 기대했던 것보다 더 행복해.

내 경험상, Sagas는 썽크보다 (길이) 더 좋고 상대적으로 이해하기 쉽습니다. Rx는 모든 사람의 차가 아닙니다. 생태계에서 나오지 않거나 앞으로 Rx를 사용할 계획이 없다면 redux-observable 대신 sagas를 강력하게 고려할 것입니다.

Typescript로 응용 프로그램을 작성하는 경우 typeless를 확인하는 것이 좋습니다 . Redux-Observable에서 영감을 얻었으며 RxJS에 의존하지만 앱을 구축하기위한 전체 생태계가 있습니다.

redux-observable / redux-saga의 가장 큰 단점은 지침이 부족하다는 것입니다. 부하 감속기, 가스 또는 에픽을 게으르게하는 방법에 대한 공식 지침은 없습니다. 더 큰 앱을 확장 할 때는 코드 분할이 중요합니다. 지연 로딩을위한 맞춤형 솔루션은 일반적으로 개발자 경험을 저하시키는 HMR과 함께 작동하지 않습니다.

타입리스 프로 :

1. TypeScript 용으로 설계
   모든 API는 typescript 및 형식 안전성을 위해 설계되었습니다.
   • Typescript는 생산성을 높이고 속도를 늦추지 않습니다.
   • 필요한 주석 만 필요합니다 : state, action arguments.
   • 타입 캐스팅이 없습니다. 모든 것이 자동으로 추론됩니다. 코드의 95 %가 순수한 자바 스크립트처럼 보입니다.
   • RootAction, RootEpic, RootState 또는 기타 도우미 유형이 없습니다.
2. 모든 빌딩 블록 제공
   • Typeless에는 중간 규모 또는 엔터프라이즈 급 앱을 빌드하기위한 모든 것이 포함됩니다.
   • 여러 개의 작은 라이브러리에 의존 할 필요가 없습니다.
3. 모듈성
   • 확장 가능한 앱을 구축하려면 적절한 모듈성이 중요합니다.
   • epics, 리듀서, 유형 등을위한 루트 파일을 만들 필요가 없습니다. 새 모듈을 만든 후에는 어느 곳에서나 연결할 수 있습니다. 표준 React 구성 요소와 유사합니다.
4. 의견
   • 모든 일반적인 사용 사례와 문제는 기본적으로 해결됩니다. 사소한 문제를 해결하는 방법을 지나치게 생각할 필요가 없습니다.
   • 모든 권장 사항과 모범 사례가 제공됩니다!

https://typeless.js.org/를 확인 하십시오.