December 5, 2024 • 57 mins
Armen Vardanyan is an Armenian Angular developer who works extensively with both angular and RXjs. He walks Chuck through the ins and outs of how he uses RXjs to expand the functionality of his Angular applications and how to think about observables in general.
Picks
Become a supporter of this podcast: https://www.spreaker.com/podcast/adventures-in-angular--6102018/support.
Picks
- Armen- Frank Herbert's Dune Saga 6-Book Boxed Set
- Charles- The Way of Kings: The Stormlight Archive, Book 1
- Charles- Words of Radiance: The Stormlight Archive, Book 2
- Charles- Oathbringer: Book Three of the Stormlight Archive
- Charles- Rhythm of War: Book Four of The Stormlight Archive
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:06):
Hey everybody, and welcome to another episode of Adventures in Angler.
I'm your host today, Charles Maxwood, and we are talking
to Arman. I love getting people from other countries because
I'm looking at the name and going, let me, let
me try it. It's Vardanian.
Speaker 2 (00:20):
Yeah, you've got it mostly right. I mean your words
usually are pronounced that they are written.
Speaker 1 (00:29):
Yeah. Cool. So do you want to just tell us
a little about yourself what you do over there in
Armenia and yeah, how long have you been doing Angular
and all that good stuff?
Speaker 2 (00:38):
Yeah? Sure. So I'm a senior front and developer at
an Armenian company called Wolo. I'm in sitting in our
office right now. I'm a conference room. I'm a front
and tim lead, and I'm working on Angular for I
think it's the fourth year that I'm working on Angular already.
(01:01):
So we started one of our projects back when Angular
two was in beta. Uh huh, I guess I've been
there from the start.
Speaker 1 (01:11):
Oh wow, Yeah, I remember those days that all the
anxiety around, you know, all the stuff that was changing.
Speaker 2 (01:18):
It was it was sort of you were in constant
danger that something that you are doing today is going
to change tomorrow, and you have to prefecture some of
your code again.
Speaker 1 (01:30):
Yeah, but we're in a good place now. I'm kind
of curious as we get started. I mean, we don't
often hear a whole lot from Armenia, I guess in
the Angular community. So what does the development and regular
community look like out there?
Speaker 2 (01:46):
So Armenia has this problem with our developers that don't
really participate a lot in the community, I mean in
in a global sense, But we actually have lots of
very good software and in Angular too. So the most
biggest part of the market is React, but there are
(02:07):
also also big companies here that use Angular and concentrate
on Angular. And as a matter of fact, I'm also
teaching Angular in a private coding school. It's kind of
like a Blong boot camp. Of course, there are not
as many people enrolled in that program as there are
(02:29):
people in the React program, but we still have enough
demand for Angler developers to keep it going.
Speaker 1 (02:37):
Yeah, that makes sense.
Speaker 2 (02:39):
More usually the larger companies that use Angular.
Speaker 1 (02:42):
Oh really, that's interesting because I've seen a bunch of
larger companies using React. I've seen I've seen kind of
all across the board, I guess for all kinds. But
I talk to people across the board.
Speaker 2 (02:55):
So there are also companies that you've kind of both
on a halfferent projects. For example, one company probably know about,
you know, Pixard right the right, but that's an Armenian company,
and I know that they use both Angular and oh yeah,
(03:16):
as a matter of fact, they have reached out to
me to you know, try to hire me into their
Angular program. I didn't want to, but that's how I
learned that they actually are doing Angular. I always thought
that in and there were web projects they're using going
to react, I know that they were using correct. It
turned out they also had projects in Angular different products,
(03:36):
so probably.
Speaker 1 (03:38):
Yeah, that makes sense. I'm kind of curious as we
get into this, how did you get into Angular's.
Speaker 2 (03:43):
That's sort of an interesting story is that at the
very beginning, I was a PHP developer. So the very
first job I got, which we started this day exactly
five years ago, that was my very first working day,
so and I was hired as a PHP developer. But
(04:04):
the very first day they told me that they really
needed a Python developer. So they asked if I could
try to, you know, learn some basics quickly and try
to do some features. And I was sure, Okay, I've
already hired, so I don't have really option. So I
spent like four days doing some Python and started doing backhand.
(04:27):
But they're working on a project that there were pieces
written in Angular jas in twenty sixteen. Within the beginnings
ty sixteen, we didn't really have Angular one up and running.
So I started doing doing Angular Jazz and it sort
of became a parent that it's more interesting for me.
So when they got a project that they were going
(04:48):
to write from scratch, they decided to create a single
page application on Angler Jazz and all of that, and
I started doing it. So I got I pitched backhand
and started doing only front and then I Angular Jazz.
Then I switched to my current office and they were
also starting in new projects from scratch and they were
already doing it Angular in Angular two, which was in
(05:11):
I guess I was in beta yet. Yeah, so that's
how I got into Angular and awesome, he's been wrong
round but I still enjoyed.
Speaker 1 (05:22):
Yeah. Yeah, it's it's it's fun stuff. I mean, I
kind of dabble in all of them, and it's it's
interesting to see the different approaches but also see the
things that they have in common. So yeah, good deal.
So you've been writing I think I found like two
or three articles where you wrote about r xjs or
you know, some kind of reactive code. I'm a little
(05:44):
curious as we get into this, what what was it
that drove you to start writing about rxjas in particular?
I mean, rxs is kind of core to the way
the angular works. But for the most part, I find
that I can kind of not pay a whole lot
of attention to do what RCGS is doing and just
kind of do things the angular way and it mostly works.
(06:04):
And then I just kind of know in my head
that it's RCGS is doing every thing well.
Speaker 2 (06:09):
For me, it was sort of work experiencing that I
was working on a project that had lots of interconnected logic.
So in a sense, imagine like this is UI that
I have like a drop down, I have another drop down,
and the values in this drop down depend on what
I selected the other drop down, and everything that I
(06:31):
selecting those two dropdowns depend on some permissions that come
from back and like can I do this, can I
do that? And everything is very mixed. So at first
I was trying to keep track of all that stuff
in an imperative way, like like I said, the angular
ways around methods. So when on select this thing, round
(06:52):
this function which will go update the internal state and
so on. But it quickly got out of hands because
I ended up trying to synchronize five or six different
states with each other so that updates the other has
to update. And it was all inside one component. I
couldn't even there were scientor connected. I couldn't even divide
(07:14):
it several components to try to write sort of make
them communicate with each other. So for the next piece,
I decided, I will try to do it in an
RHS way. I will try to create sort of observables
for all the stuff and use operators and functions like
combinlatest or relatest from and so on too, and I
will use the acin pipe to just just derive the
(07:37):
state sort of from observables that I already have and
put them directly into the template using the acin functions,
no subscribes, And it worked way more elegantly that anything
that I was trying to do before that. And I
always enjoyed RGS, but I was in the camp of
the people that would say, oh, no, you're using too
(07:58):
much rgs, this is over engine and so on. I
always felt like, oh, why did this guy put I
don't know this logic inside and observable. Don't really need
an observable, you just use just use an impertive function.
But after doing it, I kind of got the notion
behind it that I can view my derived data in
(08:20):
the end as a combination of different streams and operators
applied to them to mop and find my finals. Said
that I wouldn't going to display to the end user,
and that was a very elegant thing. So I started
sort of investigating inside my project before starting to read
what other people write about are just because of course,
(08:41):
you can find lots of articles and create literature online
on how our jets may benefit their application. And so
I started investigating my own application pite fund at Oh again,
Oh I find this function. I don't need this function.
I can reach it. I can put it inside single
property that's unobservable and use it operator and so on
(09:02):
and so on. I started sort of writing down pieces
of rules that I will try to follow, and lots
of those rules will actually stupid rules. I was sort
of finding out. I was sort of finding out what
I have to do with trial and their trial and
there and then one day I was like, okay, let's
just try to read about more about RGS. Just opened
(09:24):
documentation that started trying different operators, and my project transformed.
I sort of got way better code than I thought. Yeah,
this is this is this is good. I'm going to
write an article about it. Because every time that I
sort of go from experience with a new library, a
new design pattern, or some a new approach, the best
(09:46):
way for me to finally digest what I learned is
to try to communicate my new knowledge to others. So
when I sort of when I teach, I also learned.
That's two way thing for me. I always read an
article about anything new that I've done, and then it
got rolling. So I got three articles on RGS and Angular.
(10:08):
I got an article on Unexpected Things in RGAS. I
wrote an article on best practices in our yas. I
guess I have six or seven articles on rys.
Speaker 1 (10:17):
Nice and I think I saw some of them on
Angular in Depth. Is that where they're all posted or
just some of I.
Speaker 2 (10:23):
Guess one or two of them have been posted on medium.
Then in Depth moved from moved from medium, they stopped
posting on their blog. There the only posted on the
website and in the in that community. So first I
was hoping that stuff to Medium, but then I also stopped.
I don't actually visit Medium. I opened Medium like a
(10:46):
week ago and was terrified to find out actually one
thousand followers. I didn't know. I didn't know I did
many followers on Medium. You're popular follow and I didn't
know about it because like for four or five months,
I didn't even open stopped reading their photo alter got
involved with the in depth.
Speaker 1 (11:05):
Yeah, I didn't know I was talking to celebrity. Wow,
So there you go. Got to start somewhere, right, Yeah.
So yeah, I just I find this really fascinating and
it's it's interesting too because I was I was working
on an app myself where we were building like a
(11:27):
sign up wizard, and yeah, we kind of put I mean,
we were doing and react, but we were putting a
whole bunch of stuff in you know, basically a higher
order funk or a higher order component, right that had
a whole bunch of components up underneath it so we
could maintain all the state underneath it. And yeah, like
(11:48):
maintaining all of the different events that were going on
in it and reacting to those. It was, yeah, just
doing it kind of the react way, or I was
trying to think of how to do it neither, and
we probably would have approached it much the same way,
and you know, done things the angular way. I realized that, yeah,
there were a lot of events that we would have
been emitting that yeah, something like our xgs. I didn't
(12:10):
even think about it, And I'm just going I feel
kind of silly now because yeah, it would have been
so much easier to just approach it with our XGS
and just say, okay, if any of these things happen
right then amid an event, and if any of these
things happened amid an event, and then yeah, if we
come back around any of this stuff, then you know
or subscribe to those events and we just know what
(12:31):
to do.
Speaker 2 (12:32):
So yeah, the same sort of revelation I went through
when I would find to reflector alls of stuff. Nowadays,
when I start anything new and the team I'm working
in as sort of receive new projects all along from
the client, so U we'll just received something that'll probably
have to wat from scratch using stuff that you already have.
(12:55):
So the next thing we got I was like, yeah,
but we're going to vangel X. We're going to we're
going to use ARGs a lot. My next stop is
trying to reflector and move away from using internal states
at all. Like I'm going to use the ANJX component
store for all the internal interactions and use ang x
(13:17):
for everything community between the components. It's more sort of
an experiment. I'm not sure that that's a good idea.
I will, I will try to do it, and I
guess it might be a good idea because but I can.
I can now ditch normal change detection. I can use
on pushing all the components. Because I'm only having observables
an acing pipe, I don't have to use normal change detection.
(13:40):
I can default to on push. That's a nice thing
to have. And also I will sort of that will
solve the problem that if you're like, oh am I
going to create an observable byhand for everything, No, you
can just you know, use the store class and start
from it right store ter selectors put them in the
components so it can be it can exist in parallel
(14:03):
with your component, and you will see all the transformations
of the store with the updata functions and so on,
just putting their use this in PIPEM and so on
and so on, and I think that might be nice.
So I'm sort of going to write a proof of
concept or something like it. Can we can we ditch
local internal class based states and just use or jest.
Speaker 1 (14:24):
Yeah, yeah, I'm kind of curious to see how that
would work out. To be perfectly honest, I haven't done
a whole lot with r xs or EDGRX, so yeah,
it'll be interesting to see how it all comes together.
So what what is kind of the biggest thing or
the biggest problem you found r X chess songs within
your your app.
Speaker 2 (14:45):
Oh well, well all starts again. The biggest sort of
benefit that you get from it is removing imparative logic
number one benefit and not having to synchronize two different states.
So my biggest problem always was that I have sort
(15:08):
of these two pieces of data that are interconnected. But
it's not that like one is derived from the other
or something, but more like the change in this one
can trigger a change in this one in a way
if there is some condition or something something, and that
is really like obviously apparent in large applications like enterprise
aps when you have different configurations, personal user settings that
(15:31):
can affect the UI and customized things and so on
and so on and so on. And when you switch
to RCJZ, you sort of, even unwillingly, you have this
single source of truth, so you don't have to check
three or four places to see how your state is transformed.
(15:51):
If there is sort of you have this small dependency
like you have an engine model binding, or you have
a component and you passing an input and you use
the acing pipes, or apparently this is an observable. If
you go to that observable, you immediately know what can
happen to it. You see, this is the observable. Oh,
this is the stream. This begins here, these operators are
(16:14):
used on it, so and that's the end. So you
don't have to look anywhere because it's an observable. No
one can modify it from somewhere else. This is what
you have. This is always what you have. If there's
a problem, it's in these five lines of code or
anything you have written. So if you really use that,
well it's easy to read, it's easy to find stuff
in your code. You don't get sort of oh, h okay,
(16:38):
I have this array. Let's let's just control app see
whoever has updated, or let's right click and file references
and stuff like. You know you don't have. This is
apparently everything you have. And that's a it's a big
thing because then you will always have bugs. And obviously
most of your work then would be try to find
(17:00):
where the bug is coming from, because usually when we
find in like eighty percent of cases, if we find
where the bug is sort of located, we usually easily
fix that, right, So finding is sometimes as a problem
understanding exactlyly piece of code effect. So if we have
only one piece of code that is affecting anything, so
it's very easy. Okay, I have five operators, one of
(17:22):
them is doing something wrong. Let's find out what is
in the five lines of code. That for me is
the biggest benefit because in imperative logic you always have
to sort of dive into ti times say oh, why
do we have a loop here? Oh this is all Okay,
this is array, push something into ray, get something from array,
and sort of go going gone, And that can become overwhelming,
(17:45):
especially if the logic is large.
Speaker 1 (17:48):
Yeah that makes sense, I mean, yeah, you subscribe to
a stream and then yeah, everything that happens downstream from that, Yeah,
nobody's modifying the array. It emits another stream or another
array effectively, and so it's easy to follow. I guess
the other question that I have, just kind of talking
through your story here and talking through the you know,
(18:09):
the situation where you, you know, you move kind of
outside of the internal state management with angular and into observables,
was at what point do you feel like that makes sense?
I mean, should you just do that from the get
go or do you wait till your app gets to
a certain complexity before you start using RxJS as as
(18:30):
this kind of Yeah.
Speaker 2 (18:31):
That's actually a very good question because for a lots
of people usually that exact question is the sort of
obstacle that usually either don't have enough time to think
about it, or just don't want to recolector too much,
or don't want to sort of overengineer like people have said, Oh,
(18:56):
maybe I'm blowing these out of proportions and I don't
need these whole lot of stuff, may be even doing
just a regular way.
Speaker 1 (19:04):
Yeah, my answer to that is usually try it and
then you know, right, yes, sort.
Speaker 2 (19:08):
Of yeah, But of course, obviously in the real world,
lots of people that won't have enough time to do that.
Like this project, you have this deadline, you have to
do something, and you're not sure. Maybe if I try
to do this, this is something you maybe we won't
have time. And of course some people say, oh, my
application is small, I don't need something like that. I
was saying that in the context of angio X, but
(19:29):
I said something on Twitter like six months ago or
something that lots of people sort of agreed with. It
went like this, if you have an application that is
large enough that you write it in Angular, then you
have an application that is large enough that you can
use angio x. The same for me applies to ourggs.
(19:50):
It may sound a bit radical, like maybe not some
people say this small thing, or if if it's so small,
if you say it's sort of a two pages, why
do you need this behmit of a framework that Angular
is like, it's big, it has lots of things, there's
lots of feature you can write it in something easier
if you. Of course, obviously, if the angler is the
(20:11):
only thing that you know, that's of course normal. That's
also a situation that happens in real life. But in
most cases, usually people would know some technology they're writting
some really small but if you're acting something really big
that you already opted to use Angular because it has
lots of feature because people usually like Angular for all
(20:33):
the out of the box stuff that it provides. Angular
developers that use sometimes use React. Most of the confusion
that I can, oh, how I did stop this? We
usually in Angular we have these this, and I have
to now go on find for the party libraries to
do something, maybe write something from scratch to do that.
In React, that's what they usually find not good in
(20:56):
other frameworks, especially React, because React there is more like
sort of shell, and that's a good thing in its
own way. I personally enjoy Reacts. But the thing that
I like Angular moid is that it's more opinionated and
it has more features, so you can use this and
this and this. You don't have to think about HP
requests that you covered. You don't have to think about forms,
(21:16):
and for me, Angular forms is the best thing Angular has.
It's flawed, but for me, it's really the best like
form related library out there. It's it's very good everything
you need, so of course you opt in for Angular
for all those features. So obviously if you need lots
of features, and you have a larger enough applications, so
(21:38):
why not use ANGI X for interconnected pieces at least
you don't even need to use any write everything in ANGLICS.
There is some debate to it, but obviously the stuff
that is interconnected, the stuff that they shared stay between components,
and grex is just solve all of that for that
for you, right, so it makes sense to do that.
(21:58):
The same goes for for RGS. Ang ICs is basically
like RGS but stronger. If you can use RGS solve
some problems, it would be good, and the sooner you started,
the less problematic it would be to use that code,
because refectoring is always harder than writing code from scratch. Obviously,
(22:19):
you usually face more bugs if you refractory, because sometimes
you might look at code that you yourself even have written,
but you would misunderstand something there, and refractoring into RGS
it will lose some use case or something. So of course,
starting earlier, my advice would be, if you're beginning an
angular application, at least consider using more RHES or maybe
(22:42):
using a X. If you're going into it, at least consider.
Speaker 1 (22:45):
It right now. That makes sense. It's it's kind of
interesting though that you started out with if your app
is big enough for Angular, then it's big enough to
use RXS, Because I mean, I that is true, you know,
and I thought, okay, well, the would you use for
the smaller apps? And you know, if you things come
to mind, like you know, use HTML and CSS obviously,
(23:06):
but then you know, you pull in like a jQuery
or a stimulus or something like that that just kind
of puts stuff over the top of it, that just
kind of gets you the functionality that you need. That's
that's really really simple. Yeah, you're pulling in Angular when
you need something that's a little more that has more
depth to the experience you're creating. Yeah, that makes a
ton of sense. So what I guess the other thing
(23:28):
that I'm wondering about is, you know, now that you've
kind of gone into the deep end with r XJS,
what do you find are the things that people misunderstand
about it? Like where where do people get stuck on
RXS being a solution or get stuck on what it
can and can't do?
Speaker 2 (23:44):
Well. I had experience with lots of developers that tried rgs,
both in our team and outside, so I noticed that
there are many free problems with rs the people sort
of not right the best code that they could do,
and all of them are connected to how they use RGS.
(24:07):
So they either not use it enough, misuse it, or
plainly abusing it. Okay, So I tried to cover all
the three cases. So obviously first case not using it enough,
because there's a problem you can miss all the r egs.
People won't try to apply reactive logic to it. For that,
(24:31):
I've written my very first article and it's called the
RGS in Angular. It was the first one the three parts,
and in part one I wrote about how you can
change your imperative logic to more reactive or functional programming
style to a more declarative approach. Okay. So it involved
(24:52):
trying to understand the source of data, trying to understand
what effects the data and how it gets transformed, and
then getting the final result the result and displaying it
to in the template in the UI. So those were
the steps that you can sort of try to apply
to any problem. Like if you've got I'm going to
(25:12):
develop this feature, I can try to use the steps
to understand how can I convert it? Right? Using r JET,
you can sort of always try to do that. So
even if you don't convert something something it's large enough,
you have three factor you don't have time, you still
can like sort of process in your head. If it
won't think really much. You can try to think about
ten minutes. If you sort of understand instantly how the
(25:34):
flow of the data is, now okay, you can go
forward and just try to right or jets. People often
don't do that. I know people that know urges ats well,
they know lots of operators, how they work, some new ones,
but they just won't use them. It's like, yeah, okay,
I wrote five lines of what it works. Yeah, I
don't think the rjets for this, but really it would
look more elegant and more scalable if they did there jets,
(25:55):
even even for the five lines of So that's the
first problem, not using it enough, not sort of getting
into it and trying it to apply to all at
least mentally apply to all the problems that they try
to solve. So there's that point one, and then it
comes point to sort of misusing our ages. So how
people do misuse urages is usually what they do in
(26:15):
the first step. So a lot of some people will
come and think, Okay, I'm not using urage jes now
I want to use it more. That's a really good start,
but obviously they are going to make mistakes on the
way as all of us is done. So what would
they do is they will sort of start using observables
and not really appreciating all the all the upsides that
(26:39):
they provide, like subscribing a lot. You don't really need
to subscribe an observable like explicitly you can use the
ass pipe. So that's the first three people just teach it.
They will write subscribe and a call back with lots
of imperative logic. Then they will use they will use
features of the language instead of using operators. Like one
(27:00):
of my articles about best practices i I was sort
of talking about how it can change how your subscribe logic.
It looks like the sort of if you for example,
an if state, so you're read subscribe, you get some data,
then you read if data is true something something, then
do something something in our gest you can use the
(27:21):
filter operators for that. You can just read filter and
suppres function would be cold at all, okay, right, will
and if will look way more sort of concise, like
we'll look if you see the filter. Okay, there are
some conditions that are not allowed. Okay, you see that
immediately in subscribe may have a large function inside, and
(27:42):
if you have to go through and read these subscribe functions,
you really don't need that red filter. And the condition
is obviously after that you don't perform anything. And that
is also sort of better a bat minor bit. But
you know, if you're more or less perfection is it
would be great. So you don't need to execute five
operators and then don't do nothing in the subscribe because
(28:04):
the condition is not met. You can put filter wherever
the TATA is ready that you can check and not
allow all the other operators to work. But there's also
a nice thing to do, or people would not know
enough operators. Obviously, you can know all of the operators
too much and you don't really need most of them.
But I guess one good thing you can do is
one day when you have two all three spare hours,
(28:26):
you can open our HGS documentation website and just scroll
for operators and find stuff that is interesting. There are
also there are operators that come in sort of families,
like throt frotal times, Window the bounced time, the bounce
and so on it so you can sort of know
about them. You don't need to write examples all of them.
(28:48):
Just know that there is an operator that does the
bounce something, so in the future we'll remember that. Okay,
I've heard about some operator that might have used of
use in this case and go use it. Lots of
times people don't do that, So that's an example of
sort of misusing garages like you are using garage jazz,
and it actually provides a very nice solution to your
(29:10):
problem with one operator to a combination of two custom
sorry building operators, but you don't know about them, or
you don't sort of think too deeply enough about that
particular observable, so you don't use it and you end
up with worse code. So that's the sort of next
bad problem with our jazz in that case. So people
(29:34):
use it but don't sort of get deep enough to
really harness all the benefits that it provides. Okay, Yeah,
and then we of course arrive at the third point,
that is just using I have seen pretty horrible code
that to this day I don't understand why people opted
to do that, because what would they do is sort
(29:57):
of everything was unobservable, but in a sort of scattered way.
So the one of properties fortune that will have an event.
I don't exactly exactly remember how that logic went. There's
this chat window. It looked like Facebook Messenger, sort of
right in the pence. You have conversations on the left
and you have the nique chat window in the middle.
(30:19):
So the thing is you click on the conversation, there
is an HTP request, It loads the last twenty or
something messages and it displays. So of course you can
do it, say we didn't. We haven't been using any
state management back then with USA Gelics or something, so
you could do it in a more or less practical
(30:39):
way without our Yes, okay, you could just click handler
that will call a service low data passive with inputs
to another component and it render or something. But what
they really did was like, oh, we want to be
reactive in a way. So instead of sort of manificus
understanding how their data works, creating obdurables in almost as combining,
(31:01):
then they would just be like, okay, the here is
a subject that notifies me about the click on the butt. Essentially,
what that subject was doing was just it would emit
from the button, and it was really useless and it
made code very unreadable because now you cannot even navigate
using the ID tooling to find out, oh, well, okay,
(31:21):
this dysfunction. Next this subject who has subscribed to it.
And then in some service somewhere far away, there is
someone subscribed to it and it gets it, bloads some data,
and then passity to another subject. So you have to
sort of go through all these have events to find out, well, okay,
(31:43):
here is a service. Okay, find the data is lowly.
Oh oh my god, here's another observable, another subject. Now
this subject is passed to another service that is injected
in the other component that needs it right, and then
the other components subscribes to this. It's sort of a big,
large and unncestry chain. Subjects that are calling each other
(32:03):
syndic events. Really didn't need that that was like normal.
It really was an abuse. I cannot find that sort
of that I can describe it with. Of course, it
came from notion that people would overleak enthusiastic about or
it's just oh okay, we're going to sort of that's
why you need solutions like in JRX. The mood thing
(32:25):
about nanjrs is like, okay, if you need some data
to selected from the store, you don't have to work
with fifteen observables. There is one source of truth all
of your status incidty. You can use the reducer function
to reason about it, so you don't have a problem.
You can always follow the logic. If okay, beata is
not transformed in a way that you expected, Okay, I
(32:47):
will go debug the reducer function and that's it. Or
I will use the redax dev tools extension and just
find out, okay, after this action something changed, Okay, I
will just check the function that's a pure function, can
easily reason about it or not. But in this case
you've got the like horrible mess that it's finally, it's
(33:09):
abuse of the thing. So that's the main problem that
people face when I start doing garage yeats. Usually that's
why they either not think deeply about it, either think
too deeply about it, and in the end they would
probably get disappointed. They would think, oh, this didn't suit
me well, But the problem is they didn't use it
(33:29):
in a way that was intended.
Speaker 1 (33:30):
Right, that makes sense. I could see myself doing the
last one just trying to separate concerns and then yeah,
having stuff all over the place, so yeah, to subscribe
to this, and then yeah, just do the process, just
do the work.
Speaker 2 (33:47):
That's why actually in the or community, don't subscribe, just
don't supribe, subscribe and and like the nice things about
I actually worked on a document for the rig documentation
that they wanted to have a best practice page. There
was an open issue, submitted a draft pour because it
is in the process of work, and different community members
(34:11):
and contributors wrote in the comments what would they like
to have in the drafts that I wrote sort of
And one of the main things that was noticed this,
let's inform people that use RHS about the fact that
subscribed and composibility. And composibility is actually why we use
(34:31):
that it. When you write subscribe, you cannot use any operators, right,
it's over. You have the data to do anything with it.
It's usually in perative logic, so when you subscribe, it's
end the story. So obviously you need to subscribe. Observes
that they don't subscribe to don't do anything, but you
don't need to do it explicitly and do all that
heavy listening inside it. In Angular, we have the acent pipe,
(34:53):
and also with JRX ifuse. There is this Experimental Injuries
component that provides directives that can use. There's the nguritic
less directive. It's very nice thing. You can just extract
the observable result to a variable local variable template and
use it. It's better than writing ngief as something to use
(35:14):
it without the acting right. It's a very nice thing.
I use it in my project a lot. So you
really don't subscribe menus the proof. After that, you just
use the value. Okay, you need to value in the template.
If you're writing angular, you don't need the state for
the sake of the state. You mean something to deplay
in the UI. If something is never displayed in the UI,
you probably don't need that either display that exact state
(35:38):
in the UI or some result of that state, something
that happens because you have a state like this so
rapidly and observable, take it, use the acting pipe and
it's over. There is only one case that is I
sort of allow people to subscribe in our projects, and
we do code review. We always try to follow the
rule and not subscribe manually. And the only case that
(36:00):
we allow to do that is if you're using third
part code that only has any pre imperative approach. The
best example is form controls in Angular. They have a
disabled function and enable functions. They are imperative functions. So
for example, if I have an observable of user permissions
or something, for example, if you don't have permission x,
(36:23):
this input should be disabled. So if you're using form controls,
then you will have to subscribe and see if the
permission is not there. You have to do control that
disable that imperative logy. You cannot just put it in
a template. With template driven forms, you can dig that
(36:44):
you can use the disabled attribute on the impetulment or something,
but the reactive forms don't allow for that, which is
sort of weird because reactive form are supposed to be reactive,
not imperative, which they usually are. But that's sort of
lots of perfect question. Marcustage said disabled, I don't know, disabled, enable,
and so on and so on. Most of them are
(37:06):
a bit imperative. So that's the only case that probably
if you don't you don't have a choice, or you
have a library function that does something something, you have
to call it. You cannot just write an observable. So
that's the only case that we'll all do that. That's
a nice thing to start from me. If you right subscribe,
maybe something isn't very right type to understand, how can
(37:28):
you do it better? Sort of provided like a point
of thinking, like how can I make my orges cade better?
Let's take how many sublib do I have and how
many can I pitch them? A good starting point if
you have a RGS code basically won't refractory makes sense?
Speaker 1 (37:47):
Cool? What about testing our xgs?
Speaker 2 (37:49):
That's sort of my biggest weakness is that I don't
do much testing because the requirements, yeah don't they don't.
The requirements don't from our kind, don't go into the
hunit testing or something. So most of the testing that
I have done have been like experimental. But of course,
(38:10):
if we talk in theory about testing rhes, there is
there are marble tests. And if you don't have side
effects in your are jazz. So if you don't use
the tap function, the tap operator, which is also considered
a bad practice, you don't if you only if you
really have side effects that you really really have to
(38:32):
have something like that. If you don't write the type function,
you sort of have a bunch of pure functions. Okay,
you can more or less easily test that even without
the Marble testing, just using basic humit tests. You can
do that in the very end. If you have some
properties on a class that are observable, you can just okay,
(38:55):
create an instance of that class, maybe subscribe to the observable,
see what data and how you can sort of manipulate
the source of the data, like is it coming from
an event? You can always sort of trigger that event,
can trigger that event, see how the observable goes. You
don't need to sort of test every other operator. The
operators are working, they are tested in the library. You
(39:16):
only need to test the result. They can treat it
sort of like it's just a property that I have
to subscribe to. I'm checking for the data, so triggeer
an event, see what is the data? So I guess.
It would also sort of make testing easier if you
and if you use NNGRX and testing is way way
(39:36):
easier because you sort of have to test just two things.
You have to test three things. Sorry. You have test selectors,
which usually are pure functions, so they should be pure functions,
so it's easy to test, right, just function. You have
the state you know about the state. You're the one
to providing a mocked version of state to the unit test, right,
(39:57):
so you can just check the results and it's okay.
If you get the resulted to expect it, it's okay.
It's very easy to test, and they usually don't have
very many use cases. You have to test reducers, which
also again reducer pure function. Provide the action the payload,
get the result it's expected. Okay, it's done. You don't
(40:17):
have to There are not lots of different cases and
other global variables that can affect the reduce the pure
function test. The only thing that's probably less to test
is the effects, but that's really the main point. If
you have effects in gy X, that's the only place
that you have effects. So if you get that covered,
(40:39):
most of the services you have you pro in the action,
see if the resulting action comes with the payload that
you've expected. So it's sort of the same. It's sort
of the same thing that you actually be with the reducer.
It's just not a pure function. It does something on
the side like calling a server or maybe go to
(40:59):
local storage or something. But you don't have to Again,
you don't have to test that because there's another service
doing it. You have you have you have a unit
test for bed service. Like for practical examples, say you
have an orders service that loads orders. Okay, the data,
and you have the order effects. They don't really need
to test order service in the order effect test. You
(41:22):
will just test if there is an action called load orders. Okay,
here's the action with this payload, and I expect this result.
I expect this action with this result. So you don't
really care what happens inside it, even if it does
some complicated logy. You don't care care about the results.
You can sort of sort of treated like a quasi
(41:44):
pure functioning. It isn't obviously, but because you have mocked
the service, it will always return the result that you
have expected if you if you have written the correct
code in the effects, that's what you're testing for, right,
And then you will test the order service separately, which
actually would be just marking the back end with I
(42:06):
don't know, mock et cetera backhand or something something or
the HTP testing library in Angular testing, so testing the
othersies would also be busy. So essentially you get two
interconnected classes that are both one hundred percent test covered
and that really made your job easier. If you have
been doing all of that in the component, then that
(42:27):
component uned hasn't really big. You will have to mock
the service and put it Okay, oh, this component uses
five or seven services for example, you have to make
all of them, put them inside this component, and then
check for it in every way, like oh, this boton
is clicked. This function is called this service. Server function
is called mog. Data is here. It's rendered something something
(42:48):
and GRX saves you from that too. In your components,
you usually only ir component is that's a bit smaller
and uses only external state. You inject only the store.
Inject the store. There's one. You don't need to mock
the story. Don't mock the story and JR ex test.
You moke the selectors. And it's very easy to make
a selector because essentially just say, oh, this is the
(43:10):
data this selector is going to return, and that's it,
right the elector function like, okay, I haven't the orders
property that I already use in the component. Okay, I
mock the selector and I'm like, now there are three orders.
Now I'm mog, now there are five order orders. Let's
see what happened in the ui IL eight words. It's
(43:30):
really easier to do that then to try to mow
you don't mock the dependency rather just moke the data
with the selector functions.
Speaker 1 (43:38):
Right, yeah, that makes sense. All right, let's see. Is
there anything else that we should cover? I guess The
next question I have is if people want to follow you,
because you have a thousand followers on Medium. Now, if
people want to make it one thousand and one, I guess,
then go on Medium and find you there. And then
I'm also wondering about like Twitter and GitHub and anywhere
else that you want people to follow you at you.
Speaker 2 (44:00):
I usually want people to follow me on Twitter because
I usually i'll post stuff there because if I remember correct,
you cannot follow alter on in depth. I think we
don't have the functionality there, so but I always post
my articles and some other folks on Twitter. So I
guess follow me on Twitter.
Speaker 1 (44:19):
Okay, what's your Twitter handle?
Speaker 2 (44:21):
It's Armando true.
Speaker 1 (44:23):
All right, Well, we'll make sure that we have a
link to that in the show notes. If you just
put in the chat put it over there.
Speaker 2 (44:29):
Yeah, yeah, okay, And then.
Speaker 1 (44:32):
The last thing that we do on the show is
Picks and Picks is just us shouting out about stuff
that we like, stuff that is making life better and
more enjoyable or whatever. Right, So I'll go ahead and
go first, just to get things rolling. So I've been
listening to and I have to say, I'm really slow
on the fiction books just because I don't have a
(44:52):
ton of time. But I've really been enjoying these books.
I'm listening through them for the third or fourth time.
I listened through the books whenever a new one comes out,
and a new one came out last year. And yes,
I'm slow, Yes the book came out last year. But
I've been listening to The Stormlight Archives by Brandon Sanderson.
And for those of you who aren't familiar with it,
(45:12):
it's a fictional series. It's a fantasy series. It takes
place on another world where how do I talk about
it without spoiling it anyway, they have these powers where
they essentially can channel light that Okay, I'll explain a
little bit of it, but I'm not going to take
too long because I don't want to take too long.
But effectively, so there's this there's storms that come through
(45:36):
the you know, on a regular basis, and when the
storms come through, they infuse gems with light. They call
it storm light, and then there are certain people that
can take that storm light and use it to do magic.
And anyway, the thing though with Brandon Sanderson's books is
the magic systems are interesting, but the characters and the
(45:59):
storylines are way more interesting. And to me at least,
that's the thing that I really love about a lot
of the movies and books that I enjoy are kind
of those things. Right. That's why a lot of people
really enjoyed the original Star Wars trilogy, right, is because
the characters were rich, It followed the hero's journey. It
(46:21):
you know, yes, I'm kind of a story writing nerd,
but anyway, so it followed some of the formulas that
we're familiar with, and you know, we really really love
the characters. And it's interesting because I talk to people
about some of the later Star Wars series, you know,
whether it be the prequels, you know, episodes one, two,
and three, and people were just like they just weren't
(46:42):
as good. And I don't know why, right, because the
special effects were better than everything else, and it's because
the characters weren't as interesting, right, You kind of knew
who Obi Wan Kenobi was going to end up being,
and he got a little more interesting as he started
pushing back in some ways against you know, some of
the other Masters. But you know, Anakin was just this
(47:03):
whiny kid through the whole thing, and he just wasn't
that interesting to watch, right, There was no progression for
the character. You know, the same with Padme, you know,
she was just always you know, she struggled with their
decision to be with Anakin, but that was pretty much it,
right or the new series even you know, where you
don't see the same internal struggles that you saw from
(47:23):
Luke and Leah and Hahn and the struggles with who
they were from Ray or Finn or any of those characters, right,
And that's what we wanted to see. And in fact,
they actually undid some of the growth that you saw
from Luke in the original series when they brought him back,
and a lot of people had issues with that. And
so anyway, Brandon does a really good job with his
(47:46):
characters in the way that he puts them together and
then some of the situations that they find themselves in
and you know, trying to make their way through this
universe and all of his well, I shouldn't say a
A lot of his books take place in the same universe,
which he calls the Kosmeir, and so that's always fun too,
because you're wondering at what point they're going to start
(48:06):
meeting each other, right, because there are ways for them
to travel between the worlds, and none of his books
have done that yet with more than like a handful
of characters. There are a few characters that move between worlds,
and you do meet them as you move through the worlds.
The storm Light Archives actually has one character that you've
seen in several of the books, but he kind of
has this passing role, and in this book, in the
(48:29):
first Stormlight Archives book, he's actually almost a main character.
So that was fun. But anyway, I'm nerding out and
I need to just get off the bandwagon here for
a minute. I really enjoyed the book, so go check
those out. The first book is The Way of Kings.
The second book is Words of Radiance, and that's the
(48:49):
one I'm listening to right now, and so go check
those out. I'll put a link to those in the
show notes. I listened to him on audible, so I'll
put a link to audible as well. And then the
other pick that I have is the dev Influencers Accelerator.
I'm just going to keep reminding people that is out there. Basically,
the idea is that if you're trying to get your
career to go to the next level, and you want
(49:10):
to make an impact on the community while you do it,
and eventually you'd like to get paid for it, then
the dev Influencers Accelerator is for you. And basically what
we're doing is we're walking you through the process of
starting a hit podcast and then we're gonna take you
from producing the podcast and having a podcast that is
going out every week to growing it rapidly and I
(49:32):
think I can get people to be in the top
five podcasts in their niche within six months. So if
that sounds interesting to you, then come join us. You
can go check it out at dev influencers dot com
slash apply. Also, I did start a dev Influencers podcast
and that's at dev influencers dot com slash podcast. All right, Arman,
(49:53):
what are your picks?
Speaker 2 (49:55):
When we were talking about the books that you have
been listening to, I kind of topic to sort of
build on because I like both fantasy and science fiction
a lot. I like Star Wars if you were going
to talk about stars or wear a Star Wars T shirt.
Speaker 1 (50:14):
Yeah, yeah, so Andrew.
Speaker 2 (50:17):
The thing that gets me excited about the topic is
waiting for the Dune movies to come out. Oh yeah,
because I'm a huge I'm a huge fan of the books,
and I actually regret now.
Speaker 1 (50:30):
Ever read the book.
Speaker 2 (50:31):
They are amazing for me. They're the best thing in
science fiction and probably most of the literature that I
ever read, and I regret not reading it earlier. Because
Danny Vignov is my favorite movie director. I absolutely enjoy
all the movies that he created a later later on
(50:51):
twenty forty nine and Arrival and all the other stuff
that he had. So when I and I always have
known about Dune that it's a classic, that's a great book,
but I was like, maybe I will read something. But
when I realized.
Speaker 1 (51:05):
I've seen the movie, the nineteen eighties movie.
Speaker 2 (51:08):
Oh no, I didn't watch it. I didn't watch it.
So I so when I watched the Milliaum movie that
will eventually, hope fully come out, I will have only
those impressions, so I won't sort of think about the
Lynch movie. I have seen several clips from the Lynch movie.
The actuals are really good, but it's sort of a
bit cheesy, and I know how we changed the ending
(51:28):
that isn't really reflecting what Frank Herbert was trying to
convey in the books. And Willow is always saying in
his interviews that, no, I'm going to sort of try
to convey what the author originally intended rather than sort
of come up with my interpretations or something something, because
it's apparently a big fan of Frank Herbert. So when
(51:51):
I learned when that Danny Vignow is making new movie,
I was excited. I was like, Okay, I'm gonna read
that it's the first book so that when I go
to the movie, I would sort of know what to
try to expect, because for me, it's I always loved
the experience of watching a movie on a book that
I like. I enjoyed watching the Hardpwter movies because I
(52:12):
like the books, and when I went went to the movies,
I enjoyed how they sort of brought all that stuff
to the screen. But when I was reading the Dumb books,
I was sort of blown away, but not from the start,
because from the start, and that's a mistakes make you
think that it's sort of this hero journey. It's sort
(52:33):
of like Star Wars, like there's this guy who has
this problem was to go through these adventures and then
come out on top. But in reality it's a sort
of dystopia. Did you find out about only if you
keep on reading the other books, If you just read Doom,
it's again a great piece of literature. It's sort of
(52:54):
it's very big. It's it's a classic. It has great characters,
it has great philosophy in it. But this sort of
end up with like, yeah, this is big, but sort
of in the end is just a hero journey. But
then if you keep on reading, if you read at
least Dune Messiah, which to everyone that wants to read
Dum books, I always suggest that they read at least
(53:16):
Dune and Dune Messiah, the second book, because originally Herbert
intended to release one book that is both Doing and
Dune Messiah, but it got too long, so the publication
asked him to try to sort of put it in half.
So the other part of life, I'm trying not to
spoil anything of my protagonist is in the other book.
(53:39):
And when you read the other book, you sort of
one said, Okay, this really is something different. This really
is rather than being a hero journey a sort of trope,
it's it actually criticizes the trope and tries to make
reader to understand that, yeah, you know that stuff. It
only works in works of fiction. In real life, hero
(54:01):
trope is not the good, great and exciting thing that
you think about, because the hero can easily manipulate you
to do horrible things. And it goes on and has
this motive, and it's sort of a tragedy that goes
through the family, that goes through all of that, and
it sort of comes back in Children of Dune, which
is my favorite. The first book is one hundrederson my
(54:23):
favorite thing the ones that I've read. I've read up
to God Improved Dune, the fourth book, and after that
you sort of take a break and the other events
happened too far in the future with new characters but
still being interconnected with the sort of the journey that
happens before that. So I didn't really enjoy very much
the characters in Heretics of Dune because the plot was
(54:46):
very interesting, it got really exciting things, but I sort
of didn't manage to like the characters or emphasize with them.
So I stopped somewhere in the middle. I'm still going
to finish it, hopefully before the movies amount. I want
to have written all the six books before the movie
comes out, but I guess I still have time for that.
(55:09):
So that is something that I really enjoy the dum books,
and I would advise anyone to read them because they
really they contain sort of advice about anything in the world.
That that book is about politics, that book is about religion,
and that book is about philosophy and knowledge and even ecology.
So it sort of covers everything that we have problematic
(55:32):
in our world, that everything that raises any conflict in
our world. So it's a nice, nice, large, big piece
of different thoughts and opinions inside those characters that interact
with each other. And I guess it's really great read.
Speaker 1 (55:48):
Interesting. Well, I haven't seen the nineteen eighties movies for
a long time, so yeah, I'll have to go read
the books. Now you've sold me. I've got a ton
of credits on Amazon or as well. So yeah, I'm
kind of curious because I'm wondering if they're like super
long books.
Speaker 2 (56:06):
They kind of are, but they are a bit confusing
in the beginning because Frank Herbert really doesn't like exposition.
He will throw on like this terminology or the benega
his sisterhood, and you would what the hell that is?
And okay, yes, sort of I get it. Ah, yeah,
maybe something. And then they were like, oh this is
(56:28):
gon jaba or oh this is something this, this is
the Sensimi religion, and lots of terminology. But when you
sort of get the grasp of it, it becomes really exciting.
So you have to pay very deep attention to the
dialogues because everything like expositionary happens in the dialogues.
Speaker 1 (56:45):
Yeah, yep, it's one credit on audible, so I just
you cost me a whole credit.
Speaker 2 (56:52):
So I hope you really enjoyed the book.
Speaker 1 (56:54):
Yeah, me too. All right, good deal. Well, thanks for coming.
This was fun.
Speaker 2 (56:58):
Thanks for inviting me. I enjoyed a lot to talk about.
Top day.
Speaker 1 (57:02):
All right, we'll go ahead and wrap up here and
until next time, folks, max out.
Hey everybody, and welcome to another episode of Adventures in Angler.
I'm your host today, Charles Maxwood, and we are talking
to Arman. I love getting people from other countries because
I'm looking at the name and going, let me, let
me try it. It's Vardanian.
Speaker 2 (00:20):
Yeah, you've got it mostly right. I mean your words
usually are pronounced that they are written.
Speaker 1 (00:29):
Yeah. Cool. So do you want to just tell us
a little about yourself what you do over there in
Armenia and yeah, how long have you been doing Angular
and all that good stuff?
Speaker 2 (00:38):
Yeah? Sure. So I'm a senior front and developer at
an Armenian company called Wolo. I'm in sitting in our
office right now. I'm a conference room. I'm a front
and tim lead, and I'm working on Angular for I
think it's the fourth year that I'm working on Angular already.
(01:01):
So we started one of our projects back when Angular
two was in beta. Uh huh, I guess I've been
there from the start.
Speaker 1 (01:11):
Oh wow, Yeah, I remember those days that all the
anxiety around, you know, all the stuff that was changing.
Speaker 2 (01:18):
It was it was sort of you were in constant
danger that something that you are doing today is going
to change tomorrow, and you have to prefecture some of
your code again.
Speaker 1 (01:30):
Yeah, but we're in a good place now. I'm kind
of curious as we get started. I mean, we don't
often hear a whole lot from Armenia, I guess in
the Angular community. So what does the development and regular
community look like out there?
Speaker 2 (01:46):
So Armenia has this problem with our developers that don't
really participate a lot in the community, I mean in
in a global sense, But we actually have lots of
very good software and in Angular too. So the most
biggest part of the market is React, but there are
(02:07):
also also big companies here that use Angular and concentrate
on Angular. And as a matter of fact, I'm also
teaching Angular in a private coding school. It's kind of
like a Blong boot camp. Of course, there are not
as many people enrolled in that program as there are
(02:29):
people in the React program, but we still have enough
demand for Angler developers to keep it going.
Speaker 1 (02:37):
Yeah, that makes sense.
Speaker 2 (02:39):
More usually the larger companies that use Angular.
Speaker 1 (02:42):
Oh really, that's interesting because I've seen a bunch of
larger companies using React. I've seen I've seen kind of
all across the board, I guess for all kinds. But
I talk to people across the board.
Speaker 2 (02:55):
So there are also companies that you've kind of both
on a halfferent projects. For example, one company probably know about,
you know, Pixard right the right, but that's an Armenian company,
and I know that they use both Angular and oh yeah,
(03:16):
as a matter of fact, they have reached out to
me to you know, try to hire me into their
Angular program. I didn't want to, but that's how I
learned that they actually are doing Angular. I always thought
that in and there were web projects they're using going
to react, I know that they were using correct. It
turned out they also had projects in Angular different products,
(03:36):
so probably.
Speaker 1 (03:38):
Yeah, that makes sense. I'm kind of curious as we
get into this, how did you get into Angular's.
Speaker 2 (03:43):
That's sort of an interesting story is that at the
very beginning, I was a PHP developer. So the very
first job I got, which we started this day exactly
five years ago, that was my very first working day,
so and I was hired as a PHP developer. But
(04:04):
the very first day they told me that they really
needed a Python developer. So they asked if I could
try to, you know, learn some basics quickly and try
to do some features. And I was sure, Okay, I've
already hired, so I don't have really option. So I
spent like four days doing some Python and started doing backhand.
(04:27):
But they're working on a project that there were pieces
written in Angular jas in twenty sixteen. Within the beginnings
ty sixteen, we didn't really have Angular one up and running.
So I started doing doing Angular Jazz and it sort
of became a parent that it's more interesting for me.
So when they got a project that they were going
(04:48):
to write from scratch, they decided to create a single
page application on Angler Jazz and all of that, and
I started doing it. So I got I pitched backhand
and started doing only front and then I Angular Jazz.
Then I switched to my current office and they were
also starting in new projects from scratch and they were
already doing it Angular in Angular two, which was in
(05:11):
I guess I was in beta yet. Yeah, so that's
how I got into Angular and awesome, he's been wrong
round but I still enjoyed.
Speaker 1 (05:22):
Yeah. Yeah, it's it's it's fun stuff. I mean, I
kind of dabble in all of them, and it's it's
interesting to see the different approaches but also see the
things that they have in common. So yeah, good deal.
So you've been writing I think I found like two
or three articles where you wrote about r xjs or
you know, some kind of reactive code. I'm a little
(05:44):
curious as we get into this, what what was it
that drove you to start writing about rxjas in particular?
I mean, rxs is kind of core to the way
the angular works. But for the most part, I find
that I can kind of not pay a whole lot
of attention to do what RCGS is doing and just
kind of do things the angular way and it mostly works.
(06:04):
And then I just kind of know in my head
that it's RCGS is doing every thing well.
Speaker 2 (06:09):
For me, it was sort of work experiencing that I
was working on a project that had lots of interconnected logic.
So in a sense, imagine like this is UI that
I have like a drop down, I have another drop down,
and the values in this drop down depend on what
I selected the other drop down, and everything that I
(06:31):
selecting those two dropdowns depend on some permissions that come
from back and like can I do this, can I
do that? And everything is very mixed. So at first
I was trying to keep track of all that stuff
in an imperative way, like like I said, the angular
ways around methods. So when on select this thing, round
(06:52):
this function which will go update the internal state and
so on. But it quickly got out of hands because
I ended up trying to synchronize five or six different
states with each other so that updates the other has
to update. And it was all inside one component. I
couldn't even there were scientor connected. I couldn't even divide
(07:14):
it several components to try to write sort of make
them communicate with each other. So for the next piece,
I decided, I will try to do it in an
RHS way. I will try to create sort of observables
for all the stuff and use operators and functions like
combinlatest or relatest from and so on too, and I
will use the acin pipe to just just derive the
(07:37):
state sort of from observables that I already have and
put them directly into the template using the acin functions,
no subscribes, And it worked way more elegantly that anything
that I was trying to do before that. And I
always enjoyed RGS, but I was in the camp of
the people that would say, oh, no, you're using too
(07:58):
much rgs, this is over engine and so on. I
always felt like, oh, why did this guy put I
don't know this logic inside and observable. Don't really need
an observable, you just use just use an impertive function.
But after doing it, I kind of got the notion
behind it that I can view my derived data in
(08:20):
the end as a combination of different streams and operators
applied to them to mop and find my finals. Said
that I wouldn't going to display to the end user,
and that was a very elegant thing. So I started
sort of investigating inside my project before starting to read
what other people write about are just because of course,
(08:41):
you can find lots of articles and create literature online
on how our jets may benefit their application. And so
I started investigating my own application pite fund at Oh again,
Oh I find this function. I don't need this function.
I can reach it. I can put it inside single
property that's unobservable and use it operator and so on
(09:02):
and so on. I started sort of writing down pieces
of rules that I will try to follow, and lots
of those rules will actually stupid rules. I was sort
of finding out. I was sort of finding out what
I have to do with trial and their trial and
there and then one day I was like, okay, let's
just try to read about more about RGS. Just opened
(09:24):
documentation that started trying different operators, and my project transformed.
I sort of got way better code than I thought. Yeah,
this is this is this is good. I'm going to
write an article about it. Because every time that I
sort of go from experience with a new library, a
new design pattern, or some a new approach, the best
(09:46):
way for me to finally digest what I learned is
to try to communicate my new knowledge to others. So
when I sort of when I teach, I also learned.
That's two way thing for me. I always read an
article about anything new that I've done, and then it
got rolling. So I got three articles on RGS and Angular.
(10:08):
I got an article on Unexpected Things in RGAS. I
wrote an article on best practices in our yas. I
guess I have six or seven articles on rys.
Speaker 1 (10:17):
Nice and I think I saw some of them on
Angular in Depth. Is that where they're all posted or
just some of I.
Speaker 2 (10:23):
Guess one or two of them have been posted on medium.
Then in Depth moved from moved from medium, they stopped
posting on their blog. There the only posted on the
website and in the in that community. So first I
was hoping that stuff to Medium, but then I also stopped.
I don't actually visit Medium. I opened Medium like a
(10:46):
week ago and was terrified to find out actually one
thousand followers. I didn't know. I didn't know I did
many followers on Medium. You're popular follow and I didn't
know about it because like for four or five months,
I didn't even open stopped reading their photo alter got
involved with the in depth.
Speaker 1 (11:05):
Yeah, I didn't know I was talking to celebrity. Wow,
So there you go. Got to start somewhere, right, Yeah.
So yeah, I just I find this really fascinating and
it's it's interesting too because I was I was working
on an app myself where we were building like a
(11:27):
sign up wizard, and yeah, we kind of put I mean,
we were doing and react, but we were putting a
whole bunch of stuff in you know, basically a higher
order funk or a higher order component, right that had
a whole bunch of components up underneath it so we
could maintain all the state underneath it. And yeah, like
(11:48):
maintaining all of the different events that were going on
in it and reacting to those. It was, yeah, just
doing it kind of the react way, or I was
trying to think of how to do it neither, and
we probably would have approached it much the same way,
and you know, done things the angular way. I realized that, yeah,
there were a lot of events that we would have
been emitting that yeah, something like our xgs. I didn't
(12:10):
even think about it, And I'm just going I feel
kind of silly now because yeah, it would have been
so much easier to just approach it with our XGS
and just say, okay, if any of these things happen
right then amid an event, and if any of these
things happened amid an event, and then yeah, if we
come back around any of this stuff, then you know
or subscribe to those events and we just know what
(12:31):
to do.
Speaker 2 (12:32):
So yeah, the same sort of revelation I went through
when I would find to reflector alls of stuff. Nowadays,
when I start anything new and the team I'm working
in as sort of receive new projects all along from
the client, so U we'll just received something that'll probably
have to wat from scratch using stuff that you already have.
(12:55):
So the next thing we got I was like, yeah,
but we're going to vangel X. We're going to we're
going to use ARGs a lot. My next stop is
trying to reflector and move away from using internal states
at all. Like I'm going to use the ANJX component
store for all the internal interactions and use ang x
(13:17):
for everything community between the components. It's more sort of
an experiment. I'm not sure that that's a good idea.
I will, I will try to do it, and I
guess it might be a good idea because but I can.
I can now ditch normal change detection. I can use
on pushing all the components. Because I'm only having observables
an acing pipe, I don't have to use normal change detection.
(13:40):
I can default to on push. That's a nice thing
to have. And also I will sort of that will
solve the problem that if you're like, oh am I
going to create an observable byhand for everything, No, you
can just you know, use the store class and start
from it right store ter selectors put them in the
components so it can be it can exist in parallel
(14:03):
with your component, and you will see all the transformations
of the store with the updata functions and so on,
just putting their use this in PIPEM and so on
and so on, and I think that might be nice.
So I'm sort of going to write a proof of
concept or something like it. Can we can we ditch
local internal class based states and just use or jest.
Speaker 1 (14:24):
Yeah, yeah, I'm kind of curious to see how that
would work out. To be perfectly honest, I haven't done
a whole lot with r xs or EDGRX, so yeah,
it'll be interesting to see how it all comes together.
So what what is kind of the biggest thing or
the biggest problem you found r X chess songs within
your your app.
Speaker 2 (14:45):
Oh well, well all starts again. The biggest sort of
benefit that you get from it is removing imparative logic
number one benefit and not having to synchronize two different states.
So my biggest problem always was that I have sort
(15:08):
of these two pieces of data that are interconnected. But
it's not that like one is derived from the other
or something, but more like the change in this one
can trigger a change in this one in a way
if there is some condition or something something, and that
is really like obviously apparent in large applications like enterprise
aps when you have different configurations, personal user settings that
(15:31):
can affect the UI and customized things and so on
and so on and so on. And when you switch
to RCJZ, you sort of, even unwillingly, you have this
single source of truth, so you don't have to check
three or four places to see how your state is transformed.
(15:51):
If there is sort of you have this small dependency
like you have an engine model binding, or you have
a component and you passing an input and you use
the acing pipes, or apparently this is an observable. If
you go to that observable, you immediately know what can
happen to it. You see, this is the observable. Oh,
this is the stream. This begins here, these operators are
(16:14):
used on it, so and that's the end. So you
don't have to look anywhere because it's an observable. No
one can modify it from somewhere else. This is what
you have. This is always what you have. If there's
a problem, it's in these five lines of code or
anything you have written. So if you really use that,
well it's easy to read, it's easy to find stuff
in your code. You don't get sort of oh, h okay,
(16:38):
I have this array. Let's let's just control app see
whoever has updated, or let's right click and file references
and stuff like. You know you don't have. This is
apparently everything you have. And that's a it's a big
thing because then you will always have bugs. And obviously
most of your work then would be try to find
(17:00):
where the bug is coming from, because usually when we
find in like eighty percent of cases, if we find
where the bug is sort of located, we usually easily
fix that, right, So finding is sometimes as a problem
understanding exactlyly piece of code effect. So if we have
only one piece of code that is affecting anything, so
it's very easy. Okay, I have five operators, one of
(17:22):
them is doing something wrong. Let's find out what is
in the five lines of code. That for me is
the biggest benefit because in imperative logic you always have
to sort of dive into ti times say oh, why
do we have a loop here? Oh this is all Okay,
this is array, push something into ray, get something from array,
and sort of go going gone, And that can become overwhelming,
(17:45):
especially if the logic is large.
Speaker 1 (17:48):
Yeah that makes sense, I mean, yeah, you subscribe to
a stream and then yeah, everything that happens downstream from that, Yeah,
nobody's modifying the array. It emits another stream or another
array effectively, and so it's easy to follow. I guess
the other question that I have, just kind of talking
through your story here and talking through the you know,
(18:09):
the situation where you, you know, you move kind of
outside of the internal state management with angular and into observables,
was at what point do you feel like that makes sense?
I mean, should you just do that from the get
go or do you wait till your app gets to
a certain complexity before you start using RxJS as as
(18:30):
this kind of Yeah.
Speaker 2 (18:31):
That's actually a very good question because for a lots
of people usually that exact question is the sort of
obstacle that usually either don't have enough time to think
about it, or just don't want to recolector too much,
or don't want to sort of overengineer like people have said, Oh,
(18:56):
maybe I'm blowing these out of proportions and I don't
need these whole lot of stuff, may be even doing
just a regular way.
Speaker 1 (19:04):
Yeah, my answer to that is usually try it and
then you know, right, yes, sort.
Speaker 2 (19:08):
Of yeah, But of course, obviously in the real world,
lots of people that won't have enough time to do that.
Like this project, you have this deadline, you have to
do something, and you're not sure. Maybe if I try
to do this, this is something you maybe we won't
have time. And of course some people say, oh, my
application is small, I don't need something like that. I
was saying that in the context of angio X, but
(19:29):
I said something on Twitter like six months ago or
something that lots of people sort of agreed with. It
went like this, if you have an application that is
large enough that you write it in Angular, then you
have an application that is large enough that you can
use angio x. The same for me applies to ourggs.
(19:50):
It may sound a bit radical, like maybe not some
people say this small thing, or if if it's so small,
if you say it's sort of a two pages, why
do you need this behmit of a framework that Angular
is like, it's big, it has lots of things, there's
lots of feature you can write it in something easier
if you. Of course, obviously, if the angler is the
(20:11):
only thing that you know, that's of course normal. That's
also a situation that happens in real life. But in
most cases, usually people would know some technology they're writting
some really small but if you're acting something really big
that you already opted to use Angular because it has
lots of feature because people usually like Angular for all
(20:33):
the out of the box stuff that it provides. Angular
developers that use sometimes use React. Most of the confusion
that I can, oh, how I did stop this? We
usually in Angular we have these this, and I have
to now go on find for the party libraries to
do something, maybe write something from scratch to do that.
In React, that's what they usually find not good in
(20:56):
other frameworks, especially React, because React there is more like
sort of shell, and that's a good thing in its
own way. I personally enjoy Reacts. But the thing that
I like Angular moid is that it's more opinionated and
it has more features, so you can use this and
this and this. You don't have to think about HP
requests that you covered. You don't have to think about forms,
(21:16):
and for me, Angular forms is the best thing Angular has.
It's flawed, but for me, it's really the best like
form related library out there. It's it's very good everything
you need, so of course you opt in for Angular
for all those features. So obviously if you need lots
of features, and you have a larger enough applications, so
(21:38):
why not use ANGI X for interconnected pieces at least
you don't even need to use any write everything in ANGLICS.
There is some debate to it, but obviously the stuff
that is interconnected, the stuff that they shared stay between components,
and grex is just solve all of that for that
for you, right, so it makes sense to do that.
(21:58):
The same goes for for RGS. Ang ICs is basically
like RGS but stronger. If you can use RGS solve
some problems, it would be good, and the sooner you started,
the less problematic it would be to use that code,
because refectoring is always harder than writing code from scratch. Obviously,
(22:19):
you usually face more bugs if you refractory, because sometimes
you might look at code that you yourself even have written,
but you would misunderstand something there, and refractoring into RGS
it will lose some use case or something. So of course,
starting earlier, my advice would be, if you're beginning an
angular application, at least consider using more RHES or maybe
(22:42):
using a X. If you're going into it, at least consider.
Speaker 1 (22:45):
It right now. That makes sense. It's it's kind of
interesting though that you started out with if your app
is big enough for Angular, then it's big enough to
use RXS, Because I mean, I that is true, you know,
and I thought, okay, well, the would you use for
the smaller apps? And you know, if you things come
to mind, like you know, use HTML and CSS obviously,
(23:06):
but then you know, you pull in like a jQuery
or a stimulus or something like that that just kind
of puts stuff over the top of it, that just
kind of gets you the functionality that you need. That's
that's really really simple. Yeah, you're pulling in Angular when
you need something that's a little more that has more
depth to the experience you're creating. Yeah, that makes a
ton of sense. So what I guess the other thing
(23:28):
that I'm wondering about is, you know, now that you've
kind of gone into the deep end with r XJS,
what do you find are the things that people misunderstand
about it? Like where where do people get stuck on
RXS being a solution or get stuck on what it
can and can't do?
Speaker 2 (23:44):
Well. I had experience with lots of developers that tried rgs,
both in our team and outside, so I noticed that
there are many free problems with rs the people sort
of not right the best code that they could do,
and all of them are connected to how they use RGS.
(24:07):
So they either not use it enough, misuse it, or
plainly abusing it. Okay, So I tried to cover all
the three cases. So obviously first case not using it enough,
because there's a problem you can miss all the r egs.
People won't try to apply reactive logic to it. For that,
(24:31):
I've written my very first article and it's called the
RGS in Angular. It was the first one the three parts,
and in part one I wrote about how you can
change your imperative logic to more reactive or functional programming
style to a more declarative approach. Okay. So it involved
(24:52):
trying to understand the source of data, trying to understand
what effects the data and how it gets transformed, and
then getting the final result the result and displaying it
to in the template in the UI. So those were
the steps that you can sort of try to apply
to any problem. Like if you've got I'm going to
(25:12):
develop this feature, I can try to use the steps
to understand how can I convert it? Right? Using r JET,
you can sort of always try to do that. So
even if you don't convert something something it's large enough,
you have three factor you don't have time, you still
can like sort of process in your head. If it
won't think really much. You can try to think about
ten minutes. If you sort of understand instantly how the
(25:34):
flow of the data is, now okay, you can go
forward and just try to right or jets. People often
don't do that. I know people that know urges ats well,
they know lots of operators, how they work, some new ones,
but they just won't use them. It's like, yeah, okay,
I wrote five lines of what it works. Yeah, I
don't think the rjets for this, but really it would
look more elegant and more scalable if they did there jets,
(25:55):
even even for the five lines of So that's the
first problem, not using it enough, not sort of getting
into it and trying it to apply to all at
least mentally apply to all the problems that they try
to solve. So there's that point one, and then it
comes point to sort of misusing our ages. So how
people do misuse urages is usually what they do in
(26:15):
the first step. So a lot of some people will
come and think, Okay, I'm not using urage jes now
I want to use it more. That's a really good start,
but obviously they are going to make mistakes on the
way as all of us is done. So what would
they do is they will sort of start using observables
and not really appreciating all the all the upsides that
(26:39):
they provide, like subscribing a lot. You don't really need
to subscribe an observable like explicitly you can use the
ass pipe. So that's the first three people just teach it.
They will write subscribe and a call back with lots
of imperative logic. Then they will use they will use
features of the language instead of using operators. Like one
(27:00):
of my articles about best practices i I was sort
of talking about how it can change how your subscribe logic.
It looks like the sort of if you for example,
an if state, so you're read subscribe, you get some data,
then you read if data is true something something, then
do something something in our gest you can use the
(27:21):
filter operators for that. You can just read filter and
suppres function would be cold at all, okay, right, will
and if will look way more sort of concise, like
we'll look if you see the filter. Okay, there are
some conditions that are not allowed. Okay, you see that
immediately in subscribe may have a large function inside, and
(27:42):
if you have to go through and read these subscribe functions,
you really don't need that red filter. And the condition
is obviously after that you don't perform anything. And that
is also sort of better a bat minor bit. But
you know, if you're more or less perfection is it
would be great. So you don't need to execute five
operators and then don't do nothing in the subscribe because
(28:04):
the condition is not met. You can put filter wherever
the TATA is ready that you can check and not
allow all the other operators to work. But there's also
a nice thing to do, or people would not know
enough operators. Obviously, you can know all of the operators
too much and you don't really need most of them.
But I guess one good thing you can do is
one day when you have two all three spare hours,
(28:26):
you can open our HGS documentation website and just scroll
for operators and find stuff that is interesting. There are
also there are operators that come in sort of families,
like throt frotal times, Window the bounced time, the bounce
and so on it so you can sort of know
about them. You don't need to write examples all of them.
(28:48):
Just know that there is an operator that does the
bounce something, so in the future we'll remember that. Okay,
I've heard about some operator that might have used of
use in this case and go use it. Lots of
times people don't do that, So that's an example of
sort of misusing garages like you are using garage jazz,
and it actually provides a very nice solution to your
(29:10):
problem with one operator to a combination of two custom
sorry building operators, but you don't know about them, or
you don't sort of think too deeply enough about that
particular observable, so you don't use it and you end
up with worse code. So that's the sort of next
bad problem with our jazz in that case. So people
(29:34):
use it but don't sort of get deep enough to
really harness all the benefits that it provides. Okay, Yeah,
and then we of course arrive at the third point,
that is just using I have seen pretty horrible code
that to this day I don't understand why people opted
to do that, because what would they do is sort
(29:57):
of everything was unobservable, but in a sort of scattered way.
So the one of properties fortune that will have an event.
I don't exactly exactly remember how that logic went. There's
this chat window. It looked like Facebook Messenger, sort of
right in the pence. You have conversations on the left
and you have the nique chat window in the middle.
(30:19):
So the thing is you click on the conversation, there
is an HTP request, It loads the last twenty or
something messages and it displays. So of course you can
do it, say we didn't. We haven't been using any
state management back then with USA Gelics or something, so
you could do it in a more or less practical
(30:39):
way without our Yes, okay, you could just click handler
that will call a service low data passive with inputs
to another component and it render or something. But what
they really did was like, oh, we want to be
reactive in a way. So instead of sort of manificus
understanding how their data works, creating obdurables in almost as combining,
(31:01):
then they would just be like, okay, the here is
a subject that notifies me about the click on the butt. Essentially,
what that subject was doing was just it would emit
from the button, and it was really useless and it
made code very unreadable because now you cannot even navigate
using the ID tooling to find out, oh, well, okay,
(31:21):
this dysfunction. Next this subject who has subscribed to it.
And then in some service somewhere far away, there is
someone subscribed to it and it gets it, bloads some data,
and then passity to another subject. So you have to
sort of go through all these have events to find out, well, okay,
(31:43):
here is a service. Okay, find the data is lowly.
Oh oh my god, here's another observable, another subject. Now
this subject is passed to another service that is injected
in the other component that needs it right, and then
the other components subscribes to this. It's sort of a big,
large and unncestry chain. Subjects that are calling each other
(32:03):
syndic events. Really didn't need that that was like normal.
It really was an abuse. I cannot find that sort
of that I can describe it with. Of course, it
came from notion that people would overleak enthusiastic about or
it's just oh okay, we're going to sort of that's
why you need solutions like in JRX. The mood thing
(32:25):
about nanjrs is like, okay, if you need some data
to selected from the store, you don't have to work
with fifteen observables. There is one source of truth all
of your status incidty. You can use the reducer function
to reason about it, so you don't have a problem.
You can always follow the logic. If okay, beata is
not transformed in a way that you expected, Okay, I
(32:47):
will go debug the reducer function and that's it. Or
I will use the redax dev tools extension and just
find out, okay, after this action something changed, Okay, I
will just check the function that's a pure function, can
easily reason about it or not. But in this case
you've got the like horrible mess that it's finally, it's
(33:09):
abuse of the thing. So that's the main problem that
people face when I start doing garage yeats. Usually that's
why they either not think deeply about it, either think
too deeply about it, and in the end they would
probably get disappointed. They would think, oh, this didn't suit
me well, But the problem is they didn't use it
(33:29):
in a way that was intended.
Speaker 1 (33:30):
Right, that makes sense. I could see myself doing the
last one just trying to separate concerns and then yeah,
having stuff all over the place, so yeah, to subscribe
to this, and then yeah, just do the process, just
do the work.
Speaker 2 (33:47):
That's why actually in the or community, don't subscribe, just
don't supribe, subscribe and and like the nice things about
I actually worked on a document for the rig documentation
that they wanted to have a best practice page. There
was an open issue, submitted a draft pour because it
is in the process of work, and different community members
(34:11):
and contributors wrote in the comments what would they like
to have in the drafts that I wrote sort of
And one of the main things that was noticed this,
let's inform people that use RHS about the fact that
subscribed and composibility. And composibility is actually why we use
(34:31):
that it. When you write subscribe, you cannot use any operators, right,
it's over. You have the data to do anything with it.
It's usually in perative logic, so when you subscribe, it's
end the story. So obviously you need to subscribe. Observes
that they don't subscribe to don't do anything, but you
don't need to do it explicitly and do all that
heavy listening inside it. In Angular, we have the acent pipe,
(34:53):
and also with JRX ifuse. There is this Experimental Injuries
component that provides directives that can use. There's the nguritic
less directive. It's very nice thing. You can just extract
the observable result to a variable local variable template and
use it. It's better than writing ngief as something to use
(35:14):
it without the acting right. It's a very nice thing.
I use it in my project a lot. So you
really don't subscribe menus the proof. After that, you just
use the value. Okay, you need to value in the template.
If you're writing angular, you don't need the state for
the sake of the state. You mean something to deplay
in the UI. If something is never displayed in the UI,
you probably don't need that either display that exact state
(35:38):
in the UI or some result of that state, something
that happens because you have a state like this so
rapidly and observable, take it, use the acting pipe and
it's over. There is only one case that is I
sort of allow people to subscribe in our projects, and
we do code review. We always try to follow the
rule and not subscribe manually. And the only case that
(36:00):
we allow to do that is if you're using third
part code that only has any pre imperative approach. The
best example is form controls in Angular. They have a
disabled function and enable functions. They are imperative functions. So
for example, if I have an observable of user permissions
or something, for example, if you don't have permission x,
(36:23):
this input should be disabled. So if you're using form controls,
then you will have to subscribe and see if the
permission is not there. You have to do control that
disable that imperative logy. You cannot just put it in
a template. With template driven forms, you can dig that
(36:44):
you can use the disabled attribute on the impetulment or something,
but the reactive forms don't allow for that, which is
sort of weird because reactive form are supposed to be reactive,
not imperative, which they usually are. But that's sort of
lots of perfect question. Marcustage said disabled, I don't know, disabled, enable,
and so on and so on. Most of them are
(37:06):
a bit imperative. So that's the only case that probably
if you don't you don't have a choice, or you
have a library function that does something something, you have
to call it. You cannot just write an observable. So
that's the only case that we'll all do that. That's
a nice thing to start from me. If you right subscribe,
maybe something isn't very right type to understand, how can
(37:28):
you do it better? Sort of provided like a point
of thinking, like how can I make my orges cade better?
Let's take how many sublib do I have and how
many can I pitch them? A good starting point if
you have a RGS code basically won't refractory makes sense?
Speaker 1 (37:47):
Cool? What about testing our xgs?
Speaker 2 (37:49):
That's sort of my biggest weakness is that I don't
do much testing because the requirements, yeah don't they don't.
The requirements don't from our kind, don't go into the
hunit testing or something. So most of the testing that
I have done have been like experimental. But of course,
(38:10):
if we talk in theory about testing rhes, there is
there are marble tests. And if you don't have side
effects in your are jazz. So if you don't use
the tap function, the tap operator, which is also considered
a bad practice, you don't if you only if you
really have side effects that you really really have to
(38:32):
have something like that. If you don't write the type function,
you sort of have a bunch of pure functions. Okay,
you can more or less easily test that even without
the Marble testing, just using basic humit tests. You can
do that in the very end. If you have some
properties on a class that are observable, you can just okay,
(38:55):
create an instance of that class, maybe subscribe to the observable,
see what data and how you can sort of manipulate
the source of the data, like is it coming from
an event? You can always sort of trigger that event,
can trigger that event, see how the observable goes. You
don't need to sort of test every other operator. The
operators are working, they are tested in the library. You
(39:16):
only need to test the result. They can treat it
sort of like it's just a property that I have
to subscribe to. I'm checking for the data, so triggeer
an event, see what is the data? So I guess.
It would also sort of make testing easier if you
and if you use NNGRX and testing is way way
(39:36):
easier because you sort of have to test just two things.
You have to test three things. Sorry. You have test selectors,
which usually are pure functions, so they should be pure functions,
so it's easy to test, right, just function. You have
the state you know about the state. You're the one
to providing a mocked version of state to the unit test, right,
(39:57):
so you can just check the results and it's okay.
If you get the resulted to expect it, it's okay.
It's very easy to test, and they usually don't have
very many use cases. You have to test reducers, which
also again reducer pure function. Provide the action the payload,
get the result it's expected. Okay, it's done. You don't
(40:17):
have to There are not lots of different cases and
other global variables that can affect the reduce the pure
function test. The only thing that's probably less to test
is the effects, but that's really the main point. If
you have effects in gy X, that's the only place
that you have effects. So if you get that covered,
(40:39):
most of the services you have you pro in the action,
see if the resulting action comes with the payload that
you've expected. So it's sort of the same. It's sort
of the same thing that you actually be with the reducer.
It's just not a pure function. It does something on
the side like calling a server or maybe go to
(40:59):
local storage or something. But you don't have to Again,
you don't have to test that because there's another service
doing it. You have you have you have a unit
test for bed service. Like for practical examples, say you
have an orders service that loads orders. Okay, the data,
and you have the order effects. They don't really need
to test order service in the order effect test. You
(41:22):
will just test if there is an action called load orders. Okay,
here's the action with this payload, and I expect this result.
I expect this action with this result. So you don't
really care what happens inside it, even if it does
some complicated logy. You don't care care about the results.
You can sort of sort of treated like a quasi
(41:44):
pure functioning. It isn't obviously, but because you have mocked
the service, it will always return the result that you
have expected if you if you have written the correct
code in the effects, that's what you're testing for, right,
And then you will test the order service separately, which
actually would be just marking the back end with I
(42:06):
don't know, mock et cetera backhand or something something or
the HTP testing library in Angular testing, so testing the
othersies would also be busy. So essentially you get two
interconnected classes that are both one hundred percent test covered
and that really made your job easier. If you have
been doing all of that in the component, then that
(42:27):
component uned hasn't really big. You will have to mock
the service and put it Okay, oh, this component uses
five or seven services for example, you have to make
all of them, put them inside this component, and then
check for it in every way, like oh, this boton
is clicked. This function is called this service. Server function
is called mog. Data is here. It's rendered something something
(42:48):
and GRX saves you from that too. In your components,
you usually only ir component is that's a bit smaller
and uses only external state. You inject only the store.
Inject the store. There's one. You don't need to mock
the story. Don't mock the story and JR ex test.
You moke the selectors. And it's very easy to make
a selector because essentially just say, oh, this is the
(43:10):
data this selector is going to return, and that's it,
right the elector function like, okay, I haven't the orders
property that I already use in the component. Okay, I
mock the selector and I'm like, now there are three orders.
Now I'm mog, now there are five order orders. Let's
see what happened in the ui IL eight words. It's
(43:30):
really easier to do that then to try to mow
you don't mock the dependency rather just moke the data
with the selector functions.
Speaker 1 (43:38):
Right, yeah, that makes sense. All right, let's see. Is
there anything else that we should cover? I guess The
next question I have is if people want to follow you,
because you have a thousand followers on Medium. Now, if
people want to make it one thousand and one, I guess,
then go on Medium and find you there. And then
I'm also wondering about like Twitter and GitHub and anywhere
else that you want people to follow you at you.
Speaker 2 (44:00):
I usually want people to follow me on Twitter because
I usually i'll post stuff there because if I remember correct,
you cannot follow alter on in depth. I think we
don't have the functionality there, so but I always post
my articles and some other folks on Twitter. So I
guess follow me on Twitter.
Speaker 1 (44:19):
Okay, what's your Twitter handle?
Speaker 2 (44:21):
It's Armando true.
Speaker 1 (44:23):
All right, Well, we'll make sure that we have a
link to that in the show notes. If you just
put in the chat put it over there.
Speaker 2 (44:29):
Yeah, yeah, okay, And then.
Speaker 1 (44:32):
The last thing that we do on the show is
Picks and Picks is just us shouting out about stuff
that we like, stuff that is making life better and
more enjoyable or whatever. Right, So I'll go ahead and
go first, just to get things rolling. So I've been
listening to and I have to say, I'm really slow
on the fiction books just because I don't have a
(44:52):
ton of time. But I've really been enjoying these books.
I'm listening through them for the third or fourth time.
I listened through the books whenever a new one comes out,
and a new one came out last year. And yes,
I'm slow, Yes the book came out last year. But
I've been listening to The Stormlight Archives by Brandon Sanderson.
And for those of you who aren't familiar with it,
(45:12):
it's a fictional series. It's a fantasy series. It takes
place on another world where how do I talk about
it without spoiling it anyway, they have these powers where
they essentially can channel light that Okay, I'll explain a
little bit of it, but I'm not going to take
too long because I don't want to take too long.
But effectively, so there's this there's storms that come through
(45:36):
the you know, on a regular basis, and when the
storms come through, they infuse gems with light. They call
it storm light, and then there are certain people that
can take that storm light and use it to do magic.
And anyway, the thing though with Brandon Sanderson's books is
the magic systems are interesting, but the characters and the
(45:59):
storylines are way more interesting. And to me at least,
that's the thing that I really love about a lot
of the movies and books that I enjoy are kind
of those things. Right. That's why a lot of people
really enjoyed the original Star Wars trilogy, right, is because
the characters were rich, It followed the hero's journey. It
(46:21):
you know, yes, I'm kind of a story writing nerd,
but anyway, so it followed some of the formulas that
we're familiar with, and you know, we really really love
the characters. And it's interesting because I talk to people
about some of the later Star Wars series, you know,
whether it be the prequels, you know, episodes one, two,
and three, and people were just like they just weren't
(46:42):
as good. And I don't know why, right, because the
special effects were better than everything else, and it's because
the characters weren't as interesting, right, You kind of knew
who Obi Wan Kenobi was going to end up being,
and he got a little more interesting as he started
pushing back in some ways against you know, some of
the other Masters. But you know, Anakin was just this
(47:03):
whiny kid through the whole thing, and he just wasn't
that interesting to watch, right, There was no progression for
the character. You know, the same with Padme, you know,
she was just always you know, she struggled with their
decision to be with Anakin, but that was pretty much it,
right or the new series even you know, where you
don't see the same internal struggles that you saw from
(47:23):
Luke and Leah and Hahn and the struggles with who
they were from Ray or Finn or any of those characters, right,
And that's what we wanted to see. And in fact,
they actually undid some of the growth that you saw
from Luke in the original series when they brought him back,
and a lot of people had issues with that. And
so anyway, Brandon does a really good job with his
(47:46):
characters in the way that he puts them together and
then some of the situations that they find themselves in
and you know, trying to make their way through this
universe and all of his well, I shouldn't say a
A lot of his books take place in the same universe,
which he calls the Kosmeir, and so that's always fun too,
because you're wondering at what point they're going to start
(48:06):
meeting each other, right, because there are ways for them
to travel between the worlds, and none of his books
have done that yet with more than like a handful
of characters. There are a few characters that move between worlds,
and you do meet them as you move through the worlds.
The storm Light Archives actually has one character that you've
seen in several of the books, but he kind of
has this passing role, and in this book, in the
(48:29):
first Stormlight Archives book, he's actually almost a main character.
So that was fun. But anyway, I'm nerding out and
I need to just get off the bandwagon here for
a minute. I really enjoyed the book, so go check
those out. The first book is The Way of Kings.
The second book is Words of Radiance, and that's the
(48:49):
one I'm listening to right now, and so go check
those out. I'll put a link to those in the
show notes. I listened to him on audible, so I'll
put a link to audible as well. And then the
other pick that I have is the dev Influencers Accelerator.
I'm just going to keep reminding people that is out there. Basically,
the idea is that if you're trying to get your
career to go to the next level, and you want
(49:10):
to make an impact on the community while you do it,
and eventually you'd like to get paid for it, then
the dev Influencers Accelerator is for you. And basically what
we're doing is we're walking you through the process of
starting a hit podcast and then we're gonna take you
from producing the podcast and having a podcast that is
going out every week to growing it rapidly and I
(49:32):
think I can get people to be in the top
five podcasts in their niche within six months. So if
that sounds interesting to you, then come join us. You
can go check it out at dev influencers dot com
slash apply. Also, I did start a dev Influencers podcast
and that's at dev influencers dot com slash podcast. All right, Arman,
(49:53):
what are your picks?
Speaker 2 (49:55):
When we were talking about the books that you have
been listening to, I kind of topic to sort of
build on because I like both fantasy and science fiction
a lot. I like Star Wars if you were going
to talk about stars or wear a Star Wars T shirt.
Speaker 1 (50:14):
Yeah, yeah, so Andrew.
Speaker 2 (50:17):
The thing that gets me excited about the topic is
waiting for the Dune movies to come out. Oh yeah,
because I'm a huge I'm a huge fan of the books,
and I actually regret now.
Speaker 1 (50:30):
Ever read the book.
Speaker 2 (50:31):
They are amazing for me. They're the best thing in
science fiction and probably most of the literature that I
ever read, and I regret not reading it earlier. Because
Danny Vignov is my favorite movie director. I absolutely enjoy
all the movies that he created a later later on
(50:51):
twenty forty nine and Arrival and all the other stuff
that he had. So when I and I always have
known about Dune that it's a classic, that's a great book,
but I was like, maybe I will read something. But
when I realized.
Speaker 1 (51:05):
I've seen the movie, the nineteen eighties movie.
Speaker 2 (51:08):
Oh no, I didn't watch it. I didn't watch it.
So I so when I watched the Milliaum movie that
will eventually, hope fully come out, I will have only
those impressions, so I won't sort of think about the
Lynch movie. I have seen several clips from the Lynch movie.
The actuals are really good, but it's sort of a
bit cheesy, and I know how we changed the ending
(51:28):
that isn't really reflecting what Frank Herbert was trying to
convey in the books. And Willow is always saying in
his interviews that, no, I'm going to sort of try
to convey what the author originally intended rather than sort
of come up with my interpretations or something something, because
it's apparently a big fan of Frank Herbert. So when
(51:51):
I learned when that Danny Vignow is making new movie,
I was excited. I was like, Okay, I'm gonna read
that it's the first book so that when I go
to the movie, I would sort of know what to
try to expect, because for me, it's I always loved
the experience of watching a movie on a book that
I like. I enjoyed watching the Hardpwter movies because I
(52:12):
like the books, and when I went went to the movies,
I enjoyed how they sort of brought all that stuff
to the screen. But when I was reading the Dumb books,
I was sort of blown away, but not from the start,
because from the start, and that's a mistakes make you
think that it's sort of this hero journey. It's sort
(52:33):
of like Star Wars, like there's this guy who has
this problem was to go through these adventures and then
come out on top. But in reality it's a sort
of dystopia. Did you find out about only if you
keep on reading the other books, If you just read Doom,
it's again a great piece of literature. It's sort of
(52:54):
it's very big. It's it's a classic. It has great characters,
it has great philosophy in it. But this sort of
end up with like, yeah, this is big, but sort
of in the end is just a hero journey. But
then if you keep on reading, if you read at
least Dune Messiah, which to everyone that wants to read
Dum books, I always suggest that they read at least
(53:16):
Dune and Dune Messiah, the second book, because originally Herbert
intended to release one book that is both Doing and
Dune Messiah, but it got too long, so the publication
asked him to try to sort of put it in half.
So the other part of life, I'm trying not to
spoil anything of my protagonist is in the other book.
(53:39):
And when you read the other book, you sort of
one said, Okay, this really is something different. This really
is rather than being a hero journey a sort of trope,
it's it actually criticizes the trope and tries to make
reader to understand that, yeah, you know that stuff. It
only works in works of fiction. In real life, hero
(54:01):
trope is not the good, great and exciting thing that
you think about, because the hero can easily manipulate you
to do horrible things. And it goes on and has
this motive, and it's sort of a tragedy that goes
through the family, that goes through all of that, and
it sort of comes back in Children of Dune, which
is my favorite. The first book is one hundrederson my
(54:23):
favorite thing the ones that I've read. I've read up
to God Improved Dune, the fourth book, and after that
you sort of take a break and the other events
happened too far in the future with new characters but
still being interconnected with the sort of the journey that
happens before that. So I didn't really enjoy very much
the characters in Heretics of Dune because the plot was
(54:46):
very interesting, it got really exciting things, but I sort
of didn't manage to like the characters or emphasize with them.
So I stopped somewhere in the middle. I'm still going
to finish it, hopefully before the movies amount. I want
to have written all the six books before the movie
comes out, but I guess I still have time for that.
(55:09):
So that is something that I really enjoy the dum books,
and I would advise anyone to read them because they
really they contain sort of advice about anything in the world.
That that book is about politics, that book is about religion,
and that book is about philosophy and knowledge and even ecology.
So it sort of covers everything that we have problematic
(55:32):
in our world, that everything that raises any conflict in
our world. So it's a nice, nice, large, big piece
of different thoughts and opinions inside those characters that interact
with each other. And I guess it's really great read.
Speaker 1 (55:48):
Interesting. Well, I haven't seen the nineteen eighties movies for
a long time, so yeah, I'll have to go read
the books. Now you've sold me. I've got a ton
of credits on Amazon or as well. So yeah, I'm
kind of curious because I'm wondering if they're like super
long books.
Speaker 2 (56:06):
They kind of are, but they are a bit confusing
in the beginning because Frank Herbert really doesn't like exposition.
He will throw on like this terminology or the benega
his sisterhood, and you would what the hell that is?
And okay, yes, sort of I get it. Ah, yeah,
maybe something. And then they were like, oh this is
(56:28):
gon jaba or oh this is something this, this is
the Sensimi religion, and lots of terminology. But when you
sort of get the grasp of it, it becomes really exciting.
So you have to pay very deep attention to the
dialogues because everything like expositionary happens in the dialogues.
Speaker 1 (56:45):
Yeah, yep, it's one credit on audible, so I just
you cost me a whole credit.
Speaker 2 (56:52):
So I hope you really enjoyed the book.
Speaker 1 (56:54):
Yeah, me too. All right, good deal. Well, thanks for coming.
This was fun.
Speaker 2 (56:58):
Thanks for inviting me. I enjoyed a lot to talk about.
Top day.
Speaker 1 (57:02):
All right, we'll go ahead and wrap up here and
until next time, folks, max out.
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.