订阅对象的突变价值，而无需转换为可观察的对象
我想将这两种解决方案与RXJ一起使用，但我不知道该怎么做。
将每个数据可观察到的数据输送发出并具有像主题的能力：
// Sample code, this does not work properly :(, because next is not defined on Observable
const dummy = new Subject<number>().pipe(
map((num) => num + 1)
);
dummy.subscribe((number) => {
// expects 4 but get 3
})
dummy.next(3)
我想在可观察到的构造之外散发数据并使用可观察的的管道方法对每个数据进行操作。
我可以实现一个简单的发射极类，以模拟这种行为，但我想要一种RXJS。
I want to use these two solutions together with RxJS but I don't know how to do it.
pipe each data that Observable emits and have ability to act like a Subject:
// Sample code, this does not work properly :(, because next is not defined on Observable
const dummy = new Subject<number>().pipe(
map((num) => num + 1)
);
dummy.subscribe((number) => {
// expects 4 but get 3
})
dummy.next(3)
I want to emit data everywhere even outside of observable construction like Subscribe, and operate on each data emit using pipe method like Observable.
I can implement an simple emitter class that simulate this behavior but I want a RxJS way.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这是RXJS不存在的抽象。
您可以通过定义主题的Kleisi组成来自己构建它。基本上是为受试者做什么管的可观察力。
受试者是可观察到的观察者，因此您可以通过仅跟踪源主题来构建已经存在的操作员的抽象Ontop。
那为什么不存在呢？很大程度上是因为目前尚不清楚为什么它甚至有用。操作员以可观察到的而不是观察者进行操作。
受试者对于多播（使冷热热）和声明性和命令式代码之间的接口/桥接非常有用。
从历史上看，试图整合（而不是界面）声明性和命令性API设计的尝试是不必要的复杂性。
您需要访问一个主题和一些数据的奇怪时间，并且迫切需要将两者推入对象或元组并以这种方式传递给它们，这可能更清晰。用新型的构图扩展主题并不会抽象或具体地增加太大的好处。
This is an abstraction that doesn't exist with RxJS.
You can build it yourself by defining kleisi composition for subjects. Basically do for subjects what pipe does for observables.
Subjects are observables and observers, so you can build the abstraction ontop of the operators that already exist by just tracking the source subject.
So why doesn't this already exist? Largly because it's not clear why it's even usefull. The operators operate on observables and not on observers.
Subjects are useful for multicasting (make a cold observable hot) and for interfacing/bridging between declarative and imperative code.
Historically attempts to integrate (instead of just interface) declarative and imperative api design has be frought with needless complexity.
The odd time that you need access to a subject and some steam of data together imperatively, it's probably clearer api to shove the two into an object or tuple and pass them atound that way. Extending the subject with a new type of composition just doesn't add much benefit, abstractly or concretely.