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. Yeah, you've got it
mostly right. I mean your words usually are pronounced that they are written.
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? 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
team lead, and I'm working on Angular for I think it's the for fear
that I'm working on Angular already. 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. Oh wow, Yeah, I remember those days that all
the anxiety around, you know, all the stuff that was changing. 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. 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 what
does the development and regular community look like out there? 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 to
React. But there are 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 people
in the React program, but we still have enough demand for Angler developers to
keep it going. Yeah, that makes sense. More usually the larger companies
that use Angular. 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.
So they're also company. Is that you've kind of both on Halff 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, 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, so probably, yeah, that
makes sense. I'm kind of curious as we get into this, how did
you get into Angular? That's 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
my very first working day, so and I was hired as a PHP developer.
But 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. But you're working on
a project. There were pieces written in Angular jas in twenty sixteen. Within
the beginnings twenty 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 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 go only front and the 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 I guess beta yet. Yeah, so that's how I got into
Angular and awesome, he's been wrong round but I still enjoyed. 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 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 paying a whole lot of attention
to what RCGS is doing and just kind of do things the angular way and
it mostly works. And then I just kind of know in my head that
it's RGS is doing heavy the thing. Well, 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 selecting those two dropdowns depend on some permissions that come from vacand
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 you said, the angular ways methods.
So when on select this thing, round 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 dates 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 it sveral
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 RGGS way. I will try to create sort of observables for all the
stuff and use operators and functions like com my latest or relatest from and so
on too, and I will use the acing pipe to just just derive the
state sort of from observables that I already have and put them directly into the
template using the ASIN functions, no subscribes. And it worked way more elegantly
that anything that I was trying to do before that. And I always enjoyed
RS, but I was in the camp of the people that would say,
oh, no, you're using too much orges, this is over engineering,
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 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 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 right fund. Oh again, Oh I find this function. I don't
need this function. I can reach it. I can pull it inside single
operating as an observable and use it with operators and so on 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 open
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 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 a
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. 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 urges 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
guess one or two of them have posted on Medium. Then in that 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 week ago and was terrified to find
out actually one thousand followers. I didn't know. I didn't know I had
that many flowers on Medium. You're popular, folly, and I didn't know
about it because like for four or five months I didn't given open Medium.
I also stopped reading their photo alter got involved with the in depth. Yeah,
I didn't know I was talking to celebrity wow soon, but 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 sign up
wizard, and yeah, we kind of put I mean, we were doing
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 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 in egither 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 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 to any of this stuff, then you
know or subscribe to those events and we just know what to do. 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, the team
i'm working in as sort of receive new projects all along from the client.
So we'll just reining something that'll probably have to read from scratch, using stuff
that you already have. So the next thing we got I was like,
yeah, but we're going to use ang ICs, We're going to use observables,
We're going to use rgs 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 anji x component store for all the internal interactions and use ang ICs
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 asy pipe, I don't
have to use normal change detection. 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 writer selectors put them in the component
so it can be it can exist in parallel 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 fipement, 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 that. Can we can we ditch local
internal class based states and just use or JIST. 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 EDDRX, 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? Oh well, well all start as again.
The biggest sort of benefit that you get from it is removing the imparative logic
number one benefit and not having to synchronize two different states. So my biggest
problem always was that I have sort 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 apps, when you have
different configurations, personal user settings that can affect the UI and customized things and
so on and so on and so on. And when you switch to RG
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. If there is sort of you have this small dependency, like
you have an engine model binding, or you have a component and you pass
in 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 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, 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 it's a big thing because
then you will always have bugs and obviously most of your work. Then would
we try to find 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 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 tran times say oh, why do we have a loop here? Oh
this is all Okay, this is a ray, push something into ray,
get something from array, and sort of going, and that can become overwhelming,
especially if the logic is large. 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, 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 this kind
of Yeah, that's actually a very good question because for a lot 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 reflector too much,
or don't want to sort of overengineer like. Lots of people said, oh,
maybe I'm blowing these out of proportions, Maybe I don't need this whole
lot of stuff, Maybe I'm doing just a regular way. Yeah. My
answer to that is usually try it and then you know, righty sort 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 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 rex.
The same for me applies to ourgs. It may sound a bit radical,
like maybe not some people say this small thing, or if if it's
so small, if 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 something easier if
you. Of course, obviously, if the angler is the 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 writing something really big that you already
opted to use Angular because it has lots of feature because people usually like Angular
for all the out of the box stuff that it provides. Angular developers that
use sometimes use React. Most of the confusion that is that, 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 other frameworks, especially React, because React is
more like sort of shallow, 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 or got
you covered. You don't have to think about forms. And for me,
Angular forms is the best thing Angular has. It's 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 why not use angis 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, stayed between components, and GREX was just solve all of
that for that for you, right, so it makes sense to do that.
The same goes for RGS. AnGR 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,
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
refactoring into RGS it would 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 RHGS or maybe using agi X. If you're
going into it, at least consider 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 r x Yes,
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, 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 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 on rxs being a solution or get stuck on what it can and
can't do? 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 all just the people sort of not write the best code that
they could do, and all of them are connected to how they use RGS,
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 is not using it enough because there's a problem you can miss all
with our egs, people won't try to apply reactive logic to it. For
that, 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 trying to understand
the source of data, trying to understand what the fact date and how it
gets transformed, and then getting the final result 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
develop this feature, I can try to use the steps to understand how can
I convert it right? Using rjets, you can sort of always try to
do that. So even if you don't convert something something is large enough you
have three factor you don't have time, you still can like sort of process
in your head. I won't think really much. You can try to think
about for ten minutes. If you sort of understand instantly how the 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 as well. I know lots of operators how they were 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 dre even even for the five lines. So that's the first
problem, not using it enough, not sort of getting into it and trying
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 urges is usually what
they do in the first text. So a lot of some people will come
and think, okay, I'm not using our ages 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 they provide, like subscribing a lot. You
don't really need to subscribe to an observable, like explicitly you can use the
a supply. So that's the first thing people just teach it. They will
write subscribe and a coll back with lots of imperative logic. Then they will
use that will use features of the language instead of using operators. Like in
one of my articles about best practices I I was sort of talking about how
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 filter operators for that. If
you just read filter and suppress function would be cold at all, okay,
right, will and it 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 you may have a
large function inside and if so, you said 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 bat erdd. 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 the condition is not met. You
can put filter wherever potato 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 three
spare hours, 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 frotal, frotal times, window, the bounced
time, the bounce and so on, so you can sort of know about
them. You don't need to write examples all of them. 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 operators that might have used be
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 problem
with one operator to a combination of two custom opera sorry building operators, but
you don't know about them, or you don't sort of think to enough deeply
enough about that particular observable if 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 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 arrived at the third point, that is just using Yeah,
I have seen pretty horrible code that to this day I don't understand why
people opted to do that, because would they do is sort of everything was
unobservable, but in a sort of scattered way, so they would have properties
fortune that would 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 in
the You have conversations on the left and you have the mik chat window in
the middle. 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 and GLICS or something, so
you could do it in a more or less practical way without our Yes,
okay, you could just click handler that would call a service low data passive
with inputs to another component and its grander or something. But what they really
did was like, oh, we want to be reactive in a way,
so instead of sort of and if understanding how their data works creating obsurables in
ALMOSTLMS combining, then they would just be like, okay, the here is
the 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, well, okay, 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, loads some
data, and then pass it to another subject. So you have to sort
of go through all these have events to find out, well, okay,
here is a service, Okay, find the data is lowly. Oh oh
my god, there'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 that component subscribes to this. It's sort of a big,
large and aunecessary chain of subjects that are calling each other sendic events.
You 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 not 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 good thing 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 inside
it. 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,
THEATA is not transformed in a way that you expected, Okay, I will
go deback 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 painally, it's 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 in a way that was intended. 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, subscribe to this,
and then yeah, just do the process, just do the work.
That's why actually in the urges the community, don't subscribe, just don't subpribe,
subscribe and like the nice things about I actually worked on a document for
the rig documentation that they wanted to have a best PRACTICI page. There was
an open issue, submitted a draft pour because it is in the process of
work, and different community members 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 rgs about the
fact that subscribed and composibility. And composibility is actually why we use that.
When you reade 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 and also with JRX. If
you there is this experimental injuries component that provides directives that you can use.
There's the ngurics less directive. It's very nice thing. You can just extract
the observable results to a variable local variable, new template and use it.
It's better than writing engief as something to use it without the A think 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 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 need
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 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 actin pipe and it's
over. There is only one case that is I sort of allow people to
subscribe in our projects. When we do code review, we always try to
follow the rule and not subscribe manually. And the only case that we allow
to do that is if you're using third party code that only has an 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, 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 loogy.
You cannot just put it in a template. With template driven forms, you
can't dig that. You can use the disabled attribute on the impetlment or something,
but the reactive forms don't allow for that, which is sort of weird
because reacting forms reactive not imperative, which they usually are. But that's sort
of have lots of imperative questions. Marquesstage said, disabled, I don't know,
disabled, enable, and so on and so on. Lot most of
them are a bit imperative. So that's the only case that probably sort.
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're right, subscribe, maybe
something isn't fair right, try to understand how can do it better? Sort
of provided like a point of thinking, like how can I make myge Orgies
cade better? Let's take how many subscribes do I have and how many can
I pitch them? A good starting point. If you have a RGS code
basically want to refractory it makes sense. Cool. What about testing r XGS.
That's sort of my biggest weakness is that I don't do much testing because
the requirements, yeah don't they don't. Requirements don't from our clients, don't
go into the unit testing or something. So most of the testing that I
have done have been like experimental. But of course, 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 tape 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 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 unit tests.
You can do that in the very end. If you have some properties
on a class that are observable, you can just okay, create a new
and of that class, maybe subscribe to the observable. See what data comes,
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.
They 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 only need to test the result. You can
treat it sort of like it's just a property that I have to subscribe to.
I'm checking for the data, so trigger an event. See what is
the data? So I guess. It would also sort of make testing easier
if you and if you use NGRX, and testing is way way easier because
you sort of have to test just two things. You have to test three
things. Sorry, you have to selectors, which usually are pure functions,
so they should be pure functions, so it's easy to test, right,
It's just functions. You have the state. You know about the state.
You're the one providing a mocked version of state to the unit test, so
you can just check the results and it's okay. If you get the results
to expect it, it's okay, 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 better payload, get the results it's
expected. Okay, it's done. You don't 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 is probably less you 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, most of the services you have, you throw 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 with
the reducer. It's just not a pure function. It does something on the
side like calling a server or maybe go to 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 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 logic. You don't care care about the results.
You can sort of sort of treated like quasi pure function. It isn't obviously,
but because you have mocked the service, it will always return the result
that you've expected if you if you have written the correct code in the effect
that that's what you're testing for. And then you will test the order service
separately, which actually would be just marking the back end with I don't know,
mock et cetera backhand or something something, but the HTP testing library in
Angular testing, so testing galxies 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 component you need test would be 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.
Several function is called mock. Data is here. It's rendered something something and
GRX saves you from that too. In in your components, you usually only
if component is that's a bit small and uses only external state, inject only
the store. Inject the store. There's one. You don't need to mock
the story. Don't mock the story. Jr X test. You move the
selectors, and it's very easy to make a selector because essentially just say,
oh, this is the data that 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 U I L eight
words. It's 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. 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. Yeah. I usually want people to follow me on Twitter because
I usually that'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. Okay, what's your Twitter handle? It's Armando
true. 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. Yeah, yeah, okay, And then 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 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, 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 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 book is the magic systems are interesting, but the characters and the
storylines and stuff 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 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 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 Jedi
Masters. But you know, Anakin was just this 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 her 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 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 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 all. 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 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 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, you know, 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 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 them 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 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 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, what are your when When we were talking about the books that you
have been listening to, I kind of got a nice 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 web a Star
Wars T shirt. Yeah, yeah, so Andrew. 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 you ever read the book. 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 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 I've seen the movie,
the nineteen eighties movie, oh no, I didn't watch it. I
didn't watch it. So I so when I watched the millium movie that will
eventually hopefully come out, I will have only those depressions, so I won't
sort of think about the lynch movie. I haven't 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 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
I learned when that Danny vignov is dem movie, I was excited. I
was like, Okay, I'm gonna read that this the first book so that
when I go to the movie, I would sort of know what to try
to explain, because for me, it's I always loved the experience of watching
a movie on a book that I like. I enjoyed watching the Hardworter movies
because I 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 dum 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 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 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 Dune and Dune Messiah
the second. But 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. And when you read the other book you sort of once 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 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 that 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
favorite in 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 very
interesting, it got really exciting things, but I sort of didn't manage to
like the characters or emphasize with them. I stopped somewhere in the middle.
I'm still going to finish it, hopefully before the movies come out. I
want to have written all the six books before the movie comes out, but
I guess I still have time for that. 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 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. Interesting. Well, I haven't seen the nineteen eighties
movies for a long time, so yeah, I'll have to read the books
now you've sold me. I've got a ton of credits on Amazon are audible
as well, So yeah, I'm kind of curious because I'm wondering if they're
like super long books. 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
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. Yeah, yep,
it's one credit on audible, So I just you cost me a whole credit.
So I hope you really enjoyed the book. Yeah, me too.
All right, good deal, Well, thanks for coming. This was fun.
Thanks for inviting me. I enjoyed a lot to talk about to day.
All right, we'll go ahead and wrap up here and until next time,
folks, max out.