Utilisation d'extensions réactives, je peux penser à plusieurs façons de modéliser une opération ayant des effets secondaires / io - disons souscrire aux messages d'une salle de discussion. Je pourrais soit accepter des paramètres (disons la salle de discussion), et un observateur, renvoyer une jetable, c'est-à-dire ou renvoyer une observable donnée aux paramètres, à savoir Lorsque vous retournez un observable, je dispose également du choix entre le rendant "chaud" ou "froid", c'est-à-dire exécuter l'abonnement réel soit lorsque ma méthode est appelée ou lorsque l'observable est souscrite. De plus, je pourrais rendre l'observable multiplexé ou non, c'est-à-dire partager le même abonnement sous-jacent lorsqu'il y a plus d'un abonné à l'observable ou initier une nouvelle demande à chaque fois que cela est souscrit. est là. Une approche des meilleures pratiques en matière d'utilisation de RX pour des opérations qui souscrivent à une source externe d'événements avec des paramètres?
3 Réponses :
Renvoyer un * i * Observable est beaucoup mieux, car vous êtes alors capable de composer le renvoi iobservable avec d'autres opérateurs. Essayer de mettre des choses dans une méthode de souscription personnalisée semble être une mauvaise idée pour moi, car il n'y a rien de composé de souscrits, vous êtes donc une sorte de peindre dans un coin. Si vous retournez iobservable, vous pouvez décider plus tard si vous souhaitez publier / différer, etc ..., quand vous voulez, simplement en utilisant les opérateurs existants pour IO. Si vous le faites à l'intérieur de l'abonné, il est décidé et tout doit participer aux conséquences. Le comportement serait enveloppé dans les souscrits, qui défait le but de l'IO ... d'être explicite sur les effets secondaires.
Étant explicite des effets secondaires, c'est la raison pour laquelle j'utiliserais le formulaire «abonnez-vous à» explicite. Vous savez comme un appelant qui invoquant cette fonction fera lieu, et une fois pour chaque appel, il ressort du contrat que cela doit être le cas.
iobservable code> a une méthode appelée inscrivez-vous avec une tonne de surcharges. Il n'y a aucune raison pour vous d'écrire une méthode subscride personnalisée. C'est un modèle anti-modèle. var o = ChatRoom.ObservableFor("alt.buddha.short.fat.guy").Publish().RefCount()
D'autre part, il est très facile de faire un observable de quelque chose d'accepter un observateur et de renvoyer une jetable, et cela rendrait plus évident où l'effet secondaire s'est produit ...
Vous avez mal interprété trop de blogs de programmeurs fonctionnels fondamentalistes si vous parlez de «effets secondaires» et de suggérer que la manière standard de la création de pipelines de construction est fausse.
BTW Regardez la méthode Observable.create.
Être totalement clair. Tout ce qui a une méthode doit être un iobservable. Comprenez cela et votre problème disparaît.
Je suis d'accord avec les deux autres réponses. J'aimerais ajouter des éclaircissements supplémentaires:
où / Sélectionnez / Prendre etc ... les opérateurs. Pour ce faire, crée une expérience de jarring et conduit à des résultats imprévisibles. Cela empêche une composition sûre, qui est une pierre d'angle de FP.
- est totalement bien pour passer des paramètres à une méthode qui renvoie une séquence observable! Votre échantillon est un excellent exemple de quand le faire. D'autres exemples incluent l'abonnement à une chaîne, à un point final, de session, de la minuterie, etc.
- Évitez l'utilisation des implémentations personnalisées de
iobservable . C'est juste un non-non. J'utilise Rx depuis plus de 3 ans maintenant et il n'y a pas besoin de le besoin. Même en utilisant les implémentations sur le sujet est un événement rare. Comme dit Brad, regardez à Observable.create pour créer séquences. *
résumer, je vous suggère de vous retrouver avec une interface qui ressemble à ceci: xxx RE Votre question de partage de séquences observables, est vraiment beaucoup Quelque chose que vous devez décider en fonction de vos propres besoins et d'architecture. Parfois, vous constaterez peut-être que les couches de transport sous-jacentes le feront pour vous, donc il n'est donc pas nécessaire de vous le coder. D'autres fois, vous constaterez que le partage d'un abonnement signifie que les Seconds + abonnés peuvent manquer de messages qui ne se produisent que sur l'abonnement (par exemple. État du monde). Vous pourriez finir par faire cela en utilisant un replaySubject comme votre multidiffeur. Cela soulève d'autres problèmes; Êtes-vous prêt à prendre un coût éventuellement sans bornes de stockage de chatmessages?
* Divulgation: Le lien est à mon propre site Web