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.

Hey, everybody, and welcome to another episode of Adventures in Angular. I'm your host today, Charles Max Wood, and we are talking to Armin. 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 got it mostly. Right? Yeah. Armen, your words usually are pronounced as they are written. Yep.

Cool. So do you wanna 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 end developer at an Armenian company called Volo.

I'm in sitting in our office right now in a conference room. I'm a front end team lead, and I'm working on Angular for I think it's the 4th year that I'm working on Angular already. So we started one of our projects back when Angular 2 was in beta. Uh-huh. I guess I've been there from the start.

Oh, wow. Yeah. I remember those days. The all the anxiety around, you know, all the stuff that was changing. And it was, it was sort of, you were in constant danger that something that you are doing today is going on.

Change tomorrow, and you will have to refactor some of your code again. Yeah. But we're in a good place now. I'm kinda 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 is the development and Angular 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 a in a global sense. But we've actually have lots of very good software developers and in Angular too. So the the most biggest part of the market is React, but there are also also big companies here that use Angular and concentrate on Angular. And as a as a matter of fact, I am also teaching Angular, in a private coding school.

It's kind of like a blown 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 Angular developers to, you know, keep it going. Yep. That makes sense. More usually the the larger companies that use Angular.

Oh, really? That's interesting. Because I 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 I talk to people across the board. So There are also companies that use kind of both on Uh-huh.

From projects. For example, one company probably know about, you know, Pixar. Right? The right? But that's an Armenian company.

Mhmm. And, I know that they use both Angular and Oh, yeah. 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 on the React. I know that they were using React, but turned out they also had projects in Angular with different products. So probably. Yeah. That makes sense.

I'm kinda 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 at least started this day exactly 5 years ago, that was my very first working day. So so and I was hired as a PHP developer, but very first day, they told me that they really needed a Python developer.

So they asked me if I could try to, you know, learn some basics quickly and try to do some features. That was yeah. Sure. Okay. I'm already hired, so I guess I don't have really the option.

So so I spent, like, 4 days doing some Python and started doing back end. But, in in do working on a project, there were pieces written in Angular JS in 2016. Within the beginning of 2016, we didn't really have Angular 1 up and running. So so I started doing Angular JS, and it sort of became apparent that it's more interesting for me. So and they got a project that they were going to write from scratch.

They decided to create a single page application with AngularJS and all of that, and and then I started doing it. So I I got I I ditched back end and started doing only front end in AngularJS. Then I switched to my current office, and they were also starting in project from scratch. And they were already doing it in Angular in Angular 2, which was in, I guess, I believe it was in beta yet. Yeah.

So that's how I got into Angular. And, awesome. It's been it's been a long run, but, I still enjoy it. Yep. Yeah.

It's it's it's fun stuff. I mean, I I kinda 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 I I think I found, like, 2 or 3 articles where you wrote about RxJS 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 RxJS in particular? I mean, RxJS is kind of core to the way that Angular works. But for the most part, I find that I can kind of not pay a whole lot of attention to it. What RxJS is doing, you just kinda do things the Angular way, and it mostly works.

And then I just kinda know in my head that it's RxJS that's doing the heavy lifting. Well, for me, it was sort of work experience thing that I was working on a project that had lots of interconnected logic. So Okay. In a sense, it imagine, like, this is a 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 in the other drop down.

And everything that I select in those 2 drop downs depend on some permissions that come from. 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 of our method.

So when, on select this thing, run 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 5 or 6 different states with each other. So that one updates, the other has to update. And it's all it it was all inside one component. I I couldn't even, there were signs connected.

I couldn't even divide it several component 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 RxJS way. I will try to create sort of observables for all the stuff and use operators and functions like my latest or the latest from and so on too. And I will use the async pipe to just just derive the state sort of from observables that I already have and put them directly into the template using the async function. So no subscribes.

And it worked way more elegantly that, anything that I was trying to do before that. And I always enjoyed our JS, but I was in the camp of the people that would say, oh, no, you're using too much. Our JS is over engineering. And so on. I always thought like, oh, why, why did this guy put, I don't know, this logic inside an observable.

Don't really need an observable. You just use just use an imperative function in the field. But after doing it, I kinda got the 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 map and find my final state that I will be 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 RGS because, of course, you can find lots of articles and great literature online on how urgent benefit your application.

So I started investigating my own application, predefined. Oh, again, oh, I find this function. I don't need this function. I can be I I can put it inside single property that's an observable and use it with operator. 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 were actually stupid rules. I was sort of finding out yeah. I was sort of finding out what I have to do with trial and error, trial and error. And then one day, I was like, okay. Let's just try to read about more about RxJS.

I just opened documentation that started trying different operators, and my project transformed. I sort of got way better code, and I thought, yeah, this is this is this is good. I'm I'm going to write an article about it because, every time that I sort of go for an 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 learn. That's a two way thing for me.

I always write an article about anything new that I've learned, and then it got rolling. So I get free articles on ArcGIS and Angular. I got an article on unexpected things in ArcGIS. I wrote an article on best practices in ArcGIS. I guess I have 6 or 7 articles on ArcGIS.

Nice. And I think I saw some of them on Angular in-depth. Is that where they're all posted, or it's just some of them? I guess, 1 or 2 of them have been posted on Medium. Then Yeah.

In-depth moved from moved from Medium. They stopped posting on their blog there. They only posted on on the website and and in the in-depth 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 1,000 followers. I didn't know I didn't know that many followers on Medium. You're popular, man. Yeah. And I didn't know about it because, like, for 4 or 5 months, I didn't even open Medium.

I also stopped reading there sort of after getting involved with in-depth. Yeah. I didn't know I was talking to celebrity. Wow. So I'll be more famous, Minyan, but there you go.

Gotta start somewhere. Right? Yeah. So, yeah, I 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 Angular, 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 RxJS. I didn't even think about it, and I'm just going, I feel kinda silly now because, yeah, it would have been so much easier to just approach it with RxJS and just say, okay. If any of these things happen, right, then emit an event. And if any of these things happen amid an event, and then, yeah, if we come back around any of this stuff, then, you know, we're subscribed to those events and we just know what to do.

So Yeah. The the same sort of revelation I went through when I was trying to reflect her a lot of stuff. Nowadays, when I start anything new, the team I'm working in is, sort of receive new projects all along from the client. So Uh-huh. We would just receive something that probably you have to write from scratch using, stuff that you already have.

So the next thing we got, I was like, yeah. But we're going to use NGRX. We're going to use observables. We're going to use ArcGIS a lot. My next stop is trying to refactor and move away from using internal states at at all.

Like, I'm I'm going to use the NGRX component store Mhmm. For all the internal interactions and use NGRX for everything can can commuting between 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 and async pipe. I 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 issue, like, oh, am I going to create an observable by hand for everything?

No. You can just, you know, use the store class and Uh-huh. From it. Right? The store register selectors and put them in the components.

So it can be it can exist in parallel with your component, and you will see all the transformations of the store with the updater functions and so on. Just put in there, use the async pipe and so on and so. And I think that might be nice. So I'm sort of going to write a proof of concept or something like can can we ditch local internal class based states and just use ArcGIS? Yeah.

Yeah. I'm I'm kinda curious to see how that would work out. To to be perfectly honest, I haven't done a whole lot with ArcGIS or NDRX. 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 that you found RxJS solves within your your app?

Well, well, for starters, again, the biggest sort of benefit that you get from it is removing the imperative logic, number 1 benefit, and not having to synchronize 2 different states. So the my biggest problem always was that I have sort of these 2 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 ops 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 ArcGIS, you or even unwillingly, you have this single source of truth. So you don't have to check 3 or 4 places to see how your state is transformed.

If there is sort of you have this small dependency, like you have an NG model binding or you have a component and you pass in an input and you use the async pipes or parenthesis and observable. Mhmm. 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. This this this operators are used on it. So and 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 is a problem, it's in this 5 lines of code or anything you have written. Right. 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 all oh, okay. I have this array. Let's let's use control f, c, whoever has updated, or let's Right. Right click and file references and stuff like it.

No. 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 to try to find where the bug is coming from. Because usually, when we find in in, like, 80% of cases, if we find where the bug is sort of located, we usually easily fix that.

Right? So finding is sometimes is a problem. Understanding exactly which 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 5 operators. 1 of them is doing something wrong. Let's find out what what is in the 5 lines of code. That for me is the biggest benefit because in imperative logic, you always have to sort of dive into try to answer, oh, why why do we have a loop here?

Oh, this is all okay. This is array. Push something into array, get something from array, and sort of go on and go on and go on, and that can become overwhelming, especially if the logic is large. Yeah. That makes sense.

I mean, yeah, you 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 it's easy to follow. I guess the other question that I have just kinda 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 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 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 refactor too much or don't want to, sort of over engineer, like, lots of people off at all. Maybe I'm blowing these out proportions. Maybe I don't need this whole lot of stuff. Maybe I'm doing just the regular way.

Yeah. But my answer to that is usually try it and then you'll know. Right? Yes. Sort of.

Yeah. But of course, obviously, in the real world, lots of people that won't have enough time to do that. Like, you have this project, you have this deadline. You have to do something and you are not sure. Maybe if I try to to do this, I mean, you maybe I won't have time.

And of course, some people say, oh, my application is small. I don't need something like that. And I was saying that in the context of, NGRX, but I said something on Twitter, like 6 months ago, 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's large enough that you can use NGRX.

The same for me applies to RGS. It may sound a bit radical, like, maybe not. Some people say, oh, this is a small thing. But if this is so small, if you say sort of a 2 pages, why don't need this behemoth of a framework that Angular is? Like, it's being it has lots of things.

It has lots of feature. You can write in something easier if you, of course obviously, if Angular 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 writing 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 they get, oh, how do I do stop this? We usually in Angular, we have these, this, and I have to now go on, find third 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.

React is more, like, sort of shallow, and and that's a good thing in its own way. I personally enjoy React. But the thing that I like Angular more is that it's more opinionated. It says, and it has more features. So so you can use this and this and this.

You don't have to think about HTTP request that you covered. Right. 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. It doesn't seem to need. So, of course, you opt in for Angular for all those features. So, obviously, if you need lots of features, then you have a larger enough application. So why not use the NGRX for an interconnected pieces at least?

You don't even need to use any you write everything in NGRX. There is some debate to it, but, obviously, the stuff that is interconnected, the stuff that shared state between components, NGRX will just solve all of that for that for you. Right. So it makes sense to do that. So same goes for any for RxJS.

NGRX is basically like RxJS, but stronger. So if you can use RxJS to solve some problems, it would be good. And the sooner you started, the less problematic it would be to use that code. So the factoring is always harder than writing code from scratch, obviously. You usually face more bugs if you do refactoring because Right.

Sometimes you might look at code that you yourself even have written, but you would misunderstand something there. And refactoring into ArcGIS, you 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 RGS or maybe using a jar x if you're going into it. At least consider it. Right.

No. 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 to use RxJS because I mean, I that is true, you know. And I thought, okay. Well, then what would you use for the smaller apps?

And, you know, if you I think it's 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 put stuff over the top of it that just kinda 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 kinda gone into the deep end with RxJS, what do you find are the things that people misunderstand about it? Like, where where do people get stuck on on RxJS being a solution or get stuck on what it can and can't do? Well, I had, experience with lots of developers that tried ArcGIS both in our team and outside. So I noticed that there are many free problems with ArcGIS that people sort of not write the best code that they could do. And that's all all of them are connected to how they use RxJS.

So they either not use it enough, misuse it, or plainly abusing it. Okay. So, I try to cover all the free cases. So, obviously, 1st case not using it enough because there's a problem can be solved 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 ArcGIS in Angular. It's it was the first one, the the 3 parts. And in part 1, I wrote about how you can change your imperative logic to more reactive or functional programming style, to a more declarative approach. K? So it involves trying to understand the source of data, trying to understand what affects the data and how it gets transformed, and then getting the final result and displaying it to in the template in in the UI.

So those were the steps that you can sort of try to apply to any problem. Like, if you got I'm going to develop this feature. I can try to use the steps to understand how can I convert it, right, using r o ged? You can sort of always try to do that. So even if you don't convert something, something is large enough, your 3 factories don't have time.

You still can, like, sort of process in your head. It won't take really much. You can try to think about 10 minutes if you sort of understand instantly how the flow of the data is. Okay. You can go forward.

I just tried to write. People often don't do that. I know people that know r e g s well. They know lots of operators, how they work, some nuances, but they just won't use them. It's like, yeah.

Okay. I wrote 5 lines of code. It works. Yeah. I don't think the r j is for this, but really, it would look more elegant and more scalable if they did the r j even even for that 5 lines.

But 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've tried to solve. So the third point 1, and then it comes point 2 is sort of misusing our Aegis. So how people do misuse our Aegis is usually what they do in the first step. So a lot of some people will come and think, yeah. Okay.

I'm not using RHS. 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 has done. So what would they do is they will sort of start using observables and not really appreciating all 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 AC pipe. So that's the first thing people just teach it. They will write subscribe and a callback with lots of imperative logic. Then, they will use they 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 you can change how your subscribe logic looks like.

So sort of if you have, for example, an if statement. So you you write subscribe, you get some data, then you write if data is true something something, then do something something. In our suggest, you can use the filter operators for that. You can just write filter and support function won't be called at all. K?

Right. It will and it will look way more sort of concise. Like, we'll look you will see if you see the filter out there, there are some conditions that are not allowed. K? Mhmm.

You see that immediately. In subscribe, you may have a large function inside an if. So you should have to go through and read the subscribe function. You really don't need that. Right?

Filter and the condition is obvious. So after that, you don't perform anything. And that is also sort of better beats, minor bit, but, you know, if you're more or less perfectionist, it will be great. So you don't need to execute 5 operators, and then don't do nothing in the subscribe because the condition is not met. You can put filter wherever the data is ready that you can check and not allow all the other operators to work.

That is also a nice thing to do. Or people would not know enough operators. Obviously, you can't 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 you when you have 2 or 3 spare hours, you can open RxJS 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 throttle throttle times, the window, the bounce time, the bounce, and so on.

So you can sort of know about them. You don't need to write examples, follow them. Just know that, oh, there is an operator that does the bounce something. Right. So in the future, we will remember that, okay, I've heard about some operator 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 misusing RxJS. Like, you are using RxJS, and it actually provides a very nice solution to your problem with 1 operator to a combination of 2 custom sorry, building operators. But you don't know about them or you don't sort of think too deep deeply enough about that particular observable. If you don't use it, then you end up with worst code.

So that's the sort of next bad problem with, with RxJS 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? Yep. And then we, of course, arrive at the third point that is just Yeah.

I I have seen pretty hard book code that to this day, I don't understand why people opted to do that because what would they do is sort of everything was an observable, but in a sort of scattered way. So they will have properties. For example, they will have an event. I I mean, exact exactly remember how that logic went. There there is this chat window.

It looked like Facebook Messenger sort of Right. In the and you have conversations on the left, and you have the chat window in the middle. So the thing is you click on the conversation. There is an HTTP request. It loads the last 20 or something messages, and it displays.

So, of course, you can do it, say, within we haven't been using any state management back then. We didn't use our INJARX or something. So you could do it in a more or less practical way without RxJS. Okay? You could just click handler that will call a service load data, pass it with the inputs to another component, and it will render or something.

But what they really did was it like, oh, we want it to be reactive in a way. So instead of the sort of manipulating understanding how their data works, creating observables in in normal sense, combining them, they will just be like, okay, the here is a subject that notifies me about the click on the button. Essentially, what that subject was doing was just it will emit from the button. And it was really useless, and it made code very unreadable because now you cannot even navigate using the IDE tooling to find out, oh, well, okay, this, this function next this subject who has subscribed to it. And then in some service somewhere far away, there is someone subscribes to it.

And it gets it, loads some data, and then pass it to another subject. So as to sort of go through all the pain, have events to find out, well, okay, here is a service. Okay. Finally, data is loading all. 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 component subscribes to this subject. It's sort of a big, large, and unnecessary chain of subjects that are calling each other, sending events.

You really didn't need that. That was, like, horrible. It it really was an abuse. I I cannot find that, like, sort of word that I can describe it with. Of course, it came from notion that people would overly enthusiastic about or it's just, oh, okay.

We're going to sort of that's why you need solutions like NGRX. Mhmm. The the good thing about NGRX is like, okay. If you need some data, just select it from the store. You don't have to work with 15 observables.

There is one source of truth. All of your state is 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, oh, okay. Beta is not transformed in a way that you expected.

Okay. I will go debug the reducer function, and that's it. Or I will use the, reducts dev tools extension and just find out, oh, okay. After this action, something changed. Okay.

I will just check the function. It's a pure function. You can easily reason about it, and you're done. But in this case, you got the, like, horrible mess that, explain its abuse of the thing. So that's the main problem that people face when I start doing ArcGIS.

Usually, that's why they either nothing deeply about it. Uh-huh. Either think too deeply about it, and in the end, they would probably get disappointed. They will think of 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 instead of just saying That, yeah. Well, that happens.

Subscribe to this and then, yeah, just do the process. Just do the work on it. That that that's why actually in the RGS, community, they say, oh, don't subscribe. Just don't subscribe. Subscribe ends, ends, like, the nice things about I actually worked on a document for the original documentation, that they wanted to have a best practice page.

There was an open issue. They submitted the draft pool because it's it's in a process of work. And different community members and contributors wrote in the comments what would they like to have in that drafts that I I wrote sort of, and one of the main things that was noticed is let's inform people that use r h s about the fact that subscribe ends composability. And composability is actually why we use our when you write subscribe, you cannot use any operators. Right?

It's over. Right. You have the data to do anything with it. It's usually imperative logic. So when you subscribe, it's end of story.

So, obviously, you need to subscribe because there was if you don't subscribe to, don't do anything. But you don't need to do it explicitly and do all that heavy lifting inside it. In Angular, you have the async pipe and also with, NjarX fused. There is this experimental Njarix component that provides directives that you can use. There is the Njarix less directive.

It's very nice when you can just extract the observable result to a variable, local variable, new content and use it. It's better than writing, n g as something to use it without the async. Right? It's a very nice thing. I use it in my project a lot.

So you really don't subscribe manually. It sounds important after that. You just use the value. Okay? You you need the value of the template.

If you're writing Angular, you don't need the state for the sake of the state. You need something to display in the UI. If something is never displayed in the UI, you probably don't need that. Mhmm. Either display the exact state in the UI or some result of that state, something that happens because you have a state like this.

So rapid and observable, take it using async 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 are using 3rd party code that only has an imperative approach. Best example is form controls in Angular.

They have disable function and enable function. 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 dot disable.

But this imperative logic cannot just put it in template. With template driven forms, you can ditch that. You can use the disabled attribute on the, implement or something, but reactive forms don't allow for that, which is sort of weird because reactive forms are supposed to be reactive, not imperative, which they usually are, but that sort of have lots of imperative function. Market size, set disable I don't know. Disable, enable, and so on and so on.

Well, most of them are a bit imperative. So the that's the only case that probably yeah. So if you don't you don't have a choice, or or you have a a library function that does something something. You have to call it. You cannot just write an observable Right.

Put it in. So that's the only case that will allow to do that. That that's a nice thing to start from. If you write subscribe, maybe something isn't very right. Try to understand how to do it better.

Sort of, it provided it's like a point of thinking, like, how can I make my RGS code better? Let's take a look. How many subscribers do I have and how many can I ditch? Nothing's done. A good starting point if you ever RxJS code base won't refactor it.

Makes sense. Cool. What about testing RxJS? That's sort of the my biggest weakness is that, I don't do much testing, because, the requirements yeah. They don't the requirements don't from our clients going to the human 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, RHS, there is there are marble tests. And Mhmm. If you don't have side effects in your RHS, so so if you don't use the tap function, the the tap operator, which is also considered a bad practice, you should 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 tap function, you sort of have a bunch of pure function.

K? Uh-huh. You can more or less easily test that even without the marble testing, just using basic unit test. You can do that. In the very end, if you have some properties on the class that are observable, you can just, okay, create an instance of that class.

Maybe subscribe to the observable, see what data comes and how we can sort of manipulate the source of the data. Like, is it coming from an event? You can always sort of trigger that event. K? 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've subscribed to. I'm checking for 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, then testing is way way easier because you sort of have to test just 2 things. You have to test 3 things.

Sorry. You have the selectors, which usually are pure functions, so they should be pure functions. So it's easy to test. Right? So it's just function.

It gets Right. You have the you have the state. You know about the state. You're the one Mhmm. Providing a mock version of state to the unit test.

Right. So you can just check the result, and it's okay. If you get the result that they expected, 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 is a pure function. We provide the action, get a payload. Mhmm. Get the result, it's expected. So, okay, it's done.

You don't have to they're not lots of different cases and other global variables that can affect the or reducing the pure function. To test. The only thing that's probably less easy to test is the effects, but, that's really the main point. If you if you have effects in the GRX, that's the only place that you have 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 we have expected. So Mhmm.

It's sort of the same it's sort of the same thing that they actually do with the reducer. It's just not a pure function. You know? So it does something on the side, like calling a server or maybe going 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 that service.

Like, for practical example, say you have an orders service that loads orders. K? The data, and you have the order effects. We 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 that's some complicated logic, you don't care care about the results.

So you can Right. Sort of sort of treat it like a quasi pure function. It isn't, obviously, but because you have mocked the service, it will always return the result that you have expected if you've if you have written the correct code in the effect. So that's what you're testing for. Right.

And then you will test the order service separately, which actually will be just mocking the back end with, I don't know, XHR mock XHR back end or something something or the HTTP testing library in angular testing. So testing dialysis is also busy. So, essentially, you get 2 interconnected classes that are both 100% test covered, and, that really made your job easier. If you have been doing all of that in the component, then that component unit doesn't really be. You will have to mock the service and put it, okay.

Oh, this component uses 5 or 7 services. For example, you have to mock all of them, put them inside this component, and then check for it in every way. Like, oh, this button is clicked. This function is called This service server function is called. Mog data is here.

It's rendered something something. NGINRx saves you from that too. In in your components, you usually only if component is a bit smaller and uses only external state, you inject only the store. Inject the store, this one. You don't need to mock the store.

You don't mock the store in Mhmm. NGRX test. You mock the selector. And it's very easy to mock a selector because you essentially just say, oh, this is the data that this selector is going to return, and that's it. Right.

It has a multi lecture function like okay. I have an the orders property that I already use in the component. Okay. I I moved the selector. And I'm like, now there are 3 orders.

Now I moved now there are 5 order orders. Let's see what happened in the UI. Oh, it works. Now it's really easier to do that than to try to you don't move the dependency rather just move the data with the selector, functions. Right.

Yep. That makes sense. Alright. Let's see. Is there anything else that we should cover?

I guess the next question I have is if people wanna follow you, because you have a 1,000 followers on Medium now. If people wanna make it a 1,001, I guess they can 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. Yeah.

I I usually want people to follow me on Twitter because I usually post stuff there, because if I remember correctly, you cannot follow Otter on in-depth. I think we don't have that functionality there. So I always post my articles and some other folks on Twitter. So I guess, people can follow me on Twitter. Okay.

What's your Twitter handle? It's, Armando True. Alright. We'll we'll make sure that we have a link to that in the show notes. If you just put in the chat, we'll put it over there.

Yeah. Yeah. K. 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, 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 3rd or 4th time. I listen through the books whenever a new one comes out, and a new one came out last year. And, yes, I'm slow.

Yes. The the book came out last year, but, I've been listening to the 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 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 gonna take too long because I don't wanna 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 stormlight.

And then there are certain people that can take that stormlight and use it to do magic. And, anyway, the the thing though with Brandon Sanderson's books is the magic systems are interesting, but the characters and the the story lines and stuff are way more interesting. And to me, at least, that's the thing that I really love about a lot of the 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? It's because the characters were rich. It followed the hero's journey. It you know? Yes.

I'm kind of a 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 1, 2, and 3. And people were just like, they just weren't as good. And I don't know why.

Right? Because the special effects were better and everything else. And it's because the characters weren't as interesting. Right? You kinda knew who Obi Wan Kenobi was gonna 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, same with Padme, you know, she was just always you know, she 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 Leia and Han and their struggles with who they were from, Rey 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 and 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 cosmere. And so that's always fun too because you're wondering, at what point they're gonna 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 you do meet them as you move through the worlds. The Stormlight Archives actually has one character that you've seen in several of the books, but he kinda has this passing role. And then this book in the first Stormlight Archives book, he's actually almost a main character. So that 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 listen 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 gonna keep reminding people it is out there. Basically, the idea is is that if you're trying to get your career to go to the next level and you wanna make an impact on the community while you do it and, eventually, you'd like to get paid for it, then 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 5 podcasts in their niche within 6 months. So if that sounds interesting to you, then come join us. You can go check it out at devinfluencers.com/apply.

Also, I did start a dev influencers podcast, and that's at devinfluencers.com/podcast. Alright, Arman. What are your picks? Oh, well, when we were talking about, books that you have been listening to, I I kind of thought it's a nice topic to sort of build on because, I I like both fantasy and science fiction a lot. I I I like Star Wars.

If I knew we're going to talk about Star Wars, I would wear my Star Wars t shirt. Oh, yeah. Yeah. So, Andrew, the the thing that gets me excited about this topic is waiting for the Dune movies to come out. Oh, yeah.

And because, I'm a huge I'm a huge fan of books, and I actually, regret not read the books. Are they good? The Duke books? 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 and I regret not reading it earlier because Danny is my favorite movie director. I absolutely enjoy all the movies that, he created, like, later later on in 2049 and arrival and all the other stuff that he had. So when I, and I and I always, have known about Dune, that it's a classic. That's a great book, but I always look like, maybe I will read something. But when when I realized I've seen the movie, the 1980s movie.

Oh, no. I I didn't watch it. I didn't watch it. So I so when I watched the the movie that will eventually hopefully come out, I will have only those impressions. So I I I won't sort of think about the Lynch movie.

I have seen several clips from the Lynch movie. The extras are really good, but it's 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 William is always saying in his interviews that, no. I'm going to sort of try to convey what the old author originally intended rather than sort of come up with my interpretations or something something because he's apparently a big fan of Frank Herbert.

So when I learned when that Danny Vigneault is making your 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 explain. Because for me, it's I always love the experience of watching a movie on a book that I like.

I enjoyed watching the Harry Potter 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 new books, I was sort of blown away, but not from the start because from the start and that's a mistake that you've made. The you think that it's sort of this hero journey. It's sort of like Star Wars.

Like, there is this guy who has this problem who has to go through these adventures and then come out on top. But in reality, it's a sort of dystopia that you find out about only if you keep on reading the other books. If you just read Dune, 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 you sort of end up with, like, yet 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 dune 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 Dune and Dune Messiah, but it it got too long.

So the publication asked him to try to sort of put it in half. So the other part of life, and I'm trying not to spoil anything of the main protagonist is in the other book. And when you read the other book, you sort of understand, ah, okay. This really is something different. This really is rather than being a hero's journey, a sort of trope.

It's it actually criticizes that trope and tries to make the reader to understand that, yeah, you know, that stuff, it only works in works of fiction. In real life, hero trope is is not the 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 tragedy that goes through that family that goes through all of that. And it it sort of comes back in in children of Dune, which is my favorite. The 3rd book is a 100% of my favorite in the ones that I've read.

I've read up to god emperor of Dune, the 4th book. And after that, you sort of take a break and the other events happen 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 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 come out. I want to, have written all all the 6 books before the movie comes out, but I I guess I still have time for that. So that is something that I really enjoy, the the Dune books, and I would advise anyone to read them because they 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 that everything that raises any conflict in our world. So it's it's a nice nice, large, big, piece of different thoughts and opinions inside those characters that interact with each other, and I I guess it's really really great read. Interesting. Well, I haven't seen the the 19 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, Audible as well. So Yeah. I'm kinda curious because I'm wondering if they're like super long books, if they cost. They kind of are, but they are a bit confusing in in the beginning because Frank Herbert really doesn't like exposition.

He he will throw on, like, this terminology of, the sisterhood, Andy would what the hell that is? And oh, okay. Yes. Sort of. I get it.

Yeah. Maybe something. And then they were like, oh, this is Gom Jabbar or this is something this this is the Zenfone religion and so on and so on. 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. Yep. Yep. It's one credit on Audible, so I just you you cost me a whole credit. Oh, oh, man.

So I hope you really enjoy the book. Yeah. Me too. Alright. Good deal.

Well, thanks for coming. This was fun. Thanks for inviting me. I enjoyed a lot talking about a tough day. Alright.

We'll, we'll go ahead and wrap up here. And until next time, folks. Max out.