Exercise 8 Solution Part 2

[00:00:00]
>> [MUSIC]

[00:00:04]
>> Kyle: Yes.
>> Speaker 2: I don't feel like that this is the correct behavior though. Cuz when you when click on a button, you would think it would happen right away. And then as you're clicking it would debounce a whole nother second.
>> Kyle: Debouncing is different than sampling. So we could have done an exercise for debouncing.

[00:00:23]
>> Speaker 2: Cuz this is like, no, I understand this follows the pattern in the exercise. But I'm just saying in this scenario, you have every second, it's dumping whatever it sees.
>> Kyle: Yes.
>> Speaker 2: Right?
>> Kyle: Yes.
>> Speaker 2: I mean kind of a clock, right?
>> Kyle: Yes.
>> Speaker 2: But I would expect that when you click it just operates right away.

[00:00:45]
And then it sort of-
>> Kyle: Yeah. So what you're really asking about has absolutely nothing to do with the programming. That's a user experience question.
>> Speaker 2: Yeah.
>> Kyle: If you wanted the user experience of debouncing, you would solve this a different way. I set it up because sampling is easier to understand than debouncing.

[00:01:04]
>> Speaker 2: Yeah, yeah, sure.
>> Kyle: So I set it up that the exercise is for you to learn about sampling.
>> Speaker 2: I'm just wondering how that would fit into the-
>> Kyle: Where does sampling fit in? Is that what you're asking?
>> Speaker 2: Yeah, just how you would do it like that where you're debouncing with the variables rather than, or maybe it's [CROSSTALK]

[00:01:25]
>> Kyle: It's hard to answer user experience questions in the context of software development. But there are use cases for sampling and there are use cases for event debouncing. And we would have solved this differently if our use case was asking for the debouncing.
>> Speaker 2: Sure.
>> Kyle: And RxJS, by the way, does provide a debouncing [CROSSTALK]

[00:01:44]
>> Speaker 2: I just haven't quite wrapped my head around building UIs this way.
>> Kyle: That have sampling?
>> Speaker 2: Yeah.
>> Kyle: Okay.
>> Speaker 2: With stream, so I've never actually built a whole Reactive interface.
>> Kyle: Yeah, well basically, just as with any software development, you're going to have a set of user experience requirements and UI requirements handed to you.

[00:02:03]
And as a developer you're gonna have to say, what they're asking for is debouncing. So let me go find the appropriate way to model debouncing. Or, over here they're asking for sampling, let me go solve this with a sampling thing. So this exercise was purely about solving sampling as the operation that we look for.

[00:02:21]
And sampling is a valid thing that you do in interfaces. Debouncing is also a valid thing that you do. Does that makes sense? Okay.
>> Speaker 3: Couldn't you just switch instead of having that latest variable set on click, you would have it set on it's set interval, r1ight? So that it's the second that is getting flagged.

[00:02:46]
And then every time you have the click happen, you look to see, do we have a second flag set? Then put it out right away. It would just be the event in the different order for the flag being set.
>> Kyle: I'm not gonna argue with you. I'm not entirely certain I agree, but I'm not gonna argue with you.

[00:03:07]
It might mean [INAUDIBLE]
>> Speaker 3: You could switch this logic around to.
>> Kyle: Okay, sure.
>> Speaker 3: You could get it working.
>> Kyle: Okay, sure. Maybe you should do that as a bonus. Try to rework this as debouncing instead of sampling.
>> Speaker 4: Well, I'm going to have to cuz one of the next interfaces I'm building-

[00:03:23]
>> Kyle: Is going to be that, yeah.
>> Speaker 4: Yeah.
>> Kyle: Okay. All right, good questions, though. Any other questions about exercise eight?
>> Kyle: This is nowhere near a comprehensive, two-day, deep dive into all of Reactive programming. There's a whole other workshop for that. But what I wanted to get you to the point of is understanding where it fits within the bigger scope of what we do in our programs.

[00:03:50]
Observables are about adapting your event streams and modeling your data flow in a declarative fashion. That's what observables are all about. So in the parts of your application that need that, don't reach for a generator, don't reach for a promise, don't reach for a thunk, don't reach for a callback, reach for an observable.

[00:04:09]
Right, so these are all different tools that fit in together to an application I said this at the beginning of the workshop. I've never once built an application that used exactly the same abstraction across everything. There's the right tool for the right job so this is just one more tool in your tool belt.

[00:04:28]
>> Kyle: Did you have a question? Okay.
>> Speaker 4: [INAUDIBLE]
>> Kyle: No problem. Okay, great. I want to point out one other thing. There were a couple questions about the difference between using this and using RxJS. I'm not disparaging RxJS in any way shape or form. I'm simply saying it's too much for me to have ever tried to bite off.

[00:04:50]
And eventually, I was like I need something simpler. So that's why it ended up landing in asynquence that way. I needed something that was easier to teach. And if I had to teach you three or four different frameworks, you'd be even more overwhelmed than you are already are.

[00:05:04]
So, I'm trying to keep it as simple as possible. But that's not to say in any way, shape, or form that RxJS is bad, it's a great library. In addition to that, I would say you don't have to choose between the two,. Because there is a to observable and a from observable provided with my library.

[00:05:23]
So if you have RxJS observables that you're getting from some framework. And you want to use them in asynquence, you can import them in and make a reactive sequence, or the other way around. If you have a reactive sequence and you want to make a real observable out of it for some reason, you can do that as well.

[00:05:38]
So you don't have to choose, and the same is true of promises. There's a to promise and a promise method to bring promises into React. So there's no real reason why you have to draw some dividing line and say well, it's either asynquence or not. You can mix asynquence in with any other mixed environment and should be able to go back and forth transparently.