December 19, 2024 • 23 mins
In today's episode, Lucas is joined by Jason Akbar, a full-stack software engineer who’s got a knack for front-end development. He recently penned some intriguing articles on Medium about RxJS operators. He will reveal what motivated him to write about RxJS operators, especially focusing on the top 17 operators that every Angular developer should know. They will break down each of these operators—like the map, filter, and debounce time—and discuss how they can streamline your Angular development. Jason will also touch on some of the lesser-known but incredibly useful operators like concat and merge, providing real-world examples of where these can come in handy.
Whether you’re navigating your way through Angular or looking to refine your skills, this episode is packed with nuggets of wisdom that you won't want to miss. Jason also has some tips on where you can find additional resources to master RxJS.
Links
Socials
Become a supporter of this podcast: https://www.spreaker.com/podcast/adventures-in-angular--6102018/support.
Whether you’re navigating your way through Angular or looking to refine your skills, this episode is packed with nuggets of wisdom that you won't want to miss. Jason also has some tips on where you can find additional resources to master RxJS.
Links
Socials
Become a supporter of this podcast: https://www.spreaker.com/podcast/adventures-in-angular--6102018/support.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:05):
Hey everyone, Welcome to Adventures and Angler, the podcast where
we keep you updated on all things Angular related. This
show is produced by two companies, Top and Devs and Onvoid.
Top and Devs is very great Top and dev so
get top and pay and recognition. We're working on interesting
problems and making meaningful community contributions. An Onvoid which provides
(00:26):
remote design and software development services on a task basis,
so clients only pay after tests are delivered and approved.
My name is Lucas S. Faganini. I'm your host in
the podcast, and joining me in today's episode is Jason Akbar,
which is a food stack software engineer mainly focus on
(00:48):
front end and by the way, for the companies hearing
this out there, Jason is currently looking for another role,
so if you're hiring all your companies Angular all React,
be sure to check out Jason Akbar. So, Jason, thanks
for being at the job. Thank you for having me.
(01:11):
I'm glad to be here. Awesome, Awesome, You're very welcome. So, Jason,
the reason why you're here is because you wrote a
few articles on Medium and one of those articles was
about our ex JS operators and that was one that
taught our attention and we thought it would be interesting
to bring that knowledge to the rest of the audience.
(01:34):
So maybe you could talk a little bit more about
the article that you wrote and what was the intention
behind it, like what we're trying to educate people about.
Speaker 2 (01:49):
Okay, So before I wrote the article, I didn't know
much about ours and then I wanted to do more
research on it to figure out the creatures and how
they can just make my work easier at more streamlined,
because I realized that so many things I didn't need
to do myself that our EXSS makes.
Speaker 1 (02:09):
Easier for you.
Speaker 2 (02:10):
So after I was done with my research, I just said,
it's writes an article on it so that people would
find the information they need on OURCS easier that I
had to find it. So that was the intention behind rights.
Speaker 1 (02:23):
In the article. Okay, okay, awesome, And by the way,
I understand what you mean by that, because I also
had a few challenges on my own when I was
going through my learning journey of our Extra ASS, I
would say it was definitely not super easy. And I
(02:51):
remember that there was one website in particular, I think
it was called Learn our Extra Ass. If I recall correctly,
I can check, but if it was learn our XGS,
which had some really nice diagrams for each of the operators,
and that helped me a lot when I was learning or.
(03:11):
I think it was the opposite, like the official XGS
documentation has the diagrams, but this website had more examples.
It's one of either, and to me, the combination of
the official or XGS docs and this website, but always
learn OURXGS dot ioogies check it. To me at least
was really helpful when I was learning our xs in
(03:35):
the beginning of my angular journey. So I wonder, like,
what do you think about that and what worked for you?
Like how did you learn our XGS to get into
a more advanced level.
Speaker 2 (03:51):
Okay, so for me, I learned urcs from various sources.
I can't correctly remember the sources I learned it from,
but it was very resources. Also, I just asked AI
for some of the resources if you can give me,
and I also check some websites and then I use
some of the operators. So I think I went on
(04:12):
the official website too, and then I found most of
the opulators that were necessary to me.
Speaker 1 (04:17):
The ones I use the most at the map, the.
Speaker 2 (04:19):
Filter and all those operators, these are the ones I
use the most, so I do. I do think I
would also check out the website you're also talking about
to see how that can also help me in my
journey learn in our experience.
Speaker 1 (04:32):
Now, getting back to your article in particular, it says
the top seventeen rxgs operators. So what are the top seventeen?
Speaker 2 (04:44):
Okay, So there's the map operator, the filter operator, the
tap do operator, there's the comcat operator. There's the merger operator.
There's the debounds time operator. There's the reduce operator. There's
the retry operator. There's the concact MAC operator does the
switch MAC operator. There's the partition operator. There's the combined
(05:04):
leaders to operator. There's the scape operator. There's the ass I mean,
I can go on and on. There's the take until operates,
and then there's the catch.
Speaker 1 (05:12):
Error operator and out of there is are there any
that you would consider more unknown? Is because I guess
that at this point, at least map filter reduced are
ones that are very straightforward for every Angler developer. I
(05:37):
don't think that there are many Angler developers that are
unfamiliar with those. But are there any that you would
consider to be more interesting? To talk more about.
Speaker 2 (05:49):
I think like the Comcast operator as an operator that
I'm not a lot of people use, but it can
be helpful to just merge to two things together so
you can conquact multiple observables sequentially emitting values together. I
(06:09):
think that's an operator a lot of people don't use.
And the de bounced time it's also an operator a
lot of people don't use. But also who use debounced
timers for so many things. If someone is typing something
in an input and it's supposed to run a particular function,
and they don't want it to run every time they
user putting an input, they want to wait maybe some
milli seconds before the function rants or the API rants again,
(06:34):
they usually try to create the whole debounce thing themselves,
but then there's an operator like the debounce time that
makes that quite simple to do.
Speaker 1 (06:46):
Okay, yeah, that does make sense, And can you give
me some examples of where to use in practice? For
like real Angular applications.
Speaker 2 (07:00):
If a user is typing in something in an input,
and then whenever the user types in something, you're supposed
to search for results and display it on the page
in real time as the yser types. Sometimes you wouldn't
want the API to run every single time they user
types in something. They could type in something and do.
Speaker 1 (07:18):
Need it later.
Speaker 2 (07:19):
So usually debounced timers are used to wait a little
while till the key up till they used to wait
a little while till the user stops typing for some
time and then run the API. So that's that's a
situation where the debounce time to be very helpful so
that you could just wait a while after the user
(07:41):
stops typing and then run the API instead of running
the API every single time they use up types and
a new letter.
Speaker 1 (07:50):
Okay, yeah, that makes that is a very useful one.
Rebound which, by the way, I don't think to currently
have a signal based alternative for it yet, Like I'm
seeing more and more signal based alternatives for things that
we used to do with our actually ass popping up. Recently,
(08:11):
Angle or nineteen was released and we got resource a
GUI which allows us to deal with asynchronous our requests
with signals. But we really don't yet have anything for
the bounds, although there are like simple pure functions to
handle us, like you could very easily just use modash
(08:34):
and if we allow you to bounce and you could
wrap it into a signal, but we don't yet have
anything like baked in into a signal API, which is interesting.
What else, what else do we still need our actually
ass to do?
Speaker 2 (08:52):
Yes, so we can also we try. There's are called
we try. So if you are running an API that
is supposed to run maybe when they use a load
of page. This particular operator allows mixed use of this API,
and then it will retry it three times and outside's
(09:15):
done retrying it, then you can display a message. You
can subscribe to that to it through a pipe and
then display a message after it retries like three times.
So whether retry operator if you can say you should
retry like three times, so if the API fails the
first time, you can retry the second time and then
(09:37):
retry the third time, and then on the third try
you could display a message to the user for they
used to know that the API failed or it didn't work.
Speaker 1 (09:48):
Right and for those for those scenarios, the operator that
you would recommend it is just pure retry.
Speaker 2 (09:56):
Yeah, you can use retry. That's that's one of the
operators you can use to get them results.
Speaker 1 (10:08):
Okay, I think that retry is an interesting one, but
at the same time, it's not very used like it
seems like a very nice use case, but I don't
think people in production a lot of times do that
like explicitly as we try cases prety logic, which they
(10:31):
should it makes sense to do so, but most people
just don't. I think it's also nature of our experience,
which is the code observable approach, because if you look
at the way that we use the retry operator, it's
just so interesting that you can just have an observable
(10:54):
and pipe and then pass retry and it almost seems
like how does it retry? And because imagine that if
you were a promise, you wouldn't be able to have
a promise and then just do a just put that
promise into a retry function, because the promise is just
(11:17):
the execution of the thing, whereas in this case, the
observable is almost like a formula for how you're going
to subscribe to something. So the retry operator actually has
all the information necessary not just to get the value
of the current observable, but to use the observable as
(11:37):
a formula and kind of like run it again if
it fails. I don't know if I'm complicating too much.
My explanation because it might be really tough for people that,
especially in audio format, trying to hear me and understand
what I mean. But perhaps my examples for that, Yes,
(12:00):
yeah you could.
Speaker 2 (12:01):
You could use it for an AJAX and then just
have the API you want to run and then we
try a few times. I get what you're saying too,
And a lot of people don't use it. A lot
of people don't know about it, but it's definitely something
to look into. It's one of the unused operators that
people just brush over and then they complicates the way
(12:25):
they re try and instead of just doing something like this.
Speaker 1 (12:29):
Yeah, I think in this list you also have the
partition operator, which I find to be particularly interesting. I
wouldn't say always useful, but it's interesting because I think
cases where people do two fieldures like that. That's not
specific to our actually, yes, by the way, just talking
(12:51):
about a raise in general, or any kind of iterators.
I've seen people use for one case and then filter
for the opposite case, just to have the two arrays,
like one filter for the condition being true and another
filter for the condition being false. And this is just
(13:12):
duplicated computation unnecessarily like you're going through the entire area
of elements twice, whereas you could just do it once.
But most people don't even know that there are functions
to do that, so you don't have this natively baked
into a ray methods. But for example, DASH exposes an
(13:34):
a ray utility called partition and it's the same thing
with RX. So partition is is almost like filter, but
instead of giving you a single array, it gives you
two arrays, one with all the elements that match the
condition and another with all the elements that don't match it,
which can be pretty.
Speaker 2 (13:55):
Mudful y, it's pretty useful because there are so many
cases where we have to filter out results from APIs
and it reads so many filters, and sometimes it can
be a lot of filters because they're trying to get
so many different information and section them into different.
Speaker 1 (14:16):
Values.
Speaker 2 (14:17):
But then for this one, you're able to do two
things at once and then get all the results you want.
Speaker 1 (14:26):
Yeah, exactly, exactly. I see the example they have on
the article is it's very straightforward as well, Like you
have a list of numbers and you want to separate
them between event numbers and odd numbers and the odd numbers. Yeah, yeah, yeah,
that makes that makes a lot of sense. M I
(14:51):
once did it just to give an interesting example for
the audience of how you can apply it. I once
used that in a form submission because what I wanted
to do is I wanted to check if any of
the object properties were different from what they were before
(15:12):
at the time of submission. So imagine that like you're
editing something, but when you're submitting the changes, then you
want to see if there were any changes or not.
Because if there weren't any changes, then you don't have
to then you can just let the person leave without
telling them that they are unsafe changes, right, And what
(15:35):
I did was I used a partition function to separate
which properties had changed from which ones hadn't, and then
in the model of unsaved changes, I would show up like, hey,
you have those acts properties, and I would list the
properties that had changed and said, if you leave the
(15:58):
spage now, then those changes won't be saved. Do you
want to save them before leaving it or do you
want to go ahead and discard the changes? But even
if they saved, I would still have to access all properties,
even the ones that weren't they had a change, because
the end point was but not attached, so I had
(16:21):
to give the entire object your day. So in this case,
I did it so I wouldn't have to have to
operations want to get just the unchanged properties and another
to get the change ones. I would just get all
of them, but also I would have a way to
have some separation when it also when necessary, I would
(16:43):
be able to just use all of them exactly. That's great.
That's a great use of the partition. That's even a
very creative will of using.
Speaker 2 (16:51):
It done the sampler way people would even think about it.
That's actually a very creative world.
Speaker 1 (16:56):
Using Yeah, thanks, all right, what else, let me take
a look here we have catch error, which it's kind
of straightforward. I think concat map is interesting because I
(17:17):
think concat and merge in general are interesting because so
many people that concat and merge. So perhaps you could
talk a bit about that.
Speaker 2 (17:29):
Okay, So for the concact it just helps you flatten
observable sequentially, and it's quite helpful because when they use
a clicks on something, you could you could perform a
concact map and then with a particular time and then
(17:50):
just just combine different values based on what they've they've
put in.
Speaker 1 (18:00):
So yeah, that that is correct. Just to simplify a
bit for the audience, Both contact and emerge allow you
to aggregate multiple observables into this single one. The difference
(18:22):
is that merge aggregates them in a parallel. So imagine
that you're having that you have multiple observables happening at
the same time, and when you merge them, you get
an observable that has all the events of the observables
(18:43):
that you aggregated at the moment that they have. So
let's say that you have a timer that happens every
one second and another that happens every half a second.
Then you would get a new observable that meets every
half a second, and also he meets twice every second.
But on the other hand, m sorry, concat is different
(19:08):
because comcat aggregates the observables in serial order. So it's
not going to output the values in parallel. It's going
to output all the values from the first observable until
that observable complete, and then it starts to and then
(19:30):
it emits the values from the second observable until it
completes it third. So the difference is just whether you're
aggregating things in serial order or in parallel order.
Speaker 2 (19:46):
So it waits for the inobservable to finish before moving
on to the next value.
Speaker 1 (19:52):
Exactly exactly. Yeah, yeah, and that is I think most
of it. Like the only other one that we haven't
touched is to tap, which I also think that most
people will be familiar with that, but for those that aren't,
just basically like map, but you just part the result,
(20:14):
so it's just for side effects like logging or basically
doing something with the value, but not necessarily talking about
what the function returns. Yes, so it doesn't alter the
actual value. Mm hmm, yep, yep, okay, okay. Jason, on
(20:37):
the subject or are extras? Is there anything else that
you think would be relevant to disgust with the audience
or should we start wrapping up?
Speaker 2 (20:49):
I would just say that you that definitely more uperdes
that I'm not in the top sevent sea that we
could always get into and do most of the ones.
I use that over here, and whenever there's something that
you feel is complicated, you could just search for rings
or do that or any of these tools to help
(21:09):
you out simplify certain things that would usually be complicated
to do. And I think that's that's it.
Speaker 1 (21:20):
Okay, all right, all right, Jason, let's do some quick promos.
So on my end, I'm just going to promote the
two companies that produce this show. So if you are
listening to this and you're interested in learning other technologies
not just Angular, then Top and Dobs has many other
shows as well. There's a show about React called React
(21:41):
round Up and it shows about continuous integration, container's appointment
JavaScript in general. There will there are a lot of podcasts,
so you check out Top and Down if you're interested
in that. And if you are a business owner or
if you are at a company that is currently looking
for remote developers, I would definitely recommend checking out on
(22:04):
boyd dot com. So this is a new vitalide dot
com because they have a very many proposition which basically
allows you to hire them and only pay for the
tasks that they deliver, which is a lot more client
friendly than paying by the hour or hiring a full
(22:25):
time employee and then paying a monthly value. So it's
it's very different, but definitely check out if you're interested
in that. That's you and Void dot com. So how
about you, Jason, what would you like to promote.
Speaker 2 (22:40):
Okay, I'd just like to promote myself as a software engineer,
full stat front and back and move out. If you
have any projects, if you want to be mentoring, if
you also want to mentor have anything.
Speaker 1 (22:54):
You would would like you to contribute to work on.
Speaker 2 (22:57):
If you'd like to work with me, I'm available. You
can check out my LinkedIn It's Jason Akaba and I'll
be happy to connect with anybody that listens and it's
interested in having a conversation.
Speaker 1 (23:11):
Awesome, Okay, okay, Jason, thank you so much for being
on the show. It's a pleasure to have you, dude,
it was a pleasure to be on this Yeah, thank you,
thank you. Good luck on looking for your next opportunity.
I hope it doesn't take so long. The market is
a bit crazy at the moment. But thank you so much,
(23:36):
thank you so much.
Speaker 2 (23:36):
Good luck to you too, and it was so so
much fun being.
Speaker 1 (23:40):
On this podcast. Awesome, thanks you. I have a great day,
you too.
Hey everyone, Welcome to Adventures and Angler, the podcast where
we keep you updated on all things Angular related. This
show is produced by two companies, Top and Devs and Onvoid.
Top and Devs is very great Top and dev so
get top and pay and recognition. We're working on interesting
problems and making meaningful community contributions. An Onvoid which provides
(00:26):
remote design and software development services on a task basis,
so clients only pay after tests are delivered and approved.
My name is Lucas S. Faganini. I'm your host in
the podcast, and joining me in today's episode is Jason Akbar,
which is a food stack software engineer mainly focus on
(00:48):
front end and by the way, for the companies hearing
this out there, Jason is currently looking for another role,
so if you're hiring all your companies Angular all React,
be sure to check out Jason Akbar. So, Jason, thanks
for being at the job. Thank you for having me.
(01:11):
I'm glad to be here. Awesome, Awesome, You're very welcome. So, Jason,
the reason why you're here is because you wrote a
few articles on Medium and one of those articles was
about our ex JS operators and that was one that
taught our attention and we thought it would be interesting
to bring that knowledge to the rest of the audience.
(01:34):
So maybe you could talk a little bit more about
the article that you wrote and what was the intention
behind it, like what we're trying to educate people about.
Speaker 2 (01:49):
Okay, So before I wrote the article, I didn't know
much about ours and then I wanted to do more
research on it to figure out the creatures and how
they can just make my work easier at more streamlined,
because I realized that so many things I didn't need
to do myself that our EXSS makes.
Speaker 1 (02:09):
Easier for you.
Speaker 2 (02:10):
So after I was done with my research, I just said,
it's writes an article on it so that people would
find the information they need on OURCS easier that I
had to find it. So that was the intention behind rights.
Speaker 1 (02:23):
In the article. Okay, okay, awesome, And by the way,
I understand what you mean by that, because I also
had a few challenges on my own when I was
going through my learning journey of our Extra ASS, I
would say it was definitely not super easy. And I
(02:51):
remember that there was one website in particular, I think
it was called Learn our Extra Ass. If I recall correctly,
I can check, but if it was learn our XGS,
which had some really nice diagrams for each of the operators,
and that helped me a lot when I was learning or.
(03:11):
I think it was the opposite, like the official XGS
documentation has the diagrams, but this website had more examples.
It's one of either, and to me, the combination of
the official or XGS docs and this website, but always
learn OURXGS dot ioogies check it. To me at least
was really helpful when I was learning our xs in
(03:35):
the beginning of my angular journey. So I wonder, like,
what do you think about that and what worked for you?
Like how did you learn our XGS to get into
a more advanced level.
Speaker 2 (03:51):
Okay, so for me, I learned urcs from various sources.
I can't correctly remember the sources I learned it from,
but it was very resources. Also, I just asked AI
for some of the resources if you can give me,
and I also check some websites and then I use
some of the operators. So I think I went on
(04:12):
the official website too, and then I found most of
the opulators that were necessary to me.
Speaker 1 (04:17):
The ones I use the most at the map, the.
Speaker 2 (04:19):
Filter and all those operators, these are the ones I
use the most, so I do. I do think I
would also check out the website you're also talking about
to see how that can also help me in my
journey learn in our experience.
Speaker 1 (04:32):
Now, getting back to your article in particular, it says
the top seventeen rxgs operators. So what are the top seventeen?
Speaker 2 (04:44):
Okay, So there's the map operator, the filter operator, the
tap do operator, there's the comcat operator. There's the merger operator.
There's the debounds time operator. There's the reduce operator. There's
the retry operator. There's the concact MAC operator does the
switch MAC operator. There's the partition operator. There's the combined
(05:04):
leaders to operator. There's the scape operator. There's the ass I mean,
I can go on and on. There's the take until operates,
and then there's the catch.
Speaker 1 (05:12):
Error operator and out of there is are there any
that you would consider more unknown? Is because I guess
that at this point, at least map filter reduced are
ones that are very straightforward for every Angler developer. I
(05:37):
don't think that there are many Angler developers that are
unfamiliar with those. But are there any that you would
consider to be more interesting? To talk more about.
Speaker 2 (05:49):
I think like the Comcast operator as an operator that
I'm not a lot of people use, but it can
be helpful to just merge to two things together so
you can conquact multiple observables sequentially emitting values together. I
(06:09):
think that's an operator a lot of people don't use.
And the de bounced time it's also an operator a
lot of people don't use. But also who use debounced
timers for so many things. If someone is typing something
in an input and it's supposed to run a particular function,
and they don't want it to run every time they
user putting an input, they want to wait maybe some
milli seconds before the function rants or the API rants again,
(06:34):
they usually try to create the whole debounce thing themselves,
but then there's an operator like the debounce time that
makes that quite simple to do.
Speaker 1 (06:46):
Okay, yeah, that does make sense, And can you give
me some examples of where to use in practice? For
like real Angular applications.
Speaker 2 (07:00):
If a user is typing in something in an input,
and then whenever the user types in something, you're supposed
to search for results and display it on the page
in real time as the yser types. Sometimes you wouldn't
want the API to run every single time they user
types in something. They could type in something and do.
Speaker 1 (07:18):
Need it later.
Speaker 2 (07:19):
So usually debounced timers are used to wait a little
while till the key up till they used to wait
a little while till the user stops typing for some
time and then run the API. So that's that's a
situation where the debounce time to be very helpful so
that you could just wait a while after the user
(07:41):
stops typing and then run the API instead of running
the API every single time they use up types and
a new letter.
Speaker 1 (07:50):
Okay, yeah, that makes that is a very useful one.
Rebound which, by the way, I don't think to currently
have a signal based alternative for it yet, Like I'm
seeing more and more signal based alternatives for things that
we used to do with our actually ass popping up. Recently,
(08:11):
Angle or nineteen was released and we got resource a
GUI which allows us to deal with asynchronous our requests
with signals. But we really don't yet have anything for
the bounds, although there are like simple pure functions to
handle us, like you could very easily just use modash
(08:34):
and if we allow you to bounce and you could
wrap it into a signal, but we don't yet have
anything like baked in into a signal API, which is interesting.
What else, what else do we still need our actually
ass to do?
Speaker 2 (08:52):
Yes, so we can also we try. There's are called
we try. So if you are running an API that
is supposed to run maybe when they use a load
of page. This particular operator allows mixed use of this API,
and then it will retry it three times and outside's
(09:15):
done retrying it, then you can display a message. You
can subscribe to that to it through a pipe and
then display a message after it retries like three times.
So whether retry operator if you can say you should
retry like three times, so if the API fails the
first time, you can retry the second time and then
(09:37):
retry the third time, and then on the third try
you could display a message to the user for they
used to know that the API failed or it didn't work.
Speaker 1 (09:48):
Right and for those for those scenarios, the operator that
you would recommend it is just pure retry.
Speaker 2 (09:56):
Yeah, you can use retry. That's that's one of the
operators you can use to get them results.
Speaker 1 (10:08):
Okay, I think that retry is an interesting one, but
at the same time, it's not very used like it
seems like a very nice use case, but I don't
think people in production a lot of times do that
like explicitly as we try cases prety logic, which they
(10:31):
should it makes sense to do so, but most people
just don't. I think it's also nature of our experience,
which is the code observable approach, because if you look
at the way that we use the retry operator, it's
just so interesting that you can just have an observable
(10:54):
and pipe and then pass retry and it almost seems
like how does it retry? And because imagine that if
you were a promise, you wouldn't be able to have
a promise and then just do a just put that
promise into a retry function, because the promise is just
(11:17):
the execution of the thing, whereas in this case, the
observable is almost like a formula for how you're going
to subscribe to something. So the retry operator actually has
all the information necessary not just to get the value
of the current observable, but to use the observable as
(11:37):
a formula and kind of like run it again if
it fails. I don't know if I'm complicating too much.
My explanation because it might be really tough for people that,
especially in audio format, trying to hear me and understand
what I mean. But perhaps my examples for that, Yes,
(12:00):
yeah you could.
Speaker 2 (12:01):
You could use it for an AJAX and then just
have the API you want to run and then we
try a few times. I get what you're saying too,
And a lot of people don't use it. A lot
of people don't know about it, but it's definitely something
to look into. It's one of the unused operators that
people just brush over and then they complicates the way
(12:25):
they re try and instead of just doing something like this.
Speaker 1 (12:29):
Yeah, I think in this list you also have the
partition operator, which I find to be particularly interesting. I
wouldn't say always useful, but it's interesting because I think
cases where people do two fieldures like that. That's not
specific to our actually, yes, by the way, just talking
(12:51):
about a raise in general, or any kind of iterators.
I've seen people use for one case and then filter
for the opposite case, just to have the two arrays,
like one filter for the condition being true and another
filter for the condition being false. And this is just
(13:12):
duplicated computation unnecessarily like you're going through the entire area
of elements twice, whereas you could just do it once.
But most people don't even know that there are functions
to do that, so you don't have this natively baked
into a ray methods. But for example, DASH exposes an
(13:34):
a ray utility called partition and it's the same thing
with RX. So partition is is almost like filter, but
instead of giving you a single array, it gives you
two arrays, one with all the elements that match the
condition and another with all the elements that don't match it,
which can be pretty.
Speaker 2 (13:55):
Mudful y, it's pretty useful because there are so many
cases where we have to filter out results from APIs
and it reads so many filters, and sometimes it can
be a lot of filters because they're trying to get
so many different information and section them into different.
Speaker 1 (14:16):
Values.
Speaker 2 (14:17):
But then for this one, you're able to do two
things at once and then get all the results you want.
Speaker 1 (14:26):
Yeah, exactly, exactly. I see the example they have on
the article is it's very straightforward as well, Like you
have a list of numbers and you want to separate
them between event numbers and odd numbers and the odd numbers. Yeah, yeah, yeah,
that makes that makes a lot of sense. M I
(14:51):
once did it just to give an interesting example for
the audience of how you can apply it. I once
used that in a form submission because what I wanted
to do is I wanted to check if any of
the object properties were different from what they were before
(15:12):
at the time of submission. So imagine that like you're
editing something, but when you're submitting the changes, then you
want to see if there were any changes or not.
Because if there weren't any changes, then you don't have
to then you can just let the person leave without
telling them that they are unsafe changes, right, And what
(15:35):
I did was I used a partition function to separate
which properties had changed from which ones hadn't, and then
in the model of unsaved changes, I would show up like, hey,
you have those acts properties, and I would list the
properties that had changed and said, if you leave the
(15:58):
spage now, then those changes won't be saved. Do you
want to save them before leaving it or do you
want to go ahead and discard the changes? But even
if they saved, I would still have to access all properties,
even the ones that weren't they had a change, because
the end point was but not attached, so I had
(16:21):
to give the entire object your day. So in this case,
I did it so I wouldn't have to have to
operations want to get just the unchanged properties and another
to get the change ones. I would just get all
of them, but also I would have a way to
have some separation when it also when necessary, I would
(16:43):
be able to just use all of them exactly. That's great.
That's a great use of the partition. That's even a
very creative will of using.
Speaker 2 (16:51):
It done the sampler way people would even think about it.
That's actually a very creative world.
Speaker 1 (16:56):
Using Yeah, thanks, all right, what else, let me take
a look here we have catch error, which it's kind
of straightforward. I think concat map is interesting because I
(17:17):
think concat and merge in general are interesting because so
many people that concat and merge. So perhaps you could
talk a bit about that.
Speaker 2 (17:29):
Okay, So for the concact it just helps you flatten
observable sequentially, and it's quite helpful because when they use
a clicks on something, you could you could perform a
concact map and then with a particular time and then
(17:50):
just just combine different values based on what they've they've
put in.
Speaker 1 (18:00):
So yeah, that that is correct. Just to simplify a
bit for the audience, Both contact and emerge allow you
to aggregate multiple observables into this single one. The difference
(18:22):
is that merge aggregates them in a parallel. So imagine
that you're having that you have multiple observables happening at
the same time, and when you merge them, you get
an observable that has all the events of the observables
(18:43):
that you aggregated at the moment that they have. So
let's say that you have a timer that happens every
one second and another that happens every half a second.
Then you would get a new observable that meets every
half a second, and also he meets twice every second.
But on the other hand, m sorry, concat is different
(19:08):
because comcat aggregates the observables in serial order. So it's
not going to output the values in parallel. It's going
to output all the values from the first observable until
that observable complete, and then it starts to and then
(19:30):
it emits the values from the second observable until it
completes it third. So the difference is just whether you're
aggregating things in serial order or in parallel order.
Speaker 2 (19:46):
So it waits for the inobservable to finish before moving
on to the next value.
Speaker 1 (19:52):
Exactly exactly. Yeah, yeah, and that is I think most
of it. Like the only other one that we haven't
touched is to tap, which I also think that most
people will be familiar with that, but for those that aren't,
just basically like map, but you just part the result,
(20:14):
so it's just for side effects like logging or basically
doing something with the value, but not necessarily talking about
what the function returns. Yes, so it doesn't alter the
actual value. Mm hmm, yep, yep, okay, okay. Jason, on
(20:37):
the subject or are extras? Is there anything else that
you think would be relevant to disgust with the audience
or should we start wrapping up?
Speaker 2 (20:49):
I would just say that you that definitely more uperdes
that I'm not in the top sevent sea that we
could always get into and do most of the ones.
I use that over here, and whenever there's something that
you feel is complicated, you could just search for rings
or do that or any of these tools to help
(21:09):
you out simplify certain things that would usually be complicated
to do. And I think that's that's it.
Speaker 1 (21:20):
Okay, all right, all right, Jason, let's do some quick promos.
So on my end, I'm just going to promote the
two companies that produce this show. So if you are
listening to this and you're interested in learning other technologies
not just Angular, then Top and Dobs has many other
shows as well. There's a show about React called React
(21:41):
round Up and it shows about continuous integration, container's appointment
JavaScript in general. There will there are a lot of podcasts,
so you check out Top and Down if you're interested
in that. And if you are a business owner or
if you are at a company that is currently looking
for remote developers, I would definitely recommend checking out on
(22:04):
boyd dot com. So this is a new vitalide dot
com because they have a very many proposition which basically
allows you to hire them and only pay for the
tasks that they deliver, which is a lot more client
friendly than paying by the hour or hiring a full
(22:25):
time employee and then paying a monthly value. So it's
it's very different, but definitely check out if you're interested
in that. That's you and Void dot com. So how
about you, Jason, what would you like to promote.
Speaker 2 (22:40):
Okay, I'd just like to promote myself as a software engineer,
full stat front and back and move out. If you
have any projects, if you want to be mentoring, if
you also want to mentor have anything.
Speaker 1 (22:54):
You would would like you to contribute to work on.
Speaker 2 (22:57):
If you'd like to work with me, I'm available. You
can check out my LinkedIn It's Jason Akaba and I'll
be happy to connect with anybody that listens and it's
interested in having a conversation.
Speaker 1 (23:11):
Awesome, Okay, okay, Jason, thank you so much for being
on the show. It's a pleasure to have you, dude,
it was a pleasure to be on this Yeah, thank you,
thank you. Good luck on looking for your next opportunity.
I hope it doesn't take so long. The market is
a bit crazy at the moment. But thank you so much,
(23:36):
thank you so much.
Speaker 2 (23:36):
Good luck to you too, and it was so so
much fun being.
Speaker 1 (23:40):
On this podcast. Awesome, thanks you. I have a great day,
you too.
Popular Podcasts
CrimeLess: Hillbilly Heist
It’s 1996 in rural North Carolina, and an oddball crew makes history when they pull off America’s third largest cash heist. But it’s all downhill from there. Join host Johnny Knoxville as he unspools a wild and woolly tale about a group of regular ‘ol folks who risked it all for a chance at a better life. CrimeLess: Hillbilly Heist answers the question: what would you do with 17.3 million dollars? The answer includes diamond rings, mansions, velvet Elvis paintings, plus a run for the border, murder-for-hire-plots, and FBI busts.
Crime Junkie
Does hearing about a true crime case always leave you scouring the internet for the truth behind the story? Dive into your next mystery with Crime Junkie. Every Monday, join your host Ashley Flowers as she unravels all the details of infamous and underreported true crime cases with her best friend Brit Prawat. From cold cases to missing persons and heroes in our community who seek justice, Crime Junkie is your destination for theories and stories you won’t hear anywhere else. Whether you're a seasoned true crime enthusiast or new to the genre, you'll find yourself on the edge of your seat awaiting a new episode every Monday. If you can never get enough true crime... Congratulations, you’ve found your people. Follow to join a community of Crime Junkies! Crime Junkie is presented by audiochuck Media Company.
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.