I feel like an old grumpy man now. I truely love both `this` and the decorators. It makes reading and understanding location and purpose soo intuitive. One of the things i really miss when working in our MASSIVE monolithic c# backend, is the forced use of `this`. I have no idea, weather a variable is defiend, and possible changed on the partial parent class, of inside my method scope. And when some methods are 600 lines long, and parent object have 50 fields, it's nice to know what the scope of a field is... With @Input and @Output no longer needed (Or.. We're currently running angular 13, 14 & 15, so i can still use it with good conscience) , the purpose of the variable is no longer screamed in my face when i read the source code. Now i need to skim the entire end of RHS, instead of just the first character from LHS... :( 33 years, and ancient.. 😢
The input/output organisation is definitely something I miss (though I would still take the new input/output on the whole) - I do find myself wanting to use comments or at least gaps to more clearly delineate whats an input etc.
Curious on the fact your argument for createInjectable is mostly around only exposing public apis, and you don't like typescripts private modifier. why don't you just use an octothorpe (hash names), a native javascript :D
I don't have anything against the private modifier specifically, and I do use the private field syntax sometimes (TIL the hash symbol is technically called an octothorpe) - it's not so much a "man I hate typing the keyword "private" everywhere" it's more that it forces you to think specifically about what it is you want to expose since everything is private by default
hey Josh, when exploring the signalslice docs, what is the idiomatic way of performing a backend call? So i create an action source for a create new user command In the pipe on the action source, I can concatMap and perform a http request Either the httpRequest responds with a the new user json, or I could follow up this concatmap with a switchmap that loads the users from the backend. After that, I can map either of these responses to a Partial of the State. Is this the way of doing things? Any example or suggestion on how to deal with a failures in the http call to the backend? Use onError and switch to a stream that returns an error object which is then mapped to the state? I must say, it takes some time to start thinking in sources, but once you get it, the pattern is often the same. SignalSlice appears to remove even more boilerplate. Feels natural and forces you to colour within the declarative lines. I like it ❤
Sounds like you've pretty much got it - yes essentially the same way I am calling the async operation in the example in the video, actionSource -> switch to request -> map result to partial of state, and yes you can also use catchError to retry/return an observable that maps to the appropriate error state
I haven't properly tested in an actual application scenario yet with createInjectable, but there shouldn't be (spoiler: createInjectable actually just creates a standard injectable class under the hood)
I like it, have similar approach. There must be a space for experiments and a space for tested solutions. Thanks for all your content - very inspiring 👍
Where does signalslice differ from ngrx signalstore? What are the pro's of one over the other? They both seem to create / declare a sort of encapsulated service that manages some state and only expose particular functions to the outside world and all that with reactivity in mind. Or am I overlooking a difference?
Keep in mind this is coming from someone who hasn't actually properly used SignalStore yet (me), but the key philosophical difference imo is the focus on the more declarative model for signalSlice i.e. you can't patch state in signalSlice, only pre-defined sources can update the state. Also, and I don't know if it translates to actual bundle size differences or not and I don't think that's particularly important anyway, but signalSlice is more of a simple utility function rather than a more feature complete state management library I think SignalStore is great though, to be clear
For context, I believe that Joshua released his signalSlice utility before ngrx' signalStore. But obviously the main angular state management library couldn't passs on making a signal based approach (I mean that ngrx didn't copy or steal anything from Joshua ofc)
About the (ACF) Analog Component Format. 1. what are the benefits of using this in Angular? 2. what is deferent from Vue, Svelte? 3. why not use svelte or vue? I'm sorry if I seem like an Angular police. I just don't get this? Why would I use Analog if I don't get to use the Angular syntax?
To be brief: 1) less boilerplate, no loss of features (unless you specifically use OOP stuff) 2) everything else in Angular 3) same reasons I want to use Angular (the existing component authoring syntax is not why I use Angular)
@@JoshuaMorony Ok I see? For me I just use Astrojs for (static sites, websites), I use vuejs for small things like chrome extensions, but I don't like SFC, but it is great for that stuff. But for Enterprise or Large projects, I like Angular OOP.
@@sivuyilemagutywa5286 which OOP features specifically do you make use of in large projects? just curious, not trying to judge (and btw, "Analog SFC" components don't specifically need to be SFC, it also allows defining templates/styles in separate files if that is what you want)
@@sivuyilemagutywa5286 I think all those points you need are still there if you use Angular Single File Component? Each component in a single file is basically encapsulation, modularity and organisation. Nothing has changed conceptually. Just the way u write code is less boilerplate.
from my perspective, Signals just adds yet another chunk of learning curve and complexity to what is arguably already the most complex, most difficult framework out there. If Signals could actually replace RxJS, that would be one thing, but they can't - as you said, they only cover a subset of what you can do with Observables. So you still need to learn RxJS if you want to build anything bigger than a todo list. What they should have done instead is either (A) solve the ergonomic problems with RxJS, or (B) go all-in on Signals as a total replacement for everything you can do with RxJS. Just throwing Signals into the mix only puts off the learning you will eventually need to do anyway to build something substantial with Angular. This doesn't feel like a serious feature - it looks more like a marketing ploy to ride on the success of newer frameworks that go all-in on Signals. This might temp people to onboard Angular, but will likely still lead to the same amount of bafflement and overwhelm when, inevitably, they will need to reach for RxJS for something and we're right back where we were before: still the most difficult framework there is.
I just hate having a lot of dependencies inside constructur(), I looks quite ugly and kinda annoying for me, and also hate the super() (specially with many dependencies), so you just convinced. I'm switching to it. Thanks!
I personally started off with the vim extension on vscode, used it for basically all my projects for months, and I'm currently going through the neovim docs to try and completely switch to neovim.
If you need to retrieve the user information after a successful login, how would you chain the request to react to the "authenticated" status? Is it ok to put it inside the effect function?
Hi Joshua! Great content as always! Can you please help me with my issue? Im trying to upgrade an application from Angular 16 to 17, and the problem is with new SSR approach i get "localStorage is not defined" error. What would be the best solution for that? Wrapping all uses of localStorage in smth to use them on the client side, moving away from using localStaroage at all (i have it quite a lot in the project) or maybe something else will help?
I always enjoy your content and I completed your angular course but please SLOW down. It’s really hard to focus on what you’re doing or saying because it’s so damn fast.
Yeah, please more Videos about angular and Electron. Complex intercommunication and multiple renderer Prozesses in the background without a Window like vsc.
Some comments are taking this video as evidence that rxjs is bad (at least for this situation). But there's always multiple ways to do something, and maybe people might find something like this more intuitive: this.currentPhoto$ = zip(interval(500), from(value.reverse())).pipe( map(([intervalIndex, photo]) => photo) } Learning zip, interval, and from can be tricky, but the hardest one here is zip... and playing with the rxjs marbles diagram for it gives an intuitive understanding super quickly.
I haven't properly looked a Tauri, I'm just aware of its existence and Wails I hadn't actually heard of. I am learning Go at the moment though so could be interesting.
@@JoshuaMorony I fell into the Tauri hype train to try a demo app but found it a bit overkill for the benefit. Wails was more approachable but the docs are horendous.
IDK what happend but recently something shot to my mind that i need to build an electron app, then this happen! Thanks man! Definitely need more of this!
Is not worth it the hustle, I use for my clients Angular but I really don’t see the benefit of RxJS too nested and annoying. And I am not bad at RXJs but still don’t enjoy it
Constructive comment: I think you're going a way too fast. It is really hard to follow. This video should be twice as long. Do the same thing but in real time.
I always find electron very interesting but I always think what to build and what not to build, It would be nice to see a series starting with a good research about what to build what are the limitations etc, I always run to this channel to learn about the better way to do angulr apps heheh thx JM
