💥 Angular Mistake #4: 🛑 STOP Avoiding Using Promises

  Рет қаралды 4,088

Angular University

Angular University

Күн бұрын

Пікірлер: 81
@AngularUniversity
@AngularUniversity 10 ай бұрын
Check out here the playlist for the full Angular Mistakes Series kzbin.info/www/bejne/aaDUXpqked-tb80 😊 If you are looking to learn Angular, check out my courses for all levels, Beginner to Advanced at the Angular University - angular-university.io
@moitp2
@moitp2 10 ай бұрын
I commented on your previous video about the same subject. I'll do it again :D First of all, the claim that the Angular team would like to slowly make RxJs "optional" is somewhat arguable. Why? Because in their roadmap, they specifically state that they would like to upgrade to RxJs 8. This would make no sense if they intend to eliminate it. Additionally, they are promoting Signals instead of BehaviorSubject services, which is not the same as eliminating RxJs for asynchronous operations. So yeah, we are gradually going to stop using RxJs for synchronous tasks, but it will still be the main recommendation for asynchronous operations. Now, let's talk about your first example. Like in the previous video, it's not a one-to-one comparison. The forkJoin is performing two requests in parallel, whereas calling two await methods will execute those requests sequentially. A more valid comparison would be to use Promise.all(). So, how is this less complex than the forkJoin operator? And I apologize, but you don't have to spend hours learning RxJs to know the forkJoin operator; it's one of the most common ones. Regarding your second example, once again, you are using combineLatest when you should use forkJoin. combineLatest has no advantages over forkJoin if the two observables are HTTP calls. Moreover, you don't have to unsubscribe from a forkJoin observable, whereas you do for a combineLatest one. A scenario where combineLatest becomes useful is when you have, for example, a Subject/BehaviorSubject containing some state that can change. Each change triggers a new HTTP call thanks to the combineLatest operator. And it that case, it's even simpler to use RxJs than Promises. If you can eliminate the combineLatest operator, then you don't have to use the startWith operator either, which brings us back to the first example. As I already mentioned, the first example using RxJs accomplishes more than the Promise equivalent. I've mentioned this in your previous video, but with Observables, you get much more than promises out of the box. Observables are easily cancellable, retryable, and cacheable, for example. As much as I enjoy your content, I just can't agree with these arguments about RxJs vs. Promises :) Keep up the good work, though!
@AngularUniversity
@AngularUniversity 10 ай бұрын
For what we know, RxJs will not be eliminated, but it will become optional. It's the Angular team on interviews that mentions this, and I think that it makes a lot of sense. It's true that RxJs is used in a lot of places where it probably shouldn't. My main point with the videos is that it's way easier to write HTTP code using async/await. Those properties that you mention are rarely needed. When was the last time that you actually needed cancellation and retries in a project? it's like using a canon to kill a mosquito. 😊 You can easily get those properties if you really need them via libraries. Noone uses RxJS outside Angular and they do just fine, that's my main point. 👍 Consider a simpler way of doing things. 😉 Thank you for commenting.
@PlerbyMcFlerb
@PlerbyMcFlerb 9 ай бұрын
I suppose you don't need to unsubscribe from a combineLatest either as long as every observable inside it is finite, no? For this reason I never use forkjoin, and just stick with combinelatest.
@moitp2
@moitp2 9 ай бұрын
@AngularUniversity, I apologize, but perhaps you don't need cancellation and retries in your project. Still, I can tell you that I do. Additionally, you didn't mention caching-why is that? :) "You can easily obtain those properties if you genuinely need them through libraries." How is this better than using an official tool supported for years by the Angular team? What draws people to choose Angular over other solutions is the assurance that they won't waste time searching for the best library to perform a specific task. Regarding other frameworks, you may be overlooking Svelte. Solid.js also employs its version of Observables. While neither is React nor Vue, Svelte remains a popular framework. Moreover, just because others aren't using a specific tool doesn't mean they have an easier life. Compare their approach to handling HTTP calls with our use of Observables; in many cases, it doesn't seem more efficient. Every time a task is slightly more complex than a single HTTP call, the situation worsens. Your example demonstrates this, even though there's a mistake since they don't perform the same function. A forkJoin equivalent would be Promise.all(), which doesn't simplify the code. You end up with the same number of lines and use some form of operator. Moreover, you'll need to employ a try/catch, whereas an operator suffices, requiring fewer lines of code. Also, as I mentioned in the other video, what about ngOnInit? It is no longer necessary with observables. As I said in the previous video : let's agree to disagree on that subject :)
@mr.nefario
@mr.nefario 8 ай бұрын
Have nothing to add. Just perfect
@jtpoltorak
@jtpoltorak 9 ай бұрын
Vasco, you are the man... great video, I learned a lot. Keep these videos coming!
@AngularUniversity
@AngularUniversity 9 ай бұрын
Thanks! Will do!😊
@nunoarruda
@nunoarruda 10 ай бұрын
Promises or Observables are both fine and valid options. Just make sure you use the right one depending on the use case. For example, Observables are cancelable, Promises are not.
@AngularUniversity
@AngularUniversity 10 ай бұрын
Sure but when was the last time you actually needed cancellation? You can cancel HTTP with promises as well, it's no problem. There are simpler solutions for the problem that don't involve such a complex library like RxJs, that's my main point.
@nunoarruda
@nunoarruda 10 ай бұрын
2 use cases immediately come to my mind: type-ahead search with DB requests and navigating away from a route in the middle of an HTTP request.
@PlerbyMcFlerb
@PlerbyMcFlerb 9 ай бұрын
​​@@AngularUniversityfor me the answer is today 😂. I do it ALL THE TIME for quick finds etc or just preventing network chatter from a click-happy user. I've seen people oversell the cancellability, but I think you are underselling it
@Schwartz_ls
@Schwartz_ls 9 ай бұрын
If your call to the DB requires cancellation. Then use RXJS. It’s not going anywhere and for a good reason. However, not all calls need to be cancellable. I believe this is what he is arguing. Not my style, but I can see the mans point as well as see yours.
@ratg97
@ratg97 9 ай бұрын
forkjoin is better, because you dont wait first query to end like in async await example
@AngularUniversity
@AngularUniversity 9 ай бұрын
You can do parallel queries in promises too with await Promise.all(...)
@ratg97
@ratg97 9 ай бұрын
@@AngularUniversity thx for answer
@zSandman99
@zSandman99 9 ай бұрын
@@AngularUniversity It would have been helpful to include this tin the video. Thank you for these videos I've been learning a lot.
@megarustog
@megarustog 9 ай бұрын
Very helpful again. I find writing components like this to be significantly more understandable than the declarative and more reactive approach encouraged by default. I'm currently wrapping my head around understanding when to use both and what the best default approach is. It doesn't seem like there is an easy answer to such a question and it very much depends on circumstance.
@AngularUniversity
@AngularUniversity 9 ай бұрын
Thank you it's awesome to hear that. I think for typical HTTP code promises are a great default, I would use RxJs only when and if needed. It's all about using the right tool for the job. 😊👍
@tarquin161234
@tarquin161234 6 ай бұрын
I would recommend learning to write declarative rxjs focused code. I work on an extremely complex front end project and it would be hell with an imperative style. I would never go back to imperative. People recommend it for a reason.
@zirexpl6395
@zirexpl6395 6 ай бұрын
I am working almost 3 years with angular/net. When i see now ur approach with promises, I start to wonder why the heck we are using rxjs :D (i hate it! And promises seems to look almost like c# code :D) Does it have any benefits? What about performance? Does promises have any disadventages?
@AngularUniversity
@AngularUniversity 6 ай бұрын
There aren"t any disadvantages. RxJs handles very well certain rarely needed edge cases, but you can handle those with libraries. No need to write your whole application in RxJs just in case you need it. 😉 My team has been using minimal RxJs for well over a year, and things work way better this way.
@Brendan2Alexander
@Brendan2Alexander 9 ай бұрын
I love this channel. Thanks for the great tips!
@AngularUniversity
@AngularUniversity 9 ай бұрын
Thanks for watching! 😊
@mayasingh1910
@mayasingh1910 3 ай бұрын
great series
@AngularUniversity
@AngularUniversity 3 ай бұрын
Thank you so much!
@AleksandarT10
@AleksandarT10 10 ай бұрын
Great one. Keep the series coming!
@AngularUniversity
@AngularUniversity 9 ай бұрын
Thank you. 😊
@codeSurvivor
@codeSurvivor 9 ай бұрын
Beginners, be aware that what seems simple today because of being imperative will become messy once you need to add changes or the complexity increases. If I knew this when I started i would invest my time in learning what declarative and reactive programming are and how to apply these patterns once being familiar with Angular. It would have saved me and the frontend team I work with a lot of struggle. Simple is not necessarily easier to maintain, well programmed and extensible code is definitely easier to maintain, and that, for sure, is not imperative programming
@AngularUniversity
@AngularUniversity 9 ай бұрын
It's a beginner myth that things need to be complicated in order to be "right." For most applications for the typical HTTP code, promises are a much better fit. Getting the job done in the simplest way possible is what keeps a codebase maintainable in the long run.
@TimurMishagin
@TimurMishagin 9 ай бұрын
Can totally agree with that 👍
@burningtree878
@burningtree878 9 ай бұрын
Right on brother, well said. Let’s get back to simple 👍
@AngularUniversity
@AngularUniversity 9 ай бұрын
Thank you 😊 Yes, let's do it. 😉
@gabrieldelosrios811
@gabrieldelosrios811 6 ай бұрын
RXjs team here, let's be honest it's not about better code, it's about a broader audience, the angular team is pushing for angular to be more beginners friendly, but it doesn't mean that it being easier to grab also means better coding, in fact i think this could actually take us in the opposite direction, great video anyway.
@AngularUniversity
@AngularUniversity 6 ай бұрын
Thank you, I've made a summary about RxJs becoming optional here kzbin.info/www/bejne/q4CslXyCr5J3odk, where I quote the original sources from the Angular team (links in the description). I think not having RxJS in the main learning path of the framework will be very helpful for the whole ecosystem. There will be interoperability for those that choose to use it.
@gabrielordonez7876
@gabrielordonez7876 8 ай бұрын
Hello, excellent explanation as always, I would like to obtain the code used in this video to understand it better.
@AngularUniversity
@AngularUniversity 8 ай бұрын
Thank you Gabriel 😊 The code I didn't keep around, it was just a quick example I came up with on the fly 👍
@Maxim.Shiryaev
@Maxim.Shiryaev 7 ай бұрын
IMHO, like in non-async code we use scalar variables for a single value and array/collection and for-loop, for async code we should use Promise for a single future value and Observable for a series of values. http in Angular was wrong in that sense from the beginning since request returns just one result.
@AngularUniversity
@AngularUniversity 7 ай бұрын
I agree, using Observables in the HTTP client was not the best move ever, Promises are a better fit for HTTP, especially with async/await. The new way of doing things in Angular is way easier, just wrap the data in a signal, but other than that it all works almost as we are using plain member variables.
@leiayuri
@leiayuri 6 ай бұрын
Hi, would you know if I have a component A which extends a directive B. And in comp. a I am in injecting a service A with inject and inside of the constructor I am also calling super and injecting the service A. The question is, am I creating 2 instances os service A? Thanks in advance. Example: Class component A extends Directive B…. Service = inject(serviceA) Constructor() { super(inject(serviceA) } In that case am I getting same instance right?
@AngularUniversity
@AngularUniversity 6 ай бұрын
What gets injected depends on what you set up as the injection token. Stay away from inheritance in Angular, don't ue extends at all it's an anti-patttern. Directives are meant mostly for composition, not inheritance. That ay of programming in Angular is highly discouraged.
@leiayuri
@leiayuri 6 ай бұрын
@@AngularUniversity thank so much for your advise. I will try to convert and use the composition way. BTW do u have any video talking about that?
@AngularUniversity
@AngularUniversity 6 ай бұрын
@@leiayuri you're welcome currently there is no video, but it's general practice in the Angular ecosystem to avoid inheritance. 👍
@seanszarkowicz
@seanszarkowicz 10 ай бұрын
Do you think HTTP calls will be Promised based in the future of Angular? Its makes doing sequential / dependent API calls easier at the start of using Angular? RxJS for more advanced feature if needed for HTTP
@AngularUniversity
@AngularUniversity 10 ай бұрын
I like that approach that you suggest, it's what I use now. You can already use Promises in Angular to do HTTP, no need to wait for a future version. 👍
@seanszarkowicz
@seanszarkowicz 10 ай бұрын
@@AngularUniversity Yea I cant find where its documented anywhere on the Angular docs, so it makes it seems like its not the "Angular Way" - does your way work with HTTP Interceptors? I have been trying to put together some best practice / examples using Fetch with Angular and Signals or NgRx Signal store in the last couple days when I saw your video. Also trying to have examples working with HTTP Error Handlers. My goal is to keep things as simple as possible with HTTP Fetch. Do you have the example you use for HTTP Fetch with Async / Await?
@PlerbyMcFlerb
@PlerbyMcFlerb 9 ай бұрын
​@@seanszarkowiczif you wrap your method calls on the httpclient in firstvaluefrom, then the interceptors should work fine.
@seanszarkowicz
@seanszarkowicz 9 ай бұрын
​@@PlerbyMcFlerbthanks for suggestion. yea but im trying not to have to do that sorta thing
@mauroavon7239
@mauroavon7239 9 ай бұрын
but those who use ngrx will have to continue to use rxjs and observables a lot for effects and selectors I imagine.. or can they use promises?
@AngularUniversity
@AngularUniversity 9 ай бұрын
You can use NgRx Signal Store, that uses async await but it has interoperabiblity with RxJs. I just finished recording a video for it on the channel, going live tomorrow 😉
@phuoctoanchauhuynh8557
@phuoctoanchauhuynh8557 9 ай бұрын
Can I ask you what server rendering side concept is is in Angular 17, why it has been provided, and what is it used for? I completed the update of your Angular Core Deep Dive with version 17, but I don't see the part that notices that. Thank you for sharing.
@AngularUniversity
@AngularUniversity 9 ай бұрын
SSR allows to create the initial HTML payload on the server. Then the client application takes over in the client as normal. 👍
@phuoctoanchauhuynh8557
@phuoctoanchauhuynh8557 9 ай бұрын
@@AngularUniversity Thanks for your response. I just wonder if we make the markup render on the server side it will take many resources of the server, maybe it will slow down the response and consume more bandwidth than the normal approach. If this is true, what benefit will we gain from the trade-off?
@AngularUniversity
@AngularUniversity 9 ай бұрын
@@phuoctoanchauhuynh8557 In principle the startup time is slightly faster, and the user sees content on the screen way faster. So from the point of view of the user it's better. You do need a Node server with some normal CPU and memory settings, I don't think anything special will be needed at the level of the server.
@tobias4096
@tobias4096 10 ай бұрын
One question regarding the async on ngOnInit: Won't using async here allow e.g. afterViewInit to run before you can be sure onInit is done?
@AngularUniversity
@AngularUniversity 10 ай бұрын
If you need to, you can add logic on ngOInit without async, and have it call an async function, that works too.
@stephendebeauchamp356
@stephendebeauchamp356 9 ай бұрын
nope, jumping from one foot to the other isn't something most companies I've worked for are okay with, the project uses RxJS so we'll stick to it as it's a clear path from there to signals and working with streams makes more sense for the patters we use, I appreciate the post, but I'm not going back to explaining async/await
@AngularUniversity
@AngularUniversity 9 ай бұрын
There is nothing to explain, it' trivial. Angular is making RxJs optional, you should prepare for a future with way less RxJs, if any at all.
@haroldpepete
@haroldpepete 9 ай бұрын
some people think angular is not using javascript behind the scene, when they look observable, subject, rxjs operator they think, wait a minute that's not javascript, that's something else
@AngularUniversity
@AngularUniversity 9 ай бұрын
It's just Javascript. 😉 You can use async/await with Angular as well, it's fully supported. 👍
@undefined-n5v
@undefined-n5v 10 ай бұрын
But I don't like promises anymore 😁
@AngularUniversity
@AngularUniversity 10 ай бұрын
RxJs will become optional in Angular in the future, so it's important to revisit them. Don't worry, they are way easier than Observables.
@KostasOreopoulos
@KostasOreopoulos 9 ай бұрын
I think he does not like non programming promises. It was figurative speech
@AngularUniversity
@AngularUniversity 9 ай бұрын
@@KostasOreopoulos 😂😉
@jimmyelkada166
@jimmyelkada166 Ай бұрын
The promises code is waaaaaay longer and less readable and maintainable ....
@gleitonfranco1260
@gleitonfranco1260 10 ай бұрын
Intellij highly dark theme ❓😲
@AngularUniversity
@AngularUniversity 10 ай бұрын
Yes it's the high contrast theme, not Darcula 👍
@g-luu
@g-luu 9 ай бұрын
I wouldn’t recommend anyone using angular to go the promise route. A lot of enterprise applications almost never use this approach. Keep it on personal projects like hobby projects i would say.
@AngularUniversity
@AngularUniversity 9 ай бұрын
Promises are standard in the enterprise for React or Node code, or just about anything else besides Angular. They work in Angular just as well.
@DuzyKucyk22
@DuzyKucyk22 9 ай бұрын
Vasco, I cannot believe that after learning angular from your great courses, and it's been like angular 6, I finally can disagree with or question your video. My feelings are that on the enterprise level, where everything is ngrx, you can forget promises even exist.
@asanast
@asanast 3 ай бұрын
I agree with that. I’ve been in some companies with Angular projects and I’ve never found promises, always Observables/Rxjs.
@alessandroaprile181
@alessandroaprile181 10 ай бұрын
mmm... i feel very confusing and unclean to use a second paradigm, promise, just to cover a particular case when rxjs already covers it..
@AngularUniversity
@AngularUniversity 10 ай бұрын
It's much easier to use, in general you can use Promises for most cases when it comes to HTTP. Using RxJs everywhere is like trying to use just a hammer to fix everything around the house. We have other tools on our toolbox that are much more suited for the job at hand 👍
@alessandroaprile181
@alessandroaprile181 9 ай бұрын
@@AngularUniversity well ok, _if you don't need the hammer already_. But if the complexity of your app is so low you don't need rxj, better use react.
@alessandroaprile181
@alessandroaprile181 9 ай бұрын
@@AngularUniversity i mean, ok of you need to exclude rxjs from the Build, but if you already had it, why don't use It at fullest?
@AngularUniversity
@AngularUniversity 9 ай бұрын
@@alessandroaprile181 React can be used to build apps as complex as Angular. The right tool for the job, it's all I'm saying in the video.
@AngularUniversity
@AngularUniversity 9 ай бұрын
@@alessandroaprile181 You can have multiple tools in your toolbox, use the most appropriate depending on the situation. You would use a hammer to fix a watch. 😊😉I understand where you come from, but it's mostly a myth.
💥 Angular Mistake #5: 🛑 STOP Overusing OnPush Change Detection
22:29
Lazy days…
00:24
Anwar Jibawi
Рет қаралды 8 МЛН
Thank you Santa
00:13
Nadir Show
Рет қаралды 54 МЛН
FOREVER BUNNY
00:14
Natan por Aí
Рет қаралды 38 МЛН
快乐总是短暂的!😂 #搞笑夫妻 #爱美食爱生活 #搞笑达人
00:14
朱大帅and依美姐
Рет қаралды 15 МЛН
When You Shouldn't Use Await Async in .NET
7:51
Nick Chapsas
Рет қаралды 44 М.
Why Angular Signals? Write Your First Signal
14:25
Angular University
Рет қаралды 15 М.
Angular | Implement Your Own Infinite Scroll In Less Than 20 minutes
16:43
Angular Resource API - Everything You Have To Know (so far)
27:58
Decoded Frontend
Рет қаралды 15 М.
RxJs Becoming Optional In Angular: Why and What's Next?
18:40
Angular University
Рет қаралды 6 М.
💥 Angular Mistakes #2: DON'T Overuse RxJs For Doing Simple HTTP #angular
14:03
Angular Mistakes #6: 🛑 STOP Overusing Centralized Stores
20:20
Angular University
Рет қаралды 6 М.
Windsurf vs Cursor: In-Depth AI Code Editor Comparison
18:14
Yifan - Beyond the Hype
Рет қаралды 10 М.
WTF is a HOT observable?
9:15
Joshua Morony
Рет қаралды 17 М.
Lazy days…
00:24
Anwar Jibawi
Рет қаралды 8 МЛН