Pourquoi utiliser Redux-Observable sur Redux-Saga?
J'ai utilisé Redux-Saga . Le code écrit avec est facile à raisonner jusqu’à présent, sauf que la fonction de générateur JS me dérange de temps en temps. De ma compréhension, Redux-Observable peut réaliser le même travail qui gère les effets secondaires, mais sans utiliser la fonction de générateur.
Cependant, la documentation de Redux-Observable ne donne pas beaucoup d'opinions sur sa supériorité face à Redux-Saga. Je voudrais savoir si le fait de ne pas utiliser la fonction générateur est le seul avantage de l'utilisation de Redux-Observable. Et quels pourraient être les inconvénients, les pièges ou les compromis liés à l’utilisation de Redux-Observable au lieu de Redux-Saga? Merci d'avance.
Clause de non-responsabilité: je suis l'un des auteurs de redux-observable, il est donc difficile pour moi d'être totalement impartial.
Nous ne fournissons actuellement aucune raison pour laquelle redux-observable est préférable à redux-saga parce que ... ce n'est pas le cas. ????
il y a des avantages et des inconvénients pour les deux. Beaucoup trouveront l’un plus intuitif l’un que l’autre, mais les deux méthodes sont complexes à apprendre de différentes manières si vous ne connaissez pas RxJS (Redux-observable) ou les générateurs/"effets en tant que données" (Redux-Saga).
Ils résolvent le même problème de manière extrêmement similaire, mais présentent des différences fondamentales qui ne deviennent vraiment apparentes que lorsque vous les utilisez suffisamment.
redux-observable reporte presque tout en RxJS idiomatique. Donc, si vous avez des connaissances sur RxJS (ou les avez acquises), apprendre et utiliser redux-observable est super super naturel. Cela signifie également que ces connaissances sont transférables à d’autres choses que le redux. Si vous décidez de passer à MobX, si vous décidez de passer à Angular2, si vous décidez de passer à une version ultérieure de X hotness, il y a de fortes chances que RxJS puisse vous aider. En effet, RxJS est une bibliothèque générique asynchrone et ressemble, à bien des égards, à un langage de programmation en soi - à l’ensemble du paradigme de la "programmation réactive". RxJS existe depuis 2012 et a commencé comme port de Rx.NET (il existe des "ports" dans presque toutes les langues principales, c'est cet utile).
redux-saga fournit lui-même ses opérateurs temporels. Ainsi, bien que les connaissances acquises sur les générateurs et la gestion des effets secondaires dans ce style de gestionnaire de processus soient transférables, les opérateurs et l'utilisation réels ne sont utilisés dans aucune autre bibliothèque majeure. C’est donc un peu regrettable, mais cela ne devrait certainement pas être un briseur d’accord en soi.
Il utilise également "les effets en tant que données" ( décrit ici ), ce qui peut être difficile à comprendre, mais cela signifie que votre code redux-saga n'effectue pas réellement les effets secondaires . Au lieu de cela, les fonctions d'assistance que vous utilisez créent des objets qui ressemblent à des tâches qui représentent l'intention de faire l'effet secondaire puis que la bibliothèque interne exécute à votre place. Cela rend les tests extrêmement faciles, sans besoin de se moquer et est très attrayant pour certaines personnes. Cependant, j'ai personnellement constaté que cela signifie que vos tests unitaires réimplémentent une grande partie de la logique de votre saga - rendant ces tests peu utiles, IMO (cet avis n'est pas partagé par tout le monde)
Les gens demandent souvent pourquoi nous ne faisons pas quelque chose comme ça avec redux-observable: pour moi, cela est fondamentalement incompatible avec une Rx idiomatique normale. Dans Rx, nous utilisons des opérateurs tels que .debounceTime(), qui encapsule la logique nécessaire à l'anti-rebond, mais cela signifie que si nous voulons en créer une version qui n'effectue pas réellement l'effet anti-rebond mais émet plutôt des objets de tâche avec l'intention. Nous avons maintenant perdu le pouvoir de Rx parce que vous ne pouvez plus simplement chaîner les opérateurs, car ils opéreraient sur cet objet de tâche, et non le résultat réel de l'opération. C'est vraiment difficile à expliquer avec élégance. Là encore, il faut beaucoup de compréhension de Rx pour comprendre l’incompatibilité des approches. Si vous vraiment voulez quelque chose comme ça, jetez un œil à redux-cycles qui utilise cycle.js et a pour la plupart ces objectifs. Je trouve que cela demande trop de cérémonie à mon goût, mais je vous encourage à essayer si cela vous intéresse.
Comme ThorbenA l'a mentionné, je n'hésite pas à admettre que la saga redux-saga est actuellement (10/13/16) le leader incontesté de la gestion des effets secondaires complexes pour Redux. Cela a été commencé plus tôt et a une communauté plus robuste. Il y a donc beaucoup d'attrait à utiliser la norme de facto par rapport au nouveau venu. Je pense qu'il est prudent de dire que si vous utilisez l'un ou l'autre sans connaissance préalable, vous risquez une certaine confusion. Nous utilisons tous les deux des concepts assez avancés qui, une fois obtenus, facilitent grandement la gestion complexe des effets secondaires, mais jusque-là, nombreux sont ceux qui trébuchent.
Le conseil le plus important que je puisse donner est de ne pas importer l'une de ces bibliothèques avant d'en avoir besoin. Si vous ne faites que des appels ajax simples, vous n'en avez probablement pas besoin. redux-thunk est simple à apprendre et fournit assez pour les bases - mais plus l'async est complexe, plus il devient difficile (voire impossible) pour redux-thunk. Mais pour redux-observable/saga à bien des égards, il brille le plus complexe de l’async. Il y a aussi beaucoup de mérite à utiliser redux-thunk avec l'un des autres (redux-observable/saga) dans le même projet! redux-thunk pour vos trucs simples les plus courants et utilisez uniquement redux-observable/saga pour des trucs complexes. C'est un excellent moyen de rester productif, de sorte que vous ne vous battez pas contre la saga redux-observable/pour des choses triviales avec redux-thunk.
Je pense qu'il y a des choses que vous devez prendre en considération.
- Complexité
- Style de codage
- Courbe d'apprentissage
- Testabilité
Disons que nous voulons récupérer l'utilisateur de l'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'})
)
De plus, j'ai écrit cet article afin de comparer les différences entre Redux-saga et Redux-Observable en profondeur. Départ ce lien ici ou présentation .
J'utilise Redux-Observable sur Redux-Saga parce que je préfère travailler avec des observables que sur des générateurs. Je l'utilise avec RXJS, une bibliothèque puissante pour travailler avec des flux de données. Pensez-y comme à lodash pour async. En ce qui concerne les inconvénients, les pièges et les compromis pour choisir l’un sur l’autre, jetez un oeil à cette réponse de Jay Phelps:
redux-saga en tant que projet existe depuis plus longtemps que redux-observable, ce qui en fait un argument de vente majeur. Vous trouverez plus de documentation, d’exemples et probablement une meilleure communauté pour obtenir de l’aide.
Le compteur étant que les opérateurs et les API que vous apprenez dans redux-saga ne sont pas aussi transférables que l’apprentissage de RxJS, qui est utilisé partout. redux-observable est super super super simple en interne, il vous donne simplement un moyen naturel d’utiliser RxJS. Donc, si vous connaissez RxJS (ou si vous le souhaitez), c'est un choix extrêmement naturel.
Mon conseil pour le moment pour la plupart des gens est que si vous devez demander lequel vous devez utiliser, vous devriez probablement choisir redux-saga.
J'apprécie la transférabilité entre les langues et les temps d'exécution de Rx. Même si votre application ne change pas de langue, votre carrière peut l'être. Tirez le meilleur parti possible de votre apprentissage, quelle que soit votre taille. C'est une excellente passerelle vers .NET LINQ en particulier.
Redux-Observable est une bibliothèque étonnante. Nous l'utilisons en production depuis 1,5 ans sans aucun problème jusqu'à présent, elle est parfaitement testable et peut être facilement intégrée à n'importe quel framework. Nous avons des canaux de prises parallèles extrêmement surchargés et la seule chose qui nous évite des blocages est Redux-Observable
J'ai 3 points que je voudrais mentionner ici.
1. Complexité et courbe d'apprentissage
Redux-saga bat facilement le redux-observable ici. Si vous avez juste besoin d'une simple requête pour obtenir une autorisation et que vous ne voulez pas utiliser redux-thunk pour certaines raisons, vous devriez envisager d'utiliser redux-saga, c'est plus facile à comprendre.
Si vous ne connaissez pas déjà Observable, ce sera un problème pour vous et votre équipe vous guidera :)
2. Qu'est-ce que Observable et RxJS peuvent m'offrir?
En matière de logique asynchrone, Observable est votre couteau suisse, Observable peut littéralement tout faire pour vous. Vous ne devriez jamais les comparer à des promesses ou à des générateurs, c'est beaucoup plus puissant, c'est comme comparer Optimus Prime à Chevrolet.
Et que dire de RxJS? C'est comme lodash.js mais pour la logique asynchrone, une fois entré, vous ne basculerez jamais vers quelque chose de différent.
3. Extension réactive
Il suffit de vérifier ce lien
L'extension réactive est implémentée pour tous les langages de programmation modernes, c'est simplement la clé de la programmation fonctionnelle.
Alors, passez judicieusement votre temps à apprendre RxJS et à utiliser redux-observable :)
Puisqu'il y a toute une série de discussions redux-observables ici, je pensais donner le côté saga de l'argument. Je n'utilise ni redux-observable ni RxJS, je ne peux donc pas faire de comparaison côte à côte, mais j'ai utilisé les sagas à bon escient.
Pour ce que ça vaut, j'utilise des sagas en production dans une application web.
Sagas vs Thunk
Saga gagne haut la main. Je n'ai pas aimé la façon dont thunk a mis la logique dans mes créateurs d'action. Cela a également rendu gênantes quelques requêtes consécutives. J'ai brièvement regardé redux-observable pour ce travail, mais je me suis concentré sur les Sagas.
Courbe d'apprentissage pour les Sagas
Comprendre ce que sont les générateurs et pourquoi ils sont importants est la clé pour comprendre les sagas. Mais je soulignerai que vous non devez connaître les générateurs de l'intérieur et de l'extérieur. Vous devez seulement savoir que vous passez le contrôle avec la déclaration de rendement et que la saga le rendra une fois que votre code asynchrone aura été résolu. Après cela, il n’est pas très difficile de comprendre ce qui se passe dans une saga.
Les méthodes principales de la saga sont (selon mon expérience):
call- Appelez n'importe quel bit de code et obtenez la valeur de retour. Soutient les promesses. Grande synergie entre le traitement asynchrone et les sagas.select- Appeler un sélecteur. Ce bit est plutôt brillant. Les sélecteurs sont essentiels pour redux, et ils sont supportés à 100%!put- akadispatchune action. En fait, envoyez-en autant que vous voulez!
Il existe d'autres fonctions, mais si vous maîtrisez ces trois fonctions, vous serez vraiment bien placé.
Conclusion
La raison pour laquelle j'ai choisi les sagas était la facilité d'utilisation. redux-observable ressemblait à un défi. Je suis 100% satisfait des sagas. Plus heureux que prévu.
D'après mon expérience, les sagas sont (bien) meilleures que les thunks et relativement faciles à comprendre. Rx n'est pas la tasse de thé de tout le monde. Je considérerais fortement les sagas au lieu de redux-observable si vous ne venez pas de cet écosystème et/ou ne prévoyez pas utiliser Rx dans le futur.