Комментарии:
Signals seem to be pretty much what knockoutjs did many years ago. Feels kinda weird cause that's what I used before angular, til 2018, 2019 xO Still I can see its benefits.
ОтветитьThis feels like knockout…
ОтветитьActually combineLatest example may be incorrect: derivedValue going to emit 20 after valueOne.next(2), but it’s going to happen before valueTwo.next(20), so there not going to be “transitional value” in this case
Ответитьon what basis did computed() wait for both values to be updated before computing. the changeValues() funciton to complete?
ОтветитьI love mobx and signals are just mobx rebranded
ОтветитьCould you avoid the double broadcast of combineLatest with a debounce operator (maybe if you anticipate sources updating "at the same time?"
ОтветитьSimple and effective super and well explained
ОтветитьThank you for posting this!
ОтветитьWe used to use ClearCase, and everytime I suggest git, people will say, ClearCase has all the same features and lot more, just check the docs and learn it properly. Kind of same with RxJs. Simplicity is under appreciated.
ОтветитьGreat comprehension, no shit talk just real coding and explanation, I liked it much.
ОтветитьGreat video I would like to see a video on how Signals is able to achieve glitch free computation.
ОтветитьVery nice explanation. Thank you
ОтветитьOk, I see signals are "glitchfree" but for our applications its okay to have those "glitches". The users can't see them and we love rxjs so we will stay with it. Once you got used to rxjs and it's power it immediately speeds up productivity and keeps the code very clean. Also I do not want to have a mix between signals und rxjs because it makes the code more complex 🤔
ОтветитьI noticed most people struggle with observables when they try to learn Angular and is often the reason people switch to other frameworks like vue or react.
ОтветитьNice explanation, thanks!
ОтветитьAs someone who is a huge fan of rxjs and tries to help jr devs at work write more reactive code, I love signals. It so simple to use and for people to understand after spending some time with it. I can't expect someone that's been working on Angular for a months to be as comfortable with rxjs as me whose been using it since Angular 2 first came out. Signals makes it so much easier to not fall back to the non reactive coding patterns that alot of jr devs usually do.
ОтветитьThank god. I was just beginning to learn RxJS and it was so difficult i quit for a bit. Now I"m going to learn Signals instead
ОтветитьActually - i like angular got signals a lot.. Good points - especially about rxjs and how it hinders angular adoption... it's always a pain to check all the rxjs code of beginners for all this stuff... signals will make development easier for so many...
ОтветитьRxJS and the concept of observables I think is the main reason new developers try to stay away from Angular. It is more of a new concept for most of us and you really need to learn it. Facing that big learning curve will surely intimidate devs who are new to Angular and will think Angular is full of shit and unnecessary complexities. I agree that it is a good thing to introduce Signals with Angular as it is way much simpler and straightforward. I use RxJS in all of my Angular projects for years now and I dont even utilize those complex operators in most of those projects(except for a few features and requirements). I find signals to be enough for my needs.
ОтветитьSo after 7 years Angular finally gets some DX... sorry but most of the world has moved on lol.
ОтветитьInteresting! A big difference I'm seeing is signals are synchronous while observables are asynchronous when you want to access a value, which has big implications. I guess I'll have to try signals in my next application. I would be tempted to use it in my current one, but that's going to be a big refactoring that I can't afford to do.
ОтветитьNot being able to get the latest value emitted by an observable is probably my greatest annoyance with RxJS. Sure, it's not something you should ever need in a purely reactive codebase, but a lot of the time you are not coding fully reactive, and in those cases it sucks to not have this basic feature.
ОтветитьI wonder how I can separate the changes in the effect, when which "signal" or "computed" has changed?
ОтветитьGreat info Joshua! Thank you for clarifying signals with real examples vs RxJS. It looks they are easier
ОтветитьAll "problems" (I would say side-effects) you mentioned are actually very EZ fixable in RxJS, so I it's not so cut and dry. However one has to have some experience to see those side-effects immediatelly during writing the code. Only real difference I can see is in writing less code out-of-the-box, which can be erased by writing one single cutom pipe and apply it anywhere you want. Then the practical difference is going to be mySignal vs my$.pipe(signalLike())...
Still, it's great to have that extra option as it makes Angular more approachable and predictable to newcomers
Nice Explained
ОтветитьThe average developer would have spent about 5 6 years learning the patterns of rxjs as well as its drawbacks and glitches. But now: time to throw that out the window and wait for some state management that uses signals instead of ngrx and refactor that. It's good. I make more money, I sound smart and trendy by using the latest trends, its all the dream of any developer 😂.
ОтветитьFireship rip-off?
ОтветитьGreat explanation, thank you!
ОтветитьI've learned a lot (everything) about RxJs watching your videos... Now that I understand 30% about it, Signals appears in the picture 😥
ОтветитьAm I the only one who knows that Angular is becoming similar to Vue?
ОтветитьWhile I agree that signals are easier alternative, I want to mention that your example during the side effects can be simply fixed by using shareReplay(1) method, that way your log will only trigger once
ОтветитьVery good and informative. I'm looking forward to getting stuck in to Angular 16
ОтветитьFun times ahead with more friction with state management justifiable with signals and side effects. Hopefully, this brings the community together and avoids class files with 40 mutated values in them, right? Nobody still? Ok cool.
ОтветитьThats exactly the video i needed to understand the purpose of these signals, thanks !
ОтветитьPractical video :) love it!
ОтветитьIO ♥ Rxjs
ОтветитьIt's a pretty handy utility, but I already see the overuse of signals and even more complex components.
ОтветитьWhat I'm missing here is the fact that these two serve to a different purpose. All these "issues" can be solved with operators, and with Signals new issues will pop-up, just as with computed properties in EmberJS. I see them more like RxJS being data provider and Signals used to deliver this data. Anyway good video
Ответитьthis is more like a demo of all the things wrong with RxJs and frontend dev 😂😂😂
ОтветитьHey, thanks for the great videos. I like your presentation of the material. May I ask what color scheme or theme you use in this video? Can you share?
ОтветитьSomething that you did not mention(unless I missed it): an effect(() => {...}) created inside a component gets destroyed automatically when the component gets destroyed, unlike RxJS where you need to unsubscribe/takeUntil.
Ответить