Sharing Streams with Share

John Lindquist
InstructorJohn Lindquist

Share this video with your friends

Send Tweet
Published 6 years ago
Updated 3 years ago

A stream will run with each new subscription added to it. This lesson shows the benefits of using share so that the same stream can be shared across multiple subscriptions.

[00:00] another side effect to consider is that after I type right now, I have to hit delete after every time to update that. When I start and I type one, delete, two, delete, three to try and get my final score. We can add a side effect to clear out our input every time it checks to see if we get a match.

[00:18] This is the point that it checks to see if we get a match right before the filter. I'll go ahead and break that into a stream. We'll call it something like running game. Then, we'll have our running game.

[00:30] This is the exact same. We haven't changed anything. We just gave that part of the stream a name. Then, we'll also subscribe here so that once it checks, it gets that with latest from and hits the tick, we can grab the input and set the value to an empty string. I'll hit save.

[00:50] You'll notice right away that we get two logs of that initial starting object. If we hit start, each time it'll log out two of that same thing. It was deleting that for me here, setting the value to an empty string, but it did everything twice.

[01:08] To be able to share this stream amongst these two other subscriptions, it's not subscribing twice like it is now...that's the expected behavior, because we call subscribe twice. But if we want to share so that it gets the same stream running, we'll say .share and just use the share operator.

[01:28] Now, when I hit start, you'll see that nothing is duplicated. It didn't start with anything duplicated. It's just using that same stream. But the problem now is if I start again, I hit type one. It doesn't clear it out, but it's still running just fine. That's because while we shared this stream, we're only repeating on this stream.

[01:50] In this scenario, we need to make sure that we also repeat a stream that's going to clear out my input value so that when I restart, it starts with the count of zero. I'll hit start, one, two, three. Get a score of three. Then when I start again, it'll still apply that side effect of deleting the input.

[02:16] Then finally to wrap this up, you'll see that when I click start, the score doesn't reset to zero. When I click start, at that moment I want the score to reset, and I also want the input field to clear and probably even grab focus. I'll go ahead and look for our starter stream which is up here. This is all the button clicks that we can subscribe to. We'll go ahead and share him.

[02:38] Now from my starters, I can add some more side effects just by subscribing to it. I want the side effect of input.focus. I want the side effect of the query selector of the score.

[02:57] Let's grab this whole thing, paste it in there. We'll just say the inner HTML is an empty string. I also want this initial side effect of input value is nothing. I noticed I missed an S in starters, then, I'll fix that.

[03:17] Now at this point, once I hit start, I can go one, two, three. Got a score of three. Then when I hit start again. It'll focus. I can type one, two, three. Got another score of three. This game gets easier because it clears it out for me.

[03:35] I'll try it at twice speed. It'll focus one, two, three. Still got a score of three. Then the super fast speed which will be much, much harder, one. two, three, score of one. One, two, three, score zero. One, two, three, one, one, two, three, one, two, three. There it is, score of three. I win first try...

Chris
Chris
~ 5 years ago

Can we use do() instead of subscribe() to clear the text to simplify things?

Vincent De Snerck
Vincent De Snerck
~ 5 years ago

'Do' definitely seems like a better solution for the problem. Double subscribe also seems to go against what was said in an earlier video where the entire working of the stream should be defined at declaration.

However it is an example of how and why you could share a stream.

Jordan Frankfurt
Jordan Frankfurt
~ 5 years ago

first try

ganqqwerty
ganqqwerty
~ 4 years ago

great course, thanks so much!

J. Matthew
J. Matthew
~ 2 years ago

'Do' definitely seems like a better solution for the problem. Double subscribe also seems to go against what was said in an earlier video where the entire working of the stream should be defined at declaration.

I think you're referring to this video: https://egghead.io/lessons/rxjs-reactive-programming-why-choose-rxjs

However, I think the sense of it is a bit different than your interpretation. If I'm understanding it right, that video argues that the behavior of the dynamic values of the stream itself should be defined at declaration.

The author gives the example of a stream that just emits the value "3," and then incorrectly modifying it later to also emit 4. Or setting one value based on another value, but doing so in two different places. This is what one shouldn't do.

In the video on this page, on the other hand, subscribing to the stream in more than one location doesn't violate this principle, because the additional subscribe doesn't further modify the stream itself. Like the author says, it's a side-effect, just triggering another effect on the DOM whenever the stream emits.

It's true that input.value is modified in two places (though set to an empty string each time), and maybe that would still be frowned upon; I'm still wrapping my head around that side of things. But the input stream is emitting the input event, which isn't triggered by setting the input's value programmatically. So the stream isn't being affected. At least, I don't think so.

It's a good question about whether do() would work and be more appropriate. Consider though that the share() operator wouldn't be made available if there weren't valid uses for more than one subscribe().