Transcript from the "Components Q&A" Lesson
[00:00:00]
>> If a subscription is giving a response that needs to be modified, for example, to create a data structure or columns for a table, would you subscribe to the response in the component or a service? Can you show an example of that? So we can see the async pipe where the data needs modifications, so I can answer the question, and then I can show you an example, and a little bit.
[00:00:30] That the beautiful thing about observable streams is that you have the ability to transform the data inside of that stream into whatever you want. And so under, like, I can't think of any circumstance where you would need to pull data off of an observable stream via subscribe. And then need to do any additional transformation inside of that subscribe block.
[00:01:03] So if you are doing additional data transformation inside of the subscribe block i.e the end of the stream, you have missed an opportunity inside of the observable stream itself within the pipe to transform that. So you can write this one in stone is that when you're working with a stream, your data should be in the exact form that you need when it hits your subscribe block.
[00:01:33] And so I never ever need to subscribe to a stream and do additional processing is that it is in the shape that I need, by the time it gets to my subscribe block. So there are times where I will just pipe that stream right into a template. And then there's other times where I will consume that stream inside of like, some other service.
[00:02:01] But when you consume that stream, your data needs to be in the exact shape that you want it to be. And unlike promises, observables RXJS gives you that ability to where kind of prior to observables. That I would get in, I think a lot of us if you have used promises, you're familiar with this where you basically resolve a promise, and then you still got like, five other things that you need to do.
[00:02:33] And so what I would do is I would essentially create a promise chain, that's kind of functionally trying to to process this. But it's just a lot easier to do that with observables because it's designed for that kind of functional pipeline. So I will show an example of an async pipe in a bit, but the answer is that you should not have to transform data inside of that subscribe block, you should be able to do that in the pipe itself.
[00:03:05] Next question, can we create dynamic template reference variables? I'm presuming this the idea is that, can you create, but dynamic template reference variable that has some unique name on the fly? To be honest, I think you can, I don't know, so let me ponder that. I don't use a ton of template reference variables, simply because typically I only need to grab like a single part of a template.
[00:03:35] So that is a good question, I'm just gonna be honest, I have never tried to do that, if somebody knows the answer I would love to hear it as well. I would also like to hear what the use cases because that sounds interesting to me. CSS in JS also popular in Angular, and I would say that the answer is no.
[00:04:01] The one thing that I would say philosophically is different then, let's say react in Angular is that react has in a sense converted everything into like, an imperative approach. That like, well, how do you do layout in react? Well, you've used JSX, which is essentially a JavaScript representation of the DOM, and so they have completely abstracted away the DOM.
[00:04:33] And I have seen I presume this is what we're talking about is where you see like dynamic CSS that's being manipulated by JavaScript. Philosophically, really the convention is within Angular is that you keep them separate and then we will use like CSS. I think you can use kind of these various JavaScript and CSS, but at least for me, I keep them separate issue because in the template I will use a post processor.
[00:05:09] But the very, very little like imperative logic ever goes into that, so not saying somebody could not, I think tailwind is actually pretty interesting. And something that I'm exploring but the answer is that's not something that I've seen. But it's possible I believe, but I think was rather popular is it, and I don't think it is that popular.
[00:05:38] If we handle the business logic into a service, how can we handle the UX in the component specifically like a loader? So this is a really good question. For instance, what if you have asynchronous business logic? And you need to indicate in from a UX standpoint that something is happening.
[00:06:04] And that so like a loader, or something of that nature, and this is where observable streams become really nice, and I can kind of work in kind of an example of this a little bit later. It's very common actually in NGRX, which is based on observable streams to have a loading property that you subscribe to.
[00:06:34] So you just have a loader that like NGF, if it's loading, show the spinner, and so what this would look like. And this is not real code, but you could do something like, NGF, Async. And so this would just be an observable stream that if it's loading, then it would show this, if not, then it would not, so this is where you might see something like that.
[00:07:17] So I would say use an observable stream, cuz one of the big things with these kind of faces is something happening over here. How do I communicate over here that this has happened? And so typically you have some event based architecture that accomplishes that, well, in the case of observables that event is handled inside of the stream.
[00:07:41] And as new data becomes available that it just pushes that data out to anything or anyone that is subscribed to it. This is a great question, any book that you recommend to learn about component driven architecture, I can't find any, sad face. So What you're going to find is that for some of these architecture patterns that if you want to learn about them and read about them, that you're going to have to go and read books that were written for other technologies, and then kind of transpose that into a JavaScript context.
[00:08:34] And so one of the, first books that I ever read on component driven architecture was on, Flex 4 Components. So before JavaScript, I spent many years doing flash flex, and there is a book, I believe it's called, Building Flex for Components or something of that nature, and that's where I first read a book on it.
[00:09:06] With that said, I would say any of the like, Addison-Wesley, like Signature books is really good, like Enterprise Patterns is a great book. Another book that I really, really like that cut my teeth on design patterns was the, Head First Design Patterns book. Which was very easy to read, it's a very much of an interesting kind of a conversational style, and so I would say that.
[00:09:38] As front end developers, specifically in Angular, there's a lot to be said about going and reading books outside of JavaScript Angular. And front end development, I mean, some of the old classic books, and it's amazing that 30, 40 years ago, that very, very smart people were spending a lot of cycles solving problems that seem very new to us.
[00:10:04] But have existed or people have solved them in cycles for years and years and years. So let me ponder that, I might actually even add that to the README, just some recommended books. I think anything from Robert C Martin, so I recommend clean code, clean architecture, clean coder.
[00:10:25] So a lot of those like kind of high level classic books, you simply cannot go wrong, the great works. And so last question here, can you talk more about the different types of components? I absolutely will, component driven architecture, I think that's all the questions I have Mark, if anything else has come in, hit me I'm ready.
[00:10:52]
>> Have you heard of people using a motion with Angular or any of the CSS in JS friendlies?
>> I haven't to be honest not much, but again, you've seen how good I am at CSS and that's not at all, and so typically I have stuck to material.
[00:11:10] There is, I think tailwinds pretty interesting, but other than that I think it's pretty popular in the react community, but not so much negative that I'm aware of.
>> Since there's about 150 RXJS operators, which ones do you use the most with Angular? I you use so map, is a big one, switch map, merge, what else, filter, so filter is a big one.
[00:11:40] Like you will find that interesting enough that if you're going to learn RXJS, first, you need to understand observable streams, which is slightly different. But people who are learning reactive programming, especially when it involves observables and RXJS is they just get absolutely, I think overwhelmed by how many operators there are, and how many different things that they do.
[00:12:08] What they don't realize is that just under the hood is a pretty, I would say, I don't wanna say simple. But a pretty basic concept that once they understand that first, then it's a lot easier to understand the operators themselves. And so to make an analogy, I've been learning the piano of the shear.
[00:12:32] And I have my teachers, because I have more than one thankfully, that they've really impressed upon me, that I need to learn basic chord progressions and why they work. In doing so, they said once you understand this, then if you really understand this in the context of 10 songs, you'll really understand how to play 50 songs and by extension 150 songs.
[00:12:57] And I believe this works very well with programming in the sense of, when you really understand four or five RXJS operators, and why they work, and you understand why they work because of the underlying observable stream. That wrapping your mind around the other 100 operators is inconsequential, because you understand why they work.
[00:13:23] On the other hand, trying to learn how to play an instrument by learning 150 songs would be really, really hard. And so I would say first principles and then build on that, but for me, map, filter, switch map, merge, I really like taken till is pretty good. And from, have, so if I'm just marking out data, I use have quite a bit as well as tap, but I wanna see what's happening inside the stream.
[00:13:55] So there you have it, those are the tops ones that come to my mind at least.
>> Your thoughts on NGRX versus purely using services for state management?
>> I'm trying to think of a way to say this that is not like, I don't wanna cover this with any kind of like negative, any kind of a slant.
[00:14:19] Because I have actually been in some situations where just the entire tone of this conversation was very negative, very hurtful. That, I'll say this, when you talk to somebody who is a proponent for a service with a subject, so this is where we essentially have stateful services, and they are using the subject to communicate state.
[00:14:55] That more often than not, the argument is like, why would I use NGRX, it's too complex, when I can accomplish this same thing in a service with a subject? The problem with that is that for every piece of your domain model, you have to create a service and then have a subject.
[00:15:27] And so if you have a small proof of concept app, I think that's totally fine. I think using a service with a subject is a transition mechanism is absolutely appropriate. But if you are looking at building a production enterprise level application with a complex domain model. And let's say you have, I don't know 20 entities in your domain model, what you're going to end up doing is you're going to have to create 20 services, with 20 behavior subjects.
[00:16:03] So the difference is with NGRX, they also use a behavior subject, except they use one. And so the irony to me is that NGRX is too complicated or there's too much overhead. And so instead, what we're going to do is create a service with a subject for every entity in our domain model.
[00:16:31] And instead of simply using a single behavior subject for your entire state management. So for me, I'm also a fan of a service with a subject, the difference is that I prefer to just use one in my application versus 20. Not only that is when you use a service with the subject, you lose the ability to leverage all of the other pieces that come with NGRX.
[00:17:03] So for instance, purely from Redux DevTools alone, you don't get to use Redux DevTools if you're using the service with a subject. With NGRX you absolutely can, and it is a great tool for troubleshooting in introspecting within your application. Being able to separate your communication layer via strongly typed actions, is a big plus.
[00:17:31] As well as having a specific layer for your asynchronous side effects is also, I think, really important. And so when people that they tend to, I think be antagonistic or hostile towards NGRX, because it's too complex, what they end up doing is they end up having to rewrite a bunch of pieces.
[00:17:56] Because they're just, they're hand rolling it, and they tend to do it, I think one person versus all of the 100 peoples have contributed to NGRX. I think those implementations tend to actually not be that great. It's like people who, in they exist and I would love to have a conversation with somebody who falls into this camp, but there are people that are totally anti-framework.
[00:18:30] And what I don't understand about that is well, how do you build anything that is non-trivial? Well, what you're gonna have to do is you're going to have to essentially create some kind of a framework on the fly every single time. And I think that's just a lot of work for no reason, so that's kind of my take on NGRX versus a service with a subject.
[00:19:01] I will use them for communication mechanisms, but when it comes to doing real estate management, somebody who's just using solely services with subjects there. I think what they're doing is they're actually deferring their complexity. And they're going to have to pay that price eventually and it's gonna be, it's gonna come with attacks.
[00:19:21] And it's gonna be more than if they would have just started with NGRX. Hopefully that was fairly diplomatic. If we were hanging out and nobody else was around, [LAUGH] I may be a little bit more sarcastic. But hopefully, I tempered that appropriately is that they're great as a transition mechanism.
[00:19:44] But for any real state management, I recommend using an established state management library, like NGRX, or Redux, or something of that nature.