Love discussion on reactive (imperative) forms. One strategy we employ is to build our reactive view model (the state of the page and form) and then use tap to imperatively update the form based on the view model. Then we do everything in rxjs knowing that our form will update off the back of it. Your solution is essentially the same. It's encapsulating the imperative parts inside a reactive wrapper.
Please make an angular specific playlist, would like to watch a lot of your angular specific vids, I see you have ionic playlist. I think stufflike this can go into just angular.
I'm planning on adding a few playlists broken down into things like Nx, RxJS, other Angular stuff. For now, pretty much all my recent stuff is Angular anyway :)
About reactive programming, I think that as much your application grows, the code gets more difficult to understand. And what if you had more code logic before updating the user, it wouldn't be hard to understand, and even to other programmers maintain the code as well? I really don't know if the pros of reactive programming overcome its drawbacks, mainly on big applications and considering the know-how to achieve. But, I'm excited to watch and learn more about angular + ionic + reactive programming, great content!
I think the biggest drawback to reactive programming is the learning curve, and having to have everyone else on board as well. I think if it is implemented well then it is going to make your life a lot easier. But if you don't or your team mates don't have a solid grasp on RxJS and good patterns to follow for reactive programming, then you can easily make things a whole lot harder. Imagine an observable in a service that emits values, and there is no structure around who can access that stream and emit values on it. Debugging issues related to that stream could be extremely frustrating. But if you were managing state with NgRx and followed the recommended best practices, following what is happening in your application becomes a lot easier. So I kind of agree with you - sticking with imperative programming probably is better if it is what you or your team is comfortable with, until you can build up the skills necessary to code well reactively (assuming that is of any interest in the first place)
I feel the opposite way with growing applications. Imperative code is easy (often easier) to follow with few steps. But when the dependencies follow a trail of 8 services and 10 components, finding the source with imperative style is a pain in the ass.
One issue using this style is losing form state if the observable updates. If the UserService sends an update the form will get recreated and loose an changes which may be what you want but not always. In this example it may not be a big issue but could become a problem following this pattern when you using multiple observables that can fire at different times. I've generally preferred the imperative solution as can create the form once and patch its value over time as async data comes in.
You could pass user directly by Input using async pipe, and drop *ngIf, this way component won't be re-rendered, so form will be populated only once in ngOninit. With this approach you can easily react to user change in ngOnChanges if you need to do so.
How would you handle a case where you need to get valueChanges from a field to do something else like changing the field mask dinamically or calling an api?
Hey Josh, I have a question, but first: your videos have given me a better approach to building my Angular for which I'm very grateful! So my question has to do with this video. I'm building a parent component with a users$ observable that passes a users array to a child component. In the child I have a mat-table with lots of built in functionality, but some of its changes need to be passed to the parent. Example: the mat-table in my child component registers changes made in sorting, but the parent component needs to know about the sorting changes to send a new request to my API (through the service). What's a clean approach here? Right now I'm using the @Output function to pass a Sort object to my parent, but that feels too imperative. I'd prefer to link the stream of MatSort and the UserService together somehow, but now sure how?
Hey Colin, it's hard to know for sure without deeper knowledge of the architecture, but the way you are already going about it sounds correct. Assuming the child is a dumb component then it *should* use Output to communicate with the parent, not deal with the UserService directly. Your child component should emit an event when the sorting changes, the parent smart component can react to that event by communicating it with the UserService, which should cause the UserService to emit new data on the users$ stream based on the new sorting.
Have you ever had a situation where you’ve used the async pipe just to trigger some logic but not to necessarily render something on screen? I have a situation where I need to lookup some things from the url querystrings, lookup an api and then save to a cookie. I know using async pipe is the preferred way over manually subscribing so would you still use it in this situation?
I have played around with async pipe tricks for this kind of thing, but for these sorts of situations I am generally already using something like NgRx Component Store and would just use an effect. If I'm not using Component Store I generally lean more to just doing the subscribe in the class - I think it's fine in these sorts of situations where the data is effectively "leaving" your application (in this case you are storing it in a cookie), it isn't affecting your apps state so doesn't really have any impact on it being declarative/reactive
@@JoshuaMorony thanks for your reply. Another suggestion I’ve read is to do that logic within a resolver. That way it completes before the page is rendered (which is good for me because this logic needs to complete before my existing component’s stream begins). Is using a resolver a good option?
I have a couple more recent videos on different error handling approaches, but in general I either like having a separate error stream, or using NgRx Component Store to handle error states
In short, it controls hiding/displaying the loading components inside of the ng-template - I cover this in more detail in the async pipe video in the description
Hi Joshua, I love your videos because you are one that make angular most attractive for me ! I use Angular at my company and sometimes i struggle with some angular concepts. So i m watching some of your videos and i have a more clear idea how it works and which best practices we could follow to increase the quality of code. I m super enthusiast about your topics "declarative/reactive" vs "imperative"
Template driven forms is something I have wanted to dive into for a long time, but never have! I've seen that video before too. Hopefully I will visit the topic at some point.
Great video. Can't you use .patchValue(this.user) to patch the object into the existing form all at once instead of doing it for each value name/email/bio? Your videos are helping me a ton with rxjs. Keep up the good work!
