Very, very interesting. I'm really excited to see how the community will develop this workflow. Not only it will greatly reduce minimal app size because you don't need zone.js, but I believe this way of doing it is also a lot simpler to understand than zone.js. Less "black magic" and a lot more of core Rx concepts applied. Concise, elegant, less error prone (if we develop a simpler workflow) and can provide more granular control of "rendering" (sometimes you can't avoid it).
@@artemeelemann317 Well, his proposal is a much smaller foot print. 2 separate data streams get combined into one. The dom that requires the second data piece will not always render because the first data piece comes in. So you make that dom dependant on that piece of data...Which forces you to rewrite your data to conform to say an object. And now you have action dispatch pattern you have to enforce on two disparate pieces of data. you could probably use it the observable to update a class attribute but then you'd end up withe same amount of code now as you had with method 2 (controller based observer management) Whereas, he is proposing that each variable is reactive and you call that render on just an ngIf in the view template. Its harder to make bad code with his protototype. If you want to nitpick, I would go for the fact that everybody wants to be that final class which is why he recommends integration with akita. This is a data component level final class and not a layout final class. You'd most likely wrap your ui library with a data-reactive-component and serve it into a layout view Its a lot less code. But i doubt anyone is going to work this into production code. No one is going to turn off ngzone globally. The main problem is component level control of rerender is going to be more performant than service level control of rerender. Writing acode to batch aync code properly for performance is a friggin chore. rather than this, i would like to see more support for custom ChangeDetectionStrategy or increased options. ChangeDetectionStrategy.OnCustom({rerenderOnAsyncOps: false}) that's step 1 . Reactive Component Library is step 2.
HOCs have some limitations, one of theme is multiple class inheritance, in React world for that case composition has comes and HOC’s works as expected, that’s is more suitable for functional paradigm but Angular is on the OOP way and I suppose it is more fashion way to apply props through annotation decorators @connect()
Yes, it will unsubscribe automatically… once the call will be completed, but it is better to do it onDestroy as in this case it will unsubscribe exactly onDestroy and cancel all pending requests
@@marianbencat6658 I do not see what you mean. Unsubscription is handled in success / error case automatically. Of course calling the unsubscribe method is useful when yout have to cancel an "in progress" HTTP request
@@MAKU011111 read it again and slowly... - yes, unsubscription is handled in success / error case - yes, when request ENDS with success / error - WHEN REQUEST ENDS - so if requests takes 30 sec, you are leaking resources for 30sec. MEMORY LEAK: - not freed resources when not needed anymore - try to subscribe in a component to 30sec (or timeout) lasting request and go BACK and THERE 30times... = you will need 30x more resources + YOU WILL LISTEN 30times except once.
@@marianbencat6658 yeah I get you point. But this example is very constructed.... In general I would not handle the unsubscription of http calls (but thats my personal opinion - but also heard on several occasions from others)
Very, very interesting. I'm really excited to see how the community will develop this workflow. Not only it will greatly reduce minimal app size because you don't need zone.js, but I believe this way of doing it is also a lot simpler to understand than zone.js. Less "black magic" and a lot more of core Rx concepts applied. Concise, elegant, less error prone (if we develop a simpler workflow) and can provide more granular control of "rendering" (sometimes you can't avoid it).
Beautiful. This will be incredibly elegant when complete.
you don't have to unsub from the core angular observables (like from HttpClient), because Angular itself handles that
Ruslan Kardashev yes this ss what every tutorial says. If subscribing from angular components, they are auto unsub.
Yeah http observables complete after delivery
I was just asking myself, why does he subscribe for http request?? And I see your comment 😁
This video is GOLD.
Fantastic talk, Mike!
I don't understand: for the first problem, why would you not simply use the "share" operator?
Yeah! Why nobody told this guy that the share operator exists :D
@@artemeelemann317 Well, his proposal is a much smaller foot print.
2 separate data streams get combined into one. The dom that requires the second data piece will not always render because the first data piece comes in.
So you make that dom dependant on that piece of data...Which forces you to rewrite your data to conform to say an object.
And now you have action dispatch pattern you have to enforce on two disparate pieces of data. you could probably use it the observable to update a class attribute but then you'd end up withe same amount of code now as you had with method 2 (controller based observer management)
Whereas, he is proposing that each variable is reactive and you call that render on just an ngIf in the view template. Its harder to make bad code with his protototype.
If you want to nitpick, I would go for the fact that everybody wants to be that final class which is why he recommends integration with akita.
This is a data component level final class and not a layout final class.
You'd most likely wrap your ui library with a data-reactive-component and serve it into a layout view
Its a lot less code. But i doubt anyone is going to work this into production code. No one is going to turn off ngzone globally.
The main problem is component level control of rerender is going to be more performant than service level control of rerender.
Writing acode to batch aync code properly for performance is a friggin chore.
rather than this, i would like to see more support for custom ChangeDetectionStrategy or increased options.
ChangeDetectionStrategy.OnCustom({rerenderOnAsyncOps: false})
that's step 1 .
Reactive Component Library is step 2.
Amazing talk
Mind blown - this is epic stuff
imho it's over-engineering
Amazing. Thanks for talk
The approach is awesome
Have there been any updates on this effort?
Anyone used it in practice?
Wow excellent talk!
Woo Great talk!!!!!!!
I am happy to see this direction, however, I got one question - why copy-paste react solutions instead of using react then?
legacy projects? 🤷♂️
@@marcialabrahantes3369 you can use react in angular in such case still and step by step replace. React is just a lib.
Michael Hladky: "hold my beer"
IVY + no zone.js is amazing but please, lets make this happen without HOCs, zoneless async pipe or anything else
What's wrong with HOCs? They are awesome for lots of things... form elements for instance
@@LarsRyeJeppesen One prime reason why React made the hooks api is to get rid of the HOC pattern
@@hamzabenkhaldoun ok thanks
HOCs have some limitations, one of theme is multiple class inheritance, in React world for that case composition has comes and HOC’s works as expected, that’s is more suitable for functional paradigm but Angular is on the OOP way and I suppose it is more fashion way to apply props through annotation decorators @connect()
ngIf don`t work with enabled ivy
Can't bind to 'ngIf' since it isn't a known property of 'div'.
did you import CommonModule?
httpClient will automatically unsubscribes once received, Isn't it? Do we need to manually unsubscribe it ??
Yes, it will unsubscribe automatically… once the call will be completed, but it is better to do it onDestroy as in this case it will unsubscribe exactly onDestroy and cancel all pending requests
Why is Angular not following this approach? Is it pride not to have invented it! Are Google's developer not able to think in RxJs terms?
You do not need to unsubscribe from a subscription you get from HttpClient (as mentioned at 24:09)
Yeah, there is no memory leak as mentioned at 1:57. But you might still want to unsubscribe so the subscribe callback doesn't get called.
you HAVE TO, else, you may get tons of memory leaks and strange behavior when your requests take longer than expected (30sec request time)
@@marianbencat6658 I do not see what you mean. Unsubscription is handled in success / error case automatically. Of course calling the unsubscribe method is useful when yout have to cancel an "in progress" HTTP request
@@MAKU011111 read it again and slowly...
- yes, unsubscription is handled in success / error case
- yes, when request ENDS with success / error
- WHEN REQUEST ENDS - so if requests takes 30 sec, you are leaking resources for 30sec.
MEMORY LEAK:
- not freed resources when not needed anymore
- try to subscribe in a component to 30sec (or timeout) lasting request and go BACK and THERE 30times...
= you will need 30x more resources + YOU WILL LISTEN 30times except once.
@@marianbencat6658 yeah I get you point. But this example is very constructed.... In general I would not handle the unsubscription of http calls (but thats my personal opinion - but also heard on several occasions from others)
I understood nothing!!