0:49 isn't calling a function in a template (as in count() and double()) something bad in newer Angular versions? (performance issues). I got told Angular calls these a lot of times because of how it works internally, for rendering purposes (and can be an issue with functions that do a lot of stuff). Maybe it's not really an issue?

Me too, can't wait to play around more!

Would like more if signals can also take care of the asynchronous values. No point in converting from observable to signals or vice versa. This makes things more complex.

Or even better - signals without RxJS.

I was thinking exactly the same. Would even go further to bring React Hooks into this as this looks like VueJS composition

Thanks for the kind words!

​@@JoshuaMorony Indeed the depth of your knowledge in Angular concepts is amazing. I have been working with Angular for the past 2 years too. But most time I wonder what I have to study next, I usually feel I'm lacking concepts in my angular knowledge. Please can you mentor me in Angular. Or have just 1 one on one session (Paid if necessary) to orient me on my study path to be among the best angular devs around

You missed the part that signals are not async

Signals are asynchronous.

Imperative code trying to mess with your declarative code: kzfaq.info/get/bejne/rtiXYLWYq5uqaKM.html

Funny enough react doesn't want to implement right now

There's a big discussion here if you want to check it out: github.com/angular/angular/discussions/49090

This doesn't change the justification for RxJS at all for me - RxJS is required (or something else that covers the same use cases it does) if you want to code declaratively and handle async reactivity. The only difference is that I would have also used RxJS for all sync reactivity as well, but if there is a framework primitive that can handle sync reactivity more easily that also interops with RxJS then it doesn't make much sense to me to not adopt it.

It won't be a video course, but I am working on a course that will incorporate all the new Angular goodies and teach the typical reactive/declarative style I advocate for

​​@@JoshuaMorony , Can't wait to see 👍

This is a great example, and exactly what I mean by "being dragged through the thorn bushes" to the other path

Yes, you can chain computed signals in the same way that you can with observables. I like to think of "the line" being async reactivity - if you don't need to explicitly handle async reactivity use signals, if you do use RxJS

Conceptually, A signal enables auto-tracking on Signal Read (eg: calling the signal function to get the current signal value). Imagine Components/Directives, the Template etc... have a "Reactive Context" where they can track Signal read, we could possibly have per-view/per-component Change Detection, combined with Angular's effective incremental DOM algorithm, the perf boost would be awesome. The current Change Detection would still trigger change from the root ApplicationRef so in a sense, your whole component tree is subject to be checked. OnPush Component prevents its subtree to be checked further but we still have a lot of unncessary checks. Signals w/ a "potential new CD Strategy" would help with this.

This blog has an interesting breakdown of overall Angular jobs and where to find them (overall, it's pretty close to React): www.devjobsscanner.com/blog/the-most-demanded-frontend-frameworks-in-2022/

Possibly less Angular jobs in your area may also mean less Angular devs in your area to compete with. In the React world there are more jobs but you're also competing against WAY more React devs.

I've been waiting patiently for someone to notice! lol

Heck yeah, I think it's time for everyone to jump back in!

Probably, it's hard to say now but I can't imagine this not becoming something that takes over completely. I know Brandon Roberts has already been toying around with integrating signals into NgRx.

Definitely plenty of inspiration and collaboration going on with other frameworks for this - the public facing API will likely end up looking pretty similar to other frameworks, but still a lot of work required behind the scenes to get it all working with Angular

It remains to be seen exactly how this will play out, but the Angular team have publicly talked about using signals for inputs

I love this, would be really exciting to see reactive inputs in Angular! The current way of passing the value of an input to a subject through a setter just feels so clunky.

Incredible, does this mean there’s no need for ngOnChanges? I very often have to take the Input and do something with it, with a pipe, or ngOnChanges

@@MiuBrothersOfficial I would assume so eventually yes, I can't see any need for ngOnChanges - if we have an input that is a signal and we want to do some kind of side effect equivalent to using ngOnChanges we could just define an "effect" and any signals we use in that effect (including the input) will automatically trigger that effect whenever they change

JSX/TSX is the only rescue for angular. But they won't allow that because they don't want to :D

@@RaVq91 what, I hate jsx and I'm pretty sure most angular dev do as well, can you explain why do you think this would be a "rescue" for angular. imo angular templates are far better than any other frameworks

@@nerminkarapandzic5176 Just first few things coming out of my head: hot module replacement - no need to reload the whole page and loose its state (values in inputs, etc), go to definition feature, find all references feature, rename of component will update names and imports in usages, typesafe components api even while writing its markup, easy way to create wrappers that exposes all the apis of wrapped component (not by rewriting all props by hand), full power of JS while writing views instead of html only.

It looks like it will be in v16, there is already a preview out under 16.0.0-next.1 for the initial/prototype implementation (still lacking features)

Yes we will likely have some sort of input signal

As in pipeable with RxJS operators? In the current implementation no, you would have to convert to an observable first, pipe, and then convert back to a signal. Personally, I'm hoping for the addition of some kind of "pipeable signal" or just a "pipe" method that will handle this signal -> observable -> signal conversion for you and pass in the operators to pipe to the observable.

​@@JoshuaMorony I literally just finished programming my own signals and then ended up watching your video (no kidding), what a timing. In my case it ends up being a parameterless function which when invoked returns the current value (imperatively), but which you can pipe and subscribe to directly (it literally has the pipe and subscribe method). I can even use them inside rxjs operators (like takeUntil) or use the async pipe in the templates thanks to the fact that rxjs provides a way of interop using a symbol.

If they are working on the signals I think they'll also consider 'computeds', their API is orders of magnitude better than NGRX's selectors since you don't need to tell it which other selectors it depends on, they are automatically detected when running, which also provides better ways of memoization as well as better strategies to how/when to recalculate them.

I would say it's a bit different to that - you can still using synchronous values/mechanisms and be reactive/declarative. It's better to think of imperative and declarative as being the opposites - but something can be reactive and imperative (e.g. using an observable subscribe or other mechanism to "imperatively" reassign/update a value after it has already been declared), or it can be reactive and declarative (e.g. using an observable/signal to define what something is once in the declaration and how it reacts to changes, and never imperatively reassigning that value).

With signals? Yes when it is implemented we will have some form of input signal

They are yet to be implemented, and the current prototype still relies on Zone.js, but yes the idea is that signals will eliminate the need for Zone.js (but Zone.js will still be an option for code that does not use signals)

Zone.js is here to stay for a while, at least until all of Google's Angular applications move away from Zone.js. In the mean time, Signals enables optional Zons.js aka in new projects, zone.js is not needed for perf boost and lower mental overhead

​@@ChauTran Hey Chau, I saw you on an Angular Community Meetup a couple of months ago, it was nice talk!

@@Mychelonn Thanks!

Yes, eventually. For now the prototype of signals still relies on Zone.js, but the Angular team is aiming to make Zone.js optional with a signal based approach at some point

The problem I'd to use RXJS you have to understand it almost expertly or you'll shoot yourself in the foot very badly, and unfortunately RXJS and Reactive Thinking are not just something you read about and get instantly for most people, you have to study and eventually your brain clicks. So you have to do all that and still learn Angular. At least with this you can on a surface level or within a couple minutes of reading docs get it and use. Signals will also highlight situations where RXJS is the best solution when people try and fail without it.

@@TayambaMwanza Totally agree. The library itself is great, but the learning curve is VERY painful. That's why I think other frameworks will take over Angular, because they are easier to learn :(

@@Dimonina So if Angular became easier to learn it would put it in a better position right? Which is what I think the team is doing, already seeing more people talking about Angular in a positive light than usual even from across the Isle. Then there was that post where for some reason since November Angular job postings have increased Dramatically

I'm not too familiar with Vue's implementation but these ideas across Vue/Solid/Knockout and now Angular are all quite similar in concept, and the APIs just about the same, just the underlying implementations are a bit different. It's certainly not a new or novel idea.

I'm not too familiar with Vue's implementation but these ideas across Vue/Solid/Knockout and now Angular are all quite similar in concept, and the APIs just about the same, just the underlying implementations are a bit different. It's certainly not a new or novel idea.

@@JoshuaMorony Thanks for clarifying

Solidular

Svelte a good choice for personal stuff or freelancing, but not there yet for getting hired as an employee

RX has a huge problem when using it on server said it's persistence and distribution. An interesting example of RX approach to stream processing is Microsoft Trill.

It does look similar, but the underlying ideas are quite a bit different. This is a good explainer on the difference: www.builder.io/blog/usesignal-is-the-future-of-web-frameworks

I never used Knockout but from what I have seen yes it does seem to have been a bit before its time