TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Observables, Side-Effects, and Subscriptions: Some Reactive Best Practices

79 点作者 Eyas大约 6 年前

6 条评论

vikingcaffiene大约 6 年前
At my job we went from using observables for everything to literally questioning every single one that shows up in a PR. Most of the time they don&#x27;t need to be there. Several spots in our app are nigh unusable&#x2F;untestable messes because of the side effects that get caused from subscriptions. Eg, you make a change in one place and something else totally unrelated gets updated. Obviously the implementation was totally wrong there but I tend to believe in the idea of a &quot;pit of success&quot; with framework api&#x27;s. With observables, it&#x27;s a giant foot gun if you don&#x27;t understand what you are doing and you are better off using something more stateless like a promise or just a simple javascript object reference shared via singleton service or something. If you aren&#x27;t careful about managing your &quot;source of truth&quot; you are gonna have a bad time. Then of course theres remembering to unsubscribe from them... memory leak anyone?<p>While I think they are a powerful tool, I find that a lot of developers get them confused as a drop in replacement for promises and do things like nest subscriptions etc. For most standard CRUD apps, either do as the author suggests, and use an async pipe in your template, or, convert them to promises as soon as possible.<p>What are they good for? Streams of data. Web Sockets, iframe post messages, event handlers for instance. Anything that is actually real time and makes changes without deliberate action.
评论 #19516432 未加载
评论 #19516465 未加载
评论 #19519605 未加载
评论 #19517707 未加载
评论 #19520039 未加载
dmitriid大约 6 年前
There’s one thing I find weird. There are very few, if any, resources that go beyond the simple “set up an observable, run through at most two transformations and at most two subscriptions”.<p>That’s where the vast majority of tutorials, blog posts and presentations end. And then you’re stuck with trying to implement a simple login flow, or reading data from a file, and... nothing really works, everything is overengineered and impossible to debug and trace.<p>In his book the <i>author of RxJava</i> openly admits it took him <i>several months</i> to grok reactive streams. And he was taught <i>by the author of reactive extensions for dotnet</i>.<p>Programming with reactive stuff is essentially async programming (never easy) where your data is handled, transformed in async blackboxes (hardly any implementation of Rx has a good way to observe, debug and trace data through them), and is delivered to sinks&#x2F;subscribers in async manner.<p>And yet basically everything you find on the topic will cheerfully tell you how easy this stuff is, and present you with a toy code that fits on a screen.
评论 #19517933 未加载
评论 #19520297 未加载
评论 #19517295 未加载
stupidcar大约 6 年前
It&#x27;s ironic that the author&#x27;s recommendation of using `shareReplay(1)` actually leaks a subscription as well. Unless the operator is a supplied with `{ refCount: true }` config parameter, it does <i>not</i> unsubscribe from the source observable, even when all its subscribers unsubscribe: <a href="https:&#x2F;&#x2F;github.com&#x2F;ReactiveX&#x2F;rxjs&#x2F;blob&#x2F;master&#x2F;src&#x2F;internal&#x2F;operators&#x2F;shareReplay.ts#L114" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ReactiveX&#x2F;rxjs&#x2F;blob&#x2F;master&#x2F;src&#x2F;internal&#x2F;o...</a><p>Sadly, issues like this seem to crop up all the time when using reactive programming. I&#x27;m not as anti-reactive as most other commenters here seem to be, but there&#x27;s no doubt that certain areas, particularly memory safety, sharing and buffering, seem hard to understand and get right.
评论 #19517874 未加载
polyterative大约 6 年前
After over two years heavily using RxJS in Angular for all kids of stuff (I once mapped a 100+ step-long Excel formula with success), the only advice I can give is to make a single pipe for a single purpose, using map() and friends to run data down the pipe and performing the decisive final action in the subscribe, possibily a one-line action.<p>Doing this reduces risk of side effects and help reading the code&#x2F;debugging.<p>Also you must take in account stuff like back-pressure and multicasting observables, which are as useful as hard to master and maintain correctly.<p>Really once you stop putting subscriptions in subscriptions by using the switchMap or switchMapTo operators, a lot of errors start to become clear and avoided.
cphoover大约 6 年前
When the hell did we start calling streams &quot;observables&quot;?
评论 #19516739 未加载
评论 #19516466 未加载
dmitryminkovsky大约 6 年前
I really love this implementation: <a href="https:&#x2F;&#x2F;github.com&#x2F;facebook&#x2F;relay&#x2F;blob&#x2F;master&#x2F;packages&#x2F;relay-runtime&#x2F;network&#x2F;RelayObservable.js" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;facebook&#x2F;relay&#x2F;blob&#x2F;master&#x2F;packages&#x2F;relay...</a><p>It’s one of those really nice pieces of code that’s just small enough to get your head around but at the same time totally real and useful.