-
-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add Stream.share api #3080
add Stream.share api #3080
Conversation
🦋 Changeset detectedLatest commit: c14e39f The changes in this PR will be included in the next version bump. This PR includes changesets to release 31 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
b49da35
to
b93b4d5
Compare
b505f14
to
b54c80e
Compare
I think a better primitive is a kind of It could also be used for other applications. |
b93b4d5
to
6589289
Compare
b54c80e
to
52e1e80
Compare
As i said, this PR is WIP. It should have options like interface Options {
readonly connector: Effect.Effect<
PubSub.PubSub<Take.Take<A, E>> | Queue.Queue<Take.Take<A, E>>
>;
readonly resetOnRefCountZero?: boolean;
readonly resetOnError?: boolean;
readonly resetOnComplete?: boolean;
} Let's say we have Stream.share({
connector: PubSub.replay(1),
resetOnRefCountZero: false;
}) That means if there was 2 consumers, then they both unsubscribed (0 consumers at now), then 1 consumer subscribed – it will receive the last value from stream. As i understand, it is impossible to achieve with |
@tim-smart could you maybe provide an example of code of how to use hypothetical |
6589289
to
0ce7594
Compare
52e1e80
to
0bc1b3c
Compare
0ce7594
to
4ea9615
Compare
0bc1b3c
to
4a4b15d
Compare
4ea9615
to
49e5bef
Compare
4a4b15d
to
6883cc2
Compare
49e5bef
to
ae16809
Compare
6883cc2
to
d3746cc
Compare
ae16809
to
557cb53
Compare
26d52b5
to
abff7f3
Compare
3b82e6d
to
6bf7a9a
Compare
abff7f3
to
dc4f5ee
Compare
6bf7a9a
to
4e0a58d
Compare
dc4f5ee
to
50017d0
Compare
4e0a58d
to
f3d8317
Compare
50017d0
to
313e041
Compare
f3d8317
to
53cb05b
Compare
313e041
to
77e95fc
Compare
68dc7ef
to
f9800cb
Compare
Co-authored-by: Tim <hello@timsmart.co>
Co-authored-by: Tim <hello@timsmart.co>
Co-authored-by: Tim <hello@timsmart.co>
Co-authored-by: Tim <hello@timsmart.co>
Co-authored-by: Tim <hello@timsmart.co>
Co-authored-by: Tim <hello@timsmart.co>
Co-authored-by: Tim <hello@timsmart.co>
Co-authored-by: Tim <hello@timsmart.co>
Co-authored-by: Tim <hello@timsmart.co>
Co-authored-by: Tim <hello@timsmart.co>
Co-authored-by: Tim <hello@timsmart.co>
Co-authored-by: Tim <hello@timsmart.co>
Co-authored-by: Tim <hello@timsmart.co>
Co-authored-by: Tim <hello@timsmart.co>
Co-authored-by: Tim <hello@timsmart.co>
Co-authored-by: Tim <hello@timsmart.co>
Co-authored-by: Tim <hello@timsmart.co>
Co-authored-by: Tim <hello@timsmart.co>
Type
Description
Stream.share({ connector: PubSub.unbounded() })
returns a new Stream that multicasts (shares) the originalStream
by forkingrunIntoPubSub
process inforkScoped
mode. As long as there is at least one consumer, thisStream
will be run and emitting data. When all consumers have exited, it will kill forked daemon.I understand that this PR is kinda incomplete, i just need to know if you are interested in this operator at all, so i could finish.
Please, let me know.
Related
I have not filled an issue on GitHub, but i posted a question in Discord, i will repeat it here
I have a WebSocket connection to a remote server. To subscribe to a topic, I send a
subscribe@someTopic
message, and to unsubscribe, I send anunsubscribe@someTopic
message. Each topic is represented as a broadcasted Stream.The challenge is that if two different parts of my code subscribe to the same topic, they should use the same WS connection, but should be able to work independently at the same time. This is difficult to achieve with the classic
Scope
finalization model because if one of the two consumers closes the scope, it will send theunsubscribe@someTopic
signal to the server, causing the second consumer to stop receiving events without notice.Using a global scope is not a viable solution because I need to ensure the WebSocket connection remains clean and unsubscribe from the topic when there are no active consumers.
The share operator addresses this issue by allowing multiple independent consumers to subscribe to the same topic without interfering with each other. This ensures that each consumer can independently manage its subscription and receive events without being affected by other consumers.
And, actually, there are much more scenarios when such
share
is invaluable.