1 00:00:05,240 --> 00:00:09,000 Speaker 1: Hey everyone, Welcome to Adventures and Angler, the podcast where 2 00:00:09,000 --> 00:00:12,400 we keep you updated on all things Angular related. This 3 00:00:12,480 --> 00:00:16,359 show is produced by two companies, Top and Devs and Onvoid. 4 00:00:16,800 --> 00:00:19,039 Top and Devs is very great Top and dev so 5 00:00:19,120 --> 00:00:21,920 get top and pay and recognition. We're working on interesting 6 00:00:22,000 --> 00:00:26,640 problems and making meaningful community contributions. An Onvoid which provides 7 00:00:26,679 --> 00:00:30,640 remote design and software development services on a task basis, 8 00:00:30,800 --> 00:00:34,799 so clients only pay after tests are delivered and approved. 9 00:00:36,359 --> 00:00:38,719 My name is Lucas S. Faganini. I'm your host in 10 00:00:38,799 --> 00:00:44,280 the podcast, and joining me in today's episode is Jason Akbar, 11 00:00:44,520 --> 00:00:48,119 which is a food stack software engineer mainly focus on 12 00:00:48,280 --> 00:00:52,399 front end and by the way, for the companies hearing 13 00:00:52,439 --> 00:00:56,880 this out there, Jason is currently looking for another role, 14 00:00:57,039 --> 00:01:00,719 so if you're hiring all your companies Angular all React, 15 00:01:01,399 --> 00:01:06,560 be sure to check out Jason Akbar. So, Jason, thanks 16 00:01:06,560 --> 00:01:10,680 for being at the job. Thank you for having me. 17 00:01:11,840 --> 00:01:17,000 I'm glad to be here. Awesome, Awesome, You're very welcome. So, Jason, 18 00:01:17,040 --> 00:01:20,120 the reason why you're here is because you wrote a 19 00:01:20,239 --> 00:01:23,760 few articles on Medium and one of those articles was 20 00:01:23,799 --> 00:01:28,359 about our ex JS operators and that was one that 21 00:01:28,560 --> 00:01:31,200 taught our attention and we thought it would be interesting 22 00:01:31,280 --> 00:01:34,239 to bring that knowledge to the rest of the audience. 23 00:01:34,680 --> 00:01:37,760 So maybe you could talk a little bit more about 24 00:01:38,120 --> 00:01:42,439 the article that you wrote and what was the intention 25 00:01:42,680 --> 00:01:47,959 behind it, like what we're trying to educate people about. 26 00:01:49,640 --> 00:01:52,359 Speaker 2: Okay, So before I wrote the article, I didn't know 27 00:01:52,439 --> 00:01:55,640 much about ours and then I wanted to do more 28 00:01:55,640 --> 00:02:00,239 research on it to figure out the creatures and how 29 00:02:00,239 --> 00:02:05,239 they can just make my work easier at more streamlined, 30 00:02:05,239 --> 00:02:07,000 because I realized that so many things I didn't need 31 00:02:07,000 --> 00:02:09,840 to do myself that our EXSS makes. 32 00:02:09,719 --> 00:02:10,280 Speaker 1: Easier for you. 33 00:02:10,400 --> 00:02:13,360 Speaker 2: So after I was done with my research, I just said, 34 00:02:13,439 --> 00:02:15,520 it's writes an article on it so that people would 35 00:02:15,960 --> 00:02:20,560 find the information they need on OURCS easier that I 36 00:02:20,599 --> 00:02:23,879 had to find it. So that was the intention behind rights. 37 00:02:23,680 --> 00:02:31,159 Speaker 1: In the article. Okay, okay, awesome, And by the way, 38 00:02:31,479 --> 00:02:34,840 I understand what you mean by that, because I also 39 00:02:34,960 --> 00:02:37,520 had a few challenges on my own when I was 40 00:02:38,400 --> 00:02:43,000 going through my learning journey of our Extra ASS, I 41 00:02:43,039 --> 00:02:51,199 would say it was definitely not super easy. And I 42 00:02:51,280 --> 00:02:55,120 remember that there was one website in particular, I think 43 00:02:55,120 --> 00:02:58,240 it was called Learn our Extra Ass. If I recall correctly, 44 00:02:58,280 --> 00:03:02,000 I can check, but if it was learn our XGS, 45 00:03:02,199 --> 00:03:07,680 which had some really nice diagrams for each of the operators, 46 00:03:07,719 --> 00:03:11,599 and that helped me a lot when I was learning or. 47 00:03:11,639 --> 00:03:14,240 I think it was the opposite, like the official XGS 48 00:03:14,240 --> 00:03:18,159 documentation has the diagrams, but this website had more examples. 49 00:03:18,400 --> 00:03:22,599 It's one of either, and to me, the combination of 50 00:03:22,639 --> 00:03:26,439 the official or XGS docs and this website, but always 51 00:03:26,719 --> 00:03:31,199 learn OURXGS dot ioogies check it. To me at least 52 00:03:31,479 --> 00:03:35,719 was really helpful when I was learning our xs in 53 00:03:35,800 --> 00:03:40,560 the beginning of my angular journey. So I wonder, like, 54 00:03:40,680 --> 00:03:44,120 what do you think about that and what worked for you? 55 00:03:44,199 --> 00:03:47,800 Like how did you learn our XGS to get into 56 00:03:47,800 --> 00:03:49,400 a more advanced level. 57 00:03:51,400 --> 00:03:56,840 Speaker 2: Okay, so for me, I learned urcs from various sources. 58 00:03:56,879 --> 00:03:59,680 I can't correctly remember the sources I learned it from, 59 00:03:59,719 --> 00:04:04,120 but it was very resources. Also, I just asked AI 60 00:04:04,280 --> 00:04:06,319 for some of the resources if you can give me, 61 00:04:06,360 --> 00:04:09,360 and I also check some websites and then I use 62 00:04:09,520 --> 00:04:12,879 some of the operators. So I think I went on 63 00:04:12,919 --> 00:04:15,439 the official website too, and then I found most of 64 00:04:15,479 --> 00:04:17,600 the opulators that were necessary to me. 65 00:04:17,639 --> 00:04:19,600 Speaker 1: The ones I use the most at the map, the. 66 00:04:19,519 --> 00:04:23,480 Speaker 2: Filter and all those operators, these are the ones I 67 00:04:23,560 --> 00:04:25,920 use the most, so I do. I do think I 68 00:04:25,959 --> 00:04:28,279 would also check out the website you're also talking about 69 00:04:28,399 --> 00:04:30,160 to see how that can also help me in my 70 00:04:30,240 --> 00:04:32,000 journey learn in our experience. 71 00:04:32,319 --> 00:04:36,519 Speaker 1: Now, getting back to your article in particular, it says 72 00:04:36,560 --> 00:04:43,000 the top seventeen rxgs operators. So what are the top seventeen? 73 00:04:44,600 --> 00:04:47,959 Speaker 2: Okay, So there's the map operator, the filter operator, the 74 00:04:48,040 --> 00:04:52,439 tap do operator, there's the comcat operator. There's the merger operator. 75 00:04:52,480 --> 00:04:57,160 There's the debounds time operator. There's the reduce operator. There's 76 00:04:57,199 --> 00:05:01,240 the retry operator. There's the concact MAC operator does the 77 00:05:01,319 --> 00:05:04,560 switch MAC operator. There's the partition operator. There's the combined 78 00:05:04,639 --> 00:05:07,920 leaders to operator. There's the scape operator. There's the ass I mean, 79 00:05:08,319 --> 00:05:10,759 I can go on and on. There's the take until operates, 80 00:05:10,800 --> 00:05:12,839 and then there's the catch. 81 00:05:12,720 --> 00:05:15,920 Speaker 1: Error operator and out of there is are there any 82 00:05:16,079 --> 00:05:22,680 that you would consider more unknown? Is because I guess 83 00:05:22,800 --> 00:05:32,439 that at this point, at least map filter reduced are 84 00:05:32,600 --> 00:05:37,480 ones that are very straightforward for every Angler developer. I 85 00:05:37,560 --> 00:05:39,959 don't think that there are many Angler developers that are 86 00:05:40,319 --> 00:05:45,439 unfamiliar with those. But are there any that you would 87 00:05:45,480 --> 00:05:47,879 consider to be more interesting? To talk more about. 88 00:05:49,519 --> 00:05:52,720 Speaker 2: I think like the Comcast operator as an operator that 89 00:05:54,199 --> 00:05:56,680 I'm not a lot of people use, but it can 90 00:05:56,839 --> 00:06:04,240 be helpful to just merge to two things together so 91 00:06:04,360 --> 00:06:09,759 you can conquact multiple observables sequentially emitting values together. I 92 00:06:09,839 --> 00:06:11,879 think that's an operator a lot of people don't use. 93 00:06:12,560 --> 00:06:15,560 And the de bounced time it's also an operator a 94 00:06:15,560 --> 00:06:17,680 lot of people don't use. But also who use debounced 95 00:06:17,720 --> 00:06:21,720 timers for so many things. If someone is typing something 96 00:06:21,759 --> 00:06:24,399 in an input and it's supposed to run a particular function, 97 00:06:24,800 --> 00:06:26,680 and they don't want it to run every time they 98 00:06:26,759 --> 00:06:29,120 user putting an input, they want to wait maybe some 99 00:06:29,360 --> 00:06:33,600 milli seconds before the function rants or the API rants again, 100 00:06:34,000 --> 00:06:38,319 they usually try to create the whole debounce thing themselves, 101 00:06:38,360 --> 00:06:40,800 but then there's an operator like the debounce time that 102 00:06:41,160 --> 00:06:42,560 makes that quite simple to do. 103 00:06:46,199 --> 00:06:51,959 Speaker 1: Okay, yeah, that does make sense, And can you give 104 00:06:52,000 --> 00:06:56,639 me some examples of where to use in practice? For 105 00:06:57,199 --> 00:07:00,480 like real Angular applications. 106 00:07:00,839 --> 00:07:04,680 Speaker 2: If a user is typing in something in an input, 107 00:07:04,839 --> 00:07:07,120 and then whenever the user types in something, you're supposed 108 00:07:07,160 --> 00:07:10,759 to search for results and display it on the page 109 00:07:11,040 --> 00:07:13,600 in real time as the yser types. Sometimes you wouldn't 110 00:07:13,600 --> 00:07:16,519 want the API to run every single time they user 111 00:07:16,600 --> 00:07:18,600 types in something. They could type in something and do. 112 00:07:18,639 --> 00:07:19,199 Speaker 1: Need it later. 113 00:07:19,800 --> 00:07:24,160 Speaker 2: So usually debounced timers are used to wait a little 114 00:07:24,240 --> 00:07:28,480 while till the key up till they used to wait 115 00:07:28,519 --> 00:07:30,680 a little while till the user stops typing for some 116 00:07:30,879 --> 00:07:34,959 time and then run the API. So that's that's a 117 00:07:35,040 --> 00:07:38,160 situation where the debounce time to be very helpful so 118 00:07:38,360 --> 00:07:41,480 that you could just wait a while after the user 119 00:07:41,800 --> 00:07:45,240 stops typing and then run the API instead of running 120 00:07:45,279 --> 00:07:47,720 the API every single time they use up types and 121 00:07:48,319 --> 00:07:49,199 a new letter. 122 00:07:50,240 --> 00:07:55,360 Speaker 1: Okay, yeah, that makes that is a very useful one. 123 00:07:55,519 --> 00:07:59,759 Rebound which, by the way, I don't think to currently 124 00:08:00,120 --> 00:08:04,759 have a signal based alternative for it yet, Like I'm 125 00:08:04,879 --> 00:08:08,319 seeing more and more signal based alternatives for things that 126 00:08:08,399 --> 00:08:11,759 we used to do with our actually ass popping up. Recently, 127 00:08:11,920 --> 00:08:15,000 Angle or nineteen was released and we got resource a 128 00:08:15,120 --> 00:08:19,680 GUI which allows us to deal with asynchronous our requests 129 00:08:19,920 --> 00:08:25,839 with signals. But we really don't yet have anything for 130 00:08:26,079 --> 00:08:31,399 the bounds, although there are like simple pure functions to 131 00:08:31,480 --> 00:08:34,279 handle us, like you could very easily just use modash 132 00:08:34,879 --> 00:08:37,960 and if we allow you to bounce and you could 133 00:08:38,279 --> 00:08:42,399 wrap it into a signal, but we don't yet have 134 00:08:42,759 --> 00:08:48,399 anything like baked in into a signal API, which is interesting. 135 00:08:48,559 --> 00:08:51,279 What else, what else do we still need our actually 136 00:08:51,279 --> 00:08:51,759 ass to do? 137 00:08:52,480 --> 00:08:59,120 Speaker 2: Yes, so we can also we try. There's are called 138 00:08:59,200 --> 00:09:03,279 we try. So if you are running an API that 139 00:09:03,399 --> 00:09:05,320 is supposed to run maybe when they use a load 140 00:09:05,399 --> 00:09:12,279 of page. This particular operator allows mixed use of this API, 141 00:09:12,399 --> 00:09:15,799 and then it will retry it three times and outside's 142 00:09:15,840 --> 00:09:19,360 done retrying it, then you can display a message. You 143 00:09:19,399 --> 00:09:23,840 can subscribe to that to it through a pipe and 144 00:09:23,919 --> 00:09:26,720 then display a message after it retries like three times. 145 00:09:27,440 --> 00:09:32,639 So whether retry operator if you can say you should 146 00:09:32,639 --> 00:09:35,679 retry like three times, so if the API fails the 147 00:09:35,759 --> 00:09:37,679 first time, you can retry the second time and then 148 00:09:37,720 --> 00:09:40,159 retry the third time, and then on the third try 149 00:09:40,240 --> 00:09:42,559 you could display a message to the user for they 150 00:09:42,639 --> 00:09:47,600 used to know that the API failed or it didn't work. 151 00:09:48,360 --> 00:09:53,000 Speaker 1: Right and for those for those scenarios, the operator that 152 00:09:53,200 --> 00:09:55,639 you would recommend it is just pure retry. 153 00:09:56,240 --> 00:09:59,440 Speaker 2: Yeah, you can use retry. That's that's one of the 154 00:09:59,480 --> 00:10:06,200 operators you can use to get them results. 155 00:10:08,399 --> 00:10:13,120 Speaker 1: Okay, I think that retry is an interesting one, but 156 00:10:13,240 --> 00:10:18,240 at the same time, it's not very used like it 157 00:10:18,399 --> 00:10:21,080 seems like a very nice use case, but I don't 158 00:10:21,120 --> 00:10:26,240 think people in production a lot of times do that 159 00:10:26,720 --> 00:10:31,519 like explicitly as we try cases prety logic, which they 160 00:10:31,600 --> 00:10:34,720 should it makes sense to do so, but most people 161 00:10:34,960 --> 00:10:40,080 just don't. I think it's also nature of our experience, 162 00:10:41,000 --> 00:10:46,600 which is the code observable approach, because if you look 163 00:10:46,679 --> 00:10:49,679 at the way that we use the retry operator, it's 164 00:10:49,840 --> 00:10:54,080 just so interesting that you can just have an observable 165 00:10:54,200 --> 00:10:58,840 and pipe and then pass retry and it almost seems 166 00:10:58,879 --> 00:11:06,120 like how does it retry? And because imagine that if 167 00:11:06,159 --> 00:11:08,279 you were a promise, you wouldn't be able to have 168 00:11:08,399 --> 00:11:12,480 a promise and then just do a just put that 169 00:11:12,639 --> 00:11:16,600 promise into a retry function, because the promise is just 170 00:11:17,200 --> 00:11:21,240 the execution of the thing, whereas in this case, the 171 00:11:21,399 --> 00:11:25,879 observable is almost like a formula for how you're going 172 00:11:26,000 --> 00:11:31,240 to subscribe to something. So the retry operator actually has 173 00:11:31,360 --> 00:11:35,200 all the information necessary not just to get the value 174 00:11:35,279 --> 00:11:37,879 of the current observable, but to use the observable as 175 00:11:37,919 --> 00:11:41,360 a formula and kind of like run it again if 176 00:11:41,440 --> 00:11:44,279 it fails. I don't know if I'm complicating too much. 177 00:11:44,360 --> 00:11:47,720 My explanation because it might be really tough for people that, 178 00:11:48,159 --> 00:11:51,960 especially in audio format, trying to hear me and understand 179 00:11:52,000 --> 00:11:58,720 what I mean. But perhaps my examples for that, Yes, 180 00:12:00,559 --> 00:12:01,320 yeah you could. 181 00:12:01,360 --> 00:12:04,879 Speaker 2: You could use it for an AJAX and then just 182 00:12:05,279 --> 00:12:08,279 have the API you want to run and then we 183 00:12:08,440 --> 00:12:10,559 try a few times. I get what you're saying too, 184 00:12:11,039 --> 00:12:12,559 And a lot of people don't use it. A lot 185 00:12:12,600 --> 00:12:15,799 of people don't know about it, but it's definitely something 186 00:12:16,039 --> 00:12:20,320 to look into. It's one of the unused operators that 187 00:12:20,399 --> 00:12:25,120 people just brush over and then they complicates the way 188 00:12:25,200 --> 00:12:28,799 they re try and instead of just doing something like this. 189 00:12:29,600 --> 00:12:32,440 Speaker 1: Yeah, I think in this list you also have the 190 00:12:32,559 --> 00:12:38,919 partition operator, which I find to be particularly interesting. I 191 00:12:38,960 --> 00:12:43,320 wouldn't say always useful, but it's interesting because I think 192 00:12:43,440 --> 00:12:48,440 cases where people do two fieldures like that. That's not 193 00:12:48,639 --> 00:12:51,679 specific to our actually, yes, by the way, just talking 194 00:12:51,679 --> 00:12:54,879 about a raise in general, or any kind of iterators. 195 00:12:55,440 --> 00:13:02,879 I've seen people use for one case and then filter 196 00:13:03,080 --> 00:13:05,799 for the opposite case, just to have the two arrays, 197 00:13:06,039 --> 00:13:08,559 like one filter for the condition being true and another 198 00:13:08,639 --> 00:13:11,720 filter for the condition being false. And this is just 199 00:13:12,039 --> 00:13:16,960 duplicated computation unnecessarily like you're going through the entire area 200 00:13:17,039 --> 00:13:21,720 of elements twice, whereas you could just do it once. 201 00:13:22,279 --> 00:13:26,720 But most people don't even know that there are functions 202 00:13:26,799 --> 00:13:30,360 to do that, so you don't have this natively baked 203 00:13:30,399 --> 00:13:34,759 into a ray methods. But for example, DASH exposes an 204 00:13:34,759 --> 00:13:37,600 a ray utility called partition and it's the same thing 205 00:13:37,679 --> 00:13:42,200 with RX. So partition is is almost like filter, but 206 00:13:42,320 --> 00:13:45,559 instead of giving you a single array, it gives you 207 00:13:45,679 --> 00:13:48,639 two arrays, one with all the elements that match the 208 00:13:48,720 --> 00:13:52,519 condition and another with all the elements that don't match it, 209 00:13:53,120 --> 00:13:55,320 which can be pretty. 210 00:13:55,080 --> 00:14:00,879 Speaker 2: Mudful y, it's pretty useful because there are so many 211 00:14:00,960 --> 00:14:04,679 cases where we have to filter out results from APIs 212 00:14:05,320 --> 00:14:08,519 and it reads so many filters, and sometimes it can 213 00:14:08,559 --> 00:14:10,399 be a lot of filters because they're trying to get 214 00:14:10,480 --> 00:14:14,279 so many different information and section them into different. 215 00:14:16,039 --> 00:14:16,480 Speaker 1: Values. 216 00:14:17,120 --> 00:14:18,799 Speaker 2: But then for this one, you're able to do two 217 00:14:18,879 --> 00:14:22,440 things at once and then get all the results you want. 218 00:14:26,000 --> 00:14:30,200 Speaker 1: Yeah, exactly, exactly. I see the example they have on 219 00:14:30,279 --> 00:14:33,519 the article is it's very straightforward as well, Like you 220 00:14:33,639 --> 00:14:36,559 have a list of numbers and you want to separate 221 00:14:36,639 --> 00:14:43,320 them between event numbers and odd numbers and the odd numbers. Yeah, yeah, yeah, 222 00:14:43,759 --> 00:14:49,919 that makes that makes a lot of sense. M I 223 00:14:51,039 --> 00:14:56,080 once did it just to give an interesting example for 224 00:14:56,200 --> 00:14:59,039 the audience of how you can apply it. I once 225 00:14:59,320 --> 00:15:04,039 used that in a form submission because what I wanted 226 00:15:04,120 --> 00:15:07,000 to do is I wanted to check if any of 227 00:15:07,200 --> 00:15:11,600 the object properties were different from what they were before 228 00:15:12,200 --> 00:15:14,480 at the time of submission. So imagine that like you're 229 00:15:14,600 --> 00:15:19,679 editing something, but when you're submitting the changes, then you 230 00:15:19,799 --> 00:15:22,600 want to see if there were any changes or not. 231 00:15:22,879 --> 00:15:25,960 Because if there weren't any changes, then you don't have 232 00:15:26,159 --> 00:15:30,759 to then you can just let the person leave without 233 00:15:31,240 --> 00:15:35,120 telling them that they are unsafe changes, right, And what 234 00:15:35,320 --> 00:15:40,759 I did was I used a partition function to separate 235 00:15:41,000 --> 00:15:45,360 which properties had changed from which ones hadn't, and then 236 00:15:45,559 --> 00:15:50,840 in the model of unsaved changes, I would show up like, hey, 237 00:15:50,960 --> 00:15:54,639 you have those acts properties, and I would list the 238 00:15:54,679 --> 00:15:58,519 properties that had changed and said, if you leave the 239 00:15:58,600 --> 00:16:03,480 spage now, then those changes won't be saved. Do you 240 00:16:03,559 --> 00:16:06,000 want to save them before leaving it or do you 241 00:16:06,120 --> 00:16:08,919 want to go ahead and discard the changes? But even 242 00:16:09,080 --> 00:16:14,200 if they saved, I would still have to access all properties, 243 00:16:14,279 --> 00:16:17,879 even the ones that weren't they had a change, because 244 00:16:17,919 --> 00:16:21,320 the end point was but not attached, so I had 245 00:16:21,399 --> 00:16:25,480 to give the entire object your day. So in this case, 246 00:16:26,000 --> 00:16:28,879 I did it so I wouldn't have to have to 247 00:16:30,279 --> 00:16:33,440 operations want to get just the unchanged properties and another 248 00:16:33,559 --> 00:16:35,240 to get the change ones. I would just get all 249 00:16:35,279 --> 00:16:36,960 of them, but also I would have a way to 250 00:16:38,120 --> 00:16:43,080 have some separation when it also when necessary, I would 251 00:16:43,080 --> 00:16:47,120 be able to just use all of them exactly. That's great. 252 00:16:47,159 --> 00:16:50,000 That's a great use of the partition. That's even a 253 00:16:50,240 --> 00:16:51,879 very creative will of using. 254 00:16:51,720 --> 00:16:54,840 Speaker 2: It done the sampler way people would even think about it. 255 00:16:54,960 --> 00:16:56,639 That's actually a very creative world. 256 00:16:56,559 --> 00:17:03,759 Speaker 1: Using Yeah, thanks, all right, what else, let me take 257 00:17:03,799 --> 00:17:07,680 a look here we have catch error, which it's kind 258 00:17:07,720 --> 00:17:17,119 of straightforward. I think concat map is interesting because I 259 00:17:17,200 --> 00:17:21,039 think concat and merge in general are interesting because so 260 00:17:21,200 --> 00:17:27,559 many people that concat and merge. So perhaps you could 261 00:17:27,599 --> 00:17:28,440 talk a bit about that. 262 00:17:29,079 --> 00:17:32,799 Speaker 2: Okay, So for the concact it just helps you flatten 263 00:17:33,920 --> 00:17:40,680 observable sequentially, and it's quite helpful because when they use 264 00:17:40,720 --> 00:17:46,319 a clicks on something, you could you could perform a 265 00:17:46,400 --> 00:17:50,000 concact map and then with a particular time and then 266 00:17:50,720 --> 00:17:55,359 just just combine different values based on what they've they've 267 00:17:55,400 --> 00:17:55,799 put in. 268 00:18:00,960 --> 00:18:10,559 Speaker 1: So yeah, that that is correct. Just to simplify a 269 00:18:10,680 --> 00:18:17,200 bit for the audience, Both contact and emerge allow you 270 00:18:17,400 --> 00:18:21,880 to aggregate multiple observables into this single one. The difference 271 00:18:22,599 --> 00:18:30,960 is that merge aggregates them in a parallel. So imagine 272 00:18:31,000 --> 00:18:35,279 that you're having that you have multiple observables happening at 273 00:18:35,319 --> 00:18:38,680 the same time, and when you merge them, you get 274 00:18:38,720 --> 00:18:43,599 an observable that has all the events of the observables 275 00:18:43,640 --> 00:18:46,480 that you aggregated at the moment that they have. So 276 00:18:46,640 --> 00:18:49,720 let's say that you have a timer that happens every 277 00:18:49,799 --> 00:18:53,839 one second and another that happens every half a second. 278 00:18:54,519 --> 00:18:58,799 Then you would get a new observable that meets every 279 00:18:58,880 --> 00:19:01,839 half a second, and also he meets twice every second. 280 00:19:02,880 --> 00:19:08,079 But on the other hand, m sorry, concat is different 281 00:19:08,640 --> 00:19:16,680 because comcat aggregates the observables in serial order. So it's 282 00:19:16,880 --> 00:19:21,200 not going to output the values in parallel. It's going 283 00:19:21,319 --> 00:19:25,720 to output all the values from the first observable until 284 00:19:26,119 --> 00:19:30,480 that observable complete, and then it starts to and then 285 00:19:30,519 --> 00:19:34,000 it emits the values from the second observable until it 286 00:19:34,119 --> 00:19:38,240 completes it third. So the difference is just whether you're 287 00:19:38,319 --> 00:19:44,640 aggregating things in serial order or in parallel order. 288 00:19:46,559 --> 00:19:49,480 Speaker 2: So it waits for the inobservable to finish before moving 289 00:19:49,519 --> 00:19:50,880 on to the next value. 290 00:19:52,200 --> 00:19:59,839 Speaker 1: Exactly exactly. Yeah, yeah, and that is I think most 291 00:20:00,079 --> 00:20:02,839 of it. Like the only other one that we haven't 292 00:20:02,880 --> 00:20:07,000 touched is to tap, which I also think that most 293 00:20:07,119 --> 00:20:09,960 people will be familiar with that, but for those that aren't, 294 00:20:10,000 --> 00:20:14,119 just basically like map, but you just part the result, 295 00:20:14,599 --> 00:20:19,839 so it's just for side effects like logging or basically 296 00:20:20,240 --> 00:20:22,880 doing something with the value, but not necessarily talking about 297 00:20:22,960 --> 00:20:29,160 what the function returns. Yes, so it doesn't alter the 298 00:20:29,240 --> 00:20:37,319 actual value. Mm hmm, yep, yep, okay, okay. Jason, on 299 00:20:37,599 --> 00:20:41,440 the subject or are extras? Is there anything else that 300 00:20:41,599 --> 00:20:45,599 you think would be relevant to disgust with the audience 301 00:20:45,799 --> 00:20:47,319 or should we start wrapping up? 302 00:20:49,720 --> 00:20:53,319 Speaker 2: I would just say that you that definitely more uperdes 303 00:20:53,400 --> 00:20:56,640 that I'm not in the top sevent sea that we 304 00:20:56,759 --> 00:21:00,319 could always get into and do most of the ones. 305 00:21:00,359 --> 00:21:03,839 I use that over here, and whenever there's something that 306 00:21:03,960 --> 00:21:07,119 you feel is complicated, you could just search for rings 307 00:21:07,599 --> 00:21:09,880 or do that or any of these tools to help 308 00:21:09,920 --> 00:21:13,880 you out simplify certain things that would usually be complicated 309 00:21:14,000 --> 00:21:17,440 to do. And I think that's that's it. 310 00:21:20,400 --> 00:21:26,920 Speaker 1: Okay, all right, all right, Jason, let's do some quick promos. 311 00:21:27,880 --> 00:21:29,960 So on my end, I'm just going to promote the 312 00:21:30,000 --> 00:21:32,799 two companies that produce this show. So if you are 313 00:21:32,920 --> 00:21:35,839 listening to this and you're interested in learning other technologies 314 00:21:35,960 --> 00:21:38,640 not just Angular, then Top and Dobs has many other 315 00:21:38,759 --> 00:21:41,839 shows as well. There's a show about React called React 316 00:21:41,920 --> 00:21:46,039 round Up and it shows about continuous integration, container's appointment 317 00:21:46,480 --> 00:21:49,119 JavaScript in general. There will there are a lot of podcasts, 318 00:21:49,160 --> 00:21:51,640 so you check out Top and Down if you're interested 319 00:21:51,680 --> 00:21:55,839 in that. And if you are a business owner or 320 00:21:55,960 --> 00:21:58,799 if you are at a company that is currently looking 321 00:21:58,920 --> 00:22:04,119 for remote developers, I would definitely recommend checking out on 322 00:22:04,319 --> 00:22:07,720 boyd dot com. So this is a new vitalide dot 323 00:22:07,839 --> 00:22:13,880 com because they have a very many proposition which basically 324 00:22:14,240 --> 00:22:17,200 allows you to hire them and only pay for the 325 00:22:17,400 --> 00:22:20,920 tasks that they deliver, which is a lot more client 326 00:22:21,000 --> 00:22:25,400 friendly than paying by the hour or hiring a full 327 00:22:25,440 --> 00:22:29,720 time employee and then paying a monthly value. So it's 328 00:22:29,960 --> 00:22:33,440 it's very different, but definitely check out if you're interested 329 00:22:33,480 --> 00:22:36,640 in that. That's you and Void dot com. So how 330 00:22:36,680 --> 00:22:38,680 about you, Jason, what would you like to promote. 331 00:22:40,160 --> 00:22:43,720 Speaker 2: Okay, I'd just like to promote myself as a software engineer, 332 00:22:43,839 --> 00:22:48,039 full stat front and back and move out. If you 333 00:22:48,640 --> 00:22:51,480 have any projects, if you want to be mentoring, if 334 00:22:52,039 --> 00:22:54,319 you also want to mentor have anything. 335 00:22:54,039 --> 00:22:56,960 Speaker 1: You would would like you to contribute to work on. 336 00:22:57,200 --> 00:23:00,119 Speaker 2: If you'd like to work with me, I'm available. You 337 00:23:00,160 --> 00:23:03,960 can check out my LinkedIn It's Jason Akaba and I'll 338 00:23:04,000 --> 00:23:06,559 be happy to connect with anybody that listens and it's 339 00:23:06,640 --> 00:23:08,200 interested in having a conversation. 340 00:23:11,559 --> 00:23:16,359 Speaker 1: Awesome, Okay, okay, Jason, thank you so much for being 341 00:23:16,440 --> 00:23:18,680 on the show. It's a pleasure to have you, dude, 342 00:23:19,799 --> 00:23:22,759 it was a pleasure to be on this Yeah, thank you, 343 00:23:22,920 --> 00:23:26,680 thank you. Good luck on looking for your next opportunity. 344 00:23:27,200 --> 00:23:29,279 I hope it doesn't take so long. The market is 345 00:23:29,839 --> 00:23:36,000 a bit crazy at the moment. But thank you so much, 346 00:23:36,119 --> 00:23:36,680 thank you so much. 347 00:23:36,720 --> 00:23:39,079 Speaker 2: Good luck to you too, and it was so so 348 00:23:39,279 --> 00:23:40,119 much fun being. 349 00:23:40,039 --> 00:23:43,799 Speaker 1: On this podcast. Awesome, thanks you. I have a great day, 350 00:23:45,119 --> 00:23:45,480 you too.