Discussion: ValueObservable / BehaviorObservable #5975
Replies: 4 comments 4 replies
-
I actually have a related question: when designing APIs that use observables, I use a rule of a thumb that where possible, an observable should represent a changing value rather than a stream of events. If anyone uses the same principle or knows of any articles on this subject, give a shout! |
Beta Was this translation helpful? Give feedback.
-
given a hot observable you can just do this: // setup
const subject = new BehaviorSubject(undefined);
a$.subscribe(subject);
// use later
const value = subject.getValue(); |
Beta Was this translation helpful? Give feedback.
-
The original request is to have a readonly (Observable only) interface with |
Beta Was this translation helpful? Give feedback.
-
I came here to make this request. I'm glad to see other people making similar requests although I'm disappointed this hasn't moved forward. Here's my naive attempt at implementing this - |
Beta Was this translation helpful? Give feedback.
-
Feature Request: ValueObservable / BehaviorObservable
Is your feature request related to a problem? Please describe.
RxJS works really great in the asynchronous world. However, there is plenty of times where a synchronous stream is required.
The main example is when building a web app where components must render synchronously some observable's value. A lot of times I use BehaviorSubject to do that but then I expose the mutable method "next" to the outer world.
I would like to expose only a type of "Observable + Synchronous value".
Describe the solution you'd like
I would like a subclass of Observable, named like "ValueObservable" or "BehaviorObservable" which is a specialized Observable which has access to it's current value. Something along:
Then, BehaviorSubject would be of type
class BehaviorSubject<T> extends Subject<T> implements ValueObservable<T>
Thanks to this addition we would be able to differentiate stream which already provides a value and stream who are truly asynchronous and need special care for fallback value.
In a todo app,
todos$
would be of typeValueObservable<Todo[]>
because there is always some todos available to render whilefetchTodoFromApi$()
would still be of typeObservable<Todo[]>
because we do not have any data before the request is done.Describe alternatives you've considered
I already implements this idea in the user-land package r-value-observable. But I think it would be better to have it in the core package.
Additional context
This idea comes from RxDart which already implements this and can be used in Flutter to render synchronous value in components.
PS: It would be a pleasure for me to develop it and offer a PR to this package!
Beta Was this translation helpful? Give feedback.
All reactions