This approach looks very similar to ngrx/component-store. Thanks for the information. Its nice to see more content about angular signals as they will be the default.
thanks.... I was learning angular for a while and i thought i know enough angular until i found your channel..because i use it imperatively. I was learning these rxjs based approach for a while and signal occurs. It is hard to keepup with angular. Only if i was learning angular for long then these changes would feel good. But they are happening in mid of my journey.. it is what it is. btw thanks josh for sharing these approaches.
This is really cool! More reactive than pretty much anything I've seen without a library, but without the scan boilerplate. Honestly I was bothered that RxJS itself didn't come up with something better than the Subject + map + scan + switch statement + startWith + publishReplay + refCount approach, but I've been annoyed at RxJS' lack of focus on state in general. For a while people who loved RxJS didn't really understand when I complained about it, but signals are really strong where RxJS is weak, so they're seeing it now. Signals mostly replace the need for selectors in addition to RxJS... The signal in a service approach still isn't quite as good as custom hooks in React though, because the state is eternal. The subscriptions live forever, so HTTP requests aren't canceled or refetched automatically. React Query is very nice. But for not using a library, this is fantastic.
I was hoping you would stop by, was curious to hear what you'd think about it - and yeah the main goal here is to have something more basic to teach people where they have 100% visibility of the mechanics, that isn't too hard to grok, and that meshes philosophically with approaches you might transition to when adding libraries into the mix
@@JoshuaMorony finally a state management video that I want to try out irl, it's so simple but effective, most are so damn overcomplex and most of the time I have no idea on how to integrate it with firebase
I would be really interested in a video, that takes this concept a bit further. I would love to see how you would inplemteing pulling the data from an api and even more important, I would love to see how you would handle a reactive detail page (and service), that would get diffrent data depending on the item selected.
I could do another video - perhaps it might be interesting to do one purely focused on building with it rather than the theory. But there isn't anything too special here. The example in the video already does use an API to pull in data (although it is a simulated one using local storage, but it wouldn't make any differences) and generally anything you want to do would just involve deriving things from the state, or setting up a source to put data into the state.
I'm not a Angular Expert, so not sure if this is the right why, but may it helps you to use the MS Local Storage and an API combined: // sources private storedPortfolio$ = this.storageService.loadImageTable("portfolio"); private portfolio$ = this.portfolioDataAccessApiService.portfolioGet(); // data from LOCAL STORAGE if exits else from API const tableData$ = this.storedPortfolio$.pipe( switchMap(storeTable => { if (storeTable != null) { console.log('Data From Storage'); return of(storeTable); } else { console.log('Data From API'); return this.portfolio$; } }) );
After watching your video, I forked your repo, and ran the app. I had the idea to modify the reset feature. So, I made some minor changes and created a pull request. This would be the first time I've contributed to an opensource repo. Your Angular is more concise and you clearly have a strong grasp on the front end, still, maybe you will use the changes.
Glad to hear this was your first open source PR - thanks! I likely won't include your changes as I want to keep it consistent with any content I have on the code, but thanks for sending it through anyway
Hi Joshua thanks for your great content, I ve learned a lot from you over this last year. I was thinking on how signals are going to impact on the angular ecosystem, and I've concluded that the major change will be the transformation of properties into signals in our components. Surely this signals will end up receiving their values from observables, so we arent going to need in most cases the async pipe anymore. I think that the logic in services and store will surely remain the same (observable based) since its far more powerfull than having signals all over the application, by doing this you ve got the best of both worlds, reactivity and the ability to update an specific node of the DOM.
Joshua THANKS, for this greate video and idea!! I'm a backend programmer from origin, but programming frontend for some years now, so probably doing thinks i a way you shouldn't 🙂 This video got me the idee to create a generic version of the storage.service and a generic version of the checklist(item).service which use a generic gatewayservice to call api's or in my case to read JSON-files from the assets location to make a simple website more dynamic and changeable. The api call is done when the data isn't in the storage yet, where the storage data is cleared every .... Only thing no signal like is that you have to use a | null because you can't init a generic type, but a ngif fixes this problem quick easy. Yeah backend programmers love their generics 😅 Don't see them much used in frontend, works really well. Thanks again.
Hi Joshua, I really enjoy watching your videos as they are informative and educational. May I ask whether you have any advice on how to structure a large-scale Angular project? Possible you already have a video about it?
In general a lot of my vids are on various concepts that would scale to large apps, but maybe specifically you might be interested in my "structuring your Angular apps like a Googler" video
Thank you for the real nice presentations of all the topics. You can teach in a real good way! May i ask how / with what you create your diagrams / graphics?
What do you think about utilising ngrx’es component/store for these kind of operations? The api looks much cleaner for me. And the concept should be familiar for most of the devs
I like and use NgRx Component Store, although I've taken more of a liking to State Adapt at the moment, but the point of this exercise was to create an approach that could be used and taught without telling people to just install a 3rd party library which hides some of the concepts behind the scenes.
+1 Joshua's reply, plus using the "write" part of @ngrx/component-store isn't really that declarative. Introducing method like ``` add(movie: string) { this.moviesStore.addMovie({ name: movie, id: generateId() }); } ``` is inviting imperative code to sneak in.
i found a potential problem with using a state signal. on 2:30 where you show the selectors for the state, you can see, that the computed signals update always when the state updates, even if its value is not changing. when debugging i found that angular does stop the same value from propagating through the signal only when its a primative datatype. so objects and arrays for example will always trigger the signal and cause rerendering for example or further computations..
This will depend on what version of Angular you are using - I'm not sure this is all 100% finalised yet but the Angular team removed the mutate method from signals and changed the default equality function when comparing signal values, which gets rid of the problem you are talking about. As far as I know this will be the final API, but either way you can supply your own equality function for the computed to fix this (i.e. you can supply Object.is as the equality function if it is not the default)
Thank you for your video. It was the video I was looking to change my approach. I am like you, don’t want to use RxJs or NgRx, elf or other store management. Complicates, lots of boiler plates and our project is relatively small. Lately i use Facade patterns with Observable state. Then using VM$ with combineLatest all the Facade State/Store variables to be more easily used with one general ASYNC pipe. That work OK, but little complicated and lots of code. I think you apprach fit very well in my FacadeService. I can use signal store and share it with my component. No need for Asyn pipe anymore.
hey Joshua, been following your vids for a while and directing people here because they are amazing. what do you think of the toSignal utilities and why was it not chosen? I've been trying to move away from NGRX while still replicating the pattern, the reducers having to reduce all of the state when any event affects just one or two props seems overkill and your tests would have to accommodate for that. i.e. my event emitted, check I've only touched the 2 props that i told it to touch my approach is to put private state = { prop: signal(), checklist: toSignal(checklistSource$) ... } selector = { computed(...) } actions = { someAction: () => state.prop.update() } a. this groups all of the similar processes, makes it easier to scan the code and see what's available b. those actions will only touch relevant pieces of data within your state c. no subscribes right now, i'm still stuck on ng14 so they're all behaviorSubjects still so perhaps you can drop some insights
The main reason there is no use of toSignal in my example is just to facilitate that reducer step which is basically servicing as a toSignal. Having multiple signals within the state rather than just one signal for the entire state was something I considered (and hinted at in the video) though my motivation for that was more around having more granular changes for the sake of the upcoming change detection changes. The only problems I have with your actions set up, and why I wanted to use observables instead as the actions/sources, is what I describe for my reasoning of not using just callback methods in the video (nothing else can react to someAction being triggered) and we might fire the same action/source more than once with the same data, and we might want to react to that, but signal effects won't trigger if the data hasn't changed
A detail i'd like to understand better is, as you are in a service, which usually isn't destroyed (unless provided directly in the component), what's the reference for the takeUntilDestroyed pipe that will stop the subscription if you don't need this service anymore, let's say if you go in another part of the application where the subscription becomes obsolete ? That's a concern i usually have in Angular projects where an app can have very different interfaces with specific functionalities and you don't want to start subscriptions all over the places that will become potential memory leaks. If you've addressed this issue in other videos, i'd be happy with the name or a link for it. Thanks.
If the service is provided in root then yes it is just going to exist throughout the life of the application so takeUntilDestroyed isn't technically required in that case - however your service might be destroyed if, as you mentioned, it's provided directly to a component. Personally, I just like having a rule of always having an unsubscribe strategy from any manual subscription even if it won't really matter (but you might, for example, refactor the service/change it from providedIn root but forget to now add subscription clean up and now you have a problem)
I am guessing this is just for tutorial purposes, you could cancel by adding some extra code via takeUntil and passing it a subject that will emit a boolean to tell the subscription to end but that will also make you have to initialise the subscription again when you need it, I mean if nothing triggers actions and their effects, I don't see a problem with leaving that subscription on, but if we get stuck with many of these subscriptions, that's where we might have a problem.
So theoretically, when you have a standalone component where the service is provided directly to the component, and in the component you have a subscribe with takeUntilDestroyed pipe, it should be fine?
@@joostjansen1094 well it depends, if you don't want to have the subscription take effect while the component is not generated yet, then yes, but at the same time you need to keep in mind that now every instance of that component will have its own subscription. I would always suggest to find the easiest way at the start to get things up and running correctly then optimize your case depending on your usage.
Thanks for your videos. That's really nice to see. Have 2 questions: 1) Is it ok that domain-related state (checklist-items service) is providedIn: root? Also, shared state depends on this domain-related state. May cause some issues, i guess 2) What are your thoughts about dependencies between domains. For example I need some selector(piece of data) in domain A from domain B? Injecting one state into another may cause circular deps. Interesting to get your point regarding that THANK YOU!
1) This could probably be refactored out now as well but it's never really been much of a concern to me 2) I don't think specifically in domains, for me if it is only used by the feature it belongs with that feature and if it is accessed outside of that feature it goes in the shared folder - and perhaps I just haven't hit high enough complexity but I've never had any trouble with circular dependencies so haven't given it much thought
Ayyy, you should make sure that people can only remove by using a single method via encapsulation. Then it's very declarative. I think it's probably easier to do the same with signals.
Hey Joshua, I like thi approach a lot. I'm implementing it in a new project im working on. Quick question: How should we deal with services that depend upon other services. For example if I want to inject inside the same component a service C that depends on service A and B (and use some state from them in the http call), I cannot do it because when I inject them all of them get initialized at the same time. The only way of doing this that I could come up with was creating another child component that only renders when service A and B load properly and inject service C in there. Do you know of a better way of doing this or even doing it inside the same component? Thank you so much for all of your content, looking forward to your full Angular course.
Hey bro, sorry for someone who is new into signals, this is somewhat hard to follow. maybe you could make another video where you go into the details of this implementation and explain why we are doing it, what we are trying to achieve, and why you decided to implement this approach?
This is sort of the end result of a bunch of different concepts I've been talking about on the channel recently (mostly declarative/reactive code, signals, and RxJS) - a single video that goes into sufficient detail without requiring any other context would be too long imo, I will be writing longer form content on this stuff though.
I can only agree with @jeffnikelson5824: When i first learned angular I started with mutating observables to promises to avoid those subscribtions, then i learned rxjs and just finished an enterprise level production app (team of 4 devs + product owner) using BehaviourSubjects and async pipe in template to subscribe to those. I'm okay with this approach but after that 3 new concepts appeared: First: Signals: I didn't like those too much because it is not a complete substitution for rxjs. As far as i remember You said, that signals can replace 80% or 90% of rxjs, but one still has to learn rxjs for the missing 20%-10% async code. Second: StateAdapt library: this was way over my head, since i didnt even learn ngrx because angular's services have always been sufficient for the requirements we had to fulfil. Another point I don't like about StateAdapt, which is quite obvious, is that it's a third party library maintained by one (?) developer, so it's probably not a good fit for our company's needs: enterprise level stable code base. Last: This video I like more since You present a stable/pure/angular only approach maintained by the whole angular team, hence it fits enterprise level. But again, since You've lost me on the signal's video already, this combination of signal's + ngrx-like store architecture is way above me. However i rly like the no callbacks, pure declarations only approach, i hope that You can expand more on this topic, maybe - as You've just replied - with a longer article or a more detailed video for "noobs" to migrate from the "rxjs subjects/template async pipe"-architecture to this new "signal/ngrx-like store without callbacks" approach. Hopefully i'll be able to catch up soon and the next production app my team and me code is using this new approach (in case it's your "final call", maybe in some weeks You'll have another solution...). Thank You a lot for all Your effort, im watching each new video You post and im always happy when i click on the youtube bell and see that a new video on Your channel is available
I haven’t tested this since before the Angular 16 release, but at one time, updating any state property resulted in the selectors firing again for every state property even if that property didn’t change. That’s because in the selectors, I referenced this.state() the same way you did here. Does this still happen? When you update any state property, do all of the selectors emit?
If you have a computed signal (which is how I'm creating the selectors here) it won't trigger anything unless the value has changed - so if the value of a computed derived from the state was 2, then the state updates, and the value of the computed is still 2 anyway then nothing will happen to it
I wonder will Angular expand on signals to have more built in features for managing state. So many devs try to figure out the best library for state, and angular is a batteries included framework so it would make sense for the framework to include more state features.
I think the Angular team's approach in general is to provide the tools but let the community decide on patterns etc, so I don't think they will provide some opinionated form of state management
I'm curious, if building a big app, that will evolve and be maintained by 6 developers full time on it the next 5-8 years, what library would you use? we especially value to be able to make isolated unit tests, to ensure an action mutates properly the states and everything but we would like to be sure it does integrate with signals and is not too heavy.
I'm in fact using this pattern but in the others way. The state of my smart component is one computed signal contains one big object contains the signal value from the selector (one selector = one signal(...))
Thanks! Yes they are all scripted, I used to do more ad-hoc videos but found I added too many tangents/fluff and videos ended up being way longer than they needed to be
Thank youso much for sharing, I really learned a lot. I am currently in the process of adapting my codebase to this style, but I am struggling with migrating my data services. Currently they follow a similar structure to your "service with a subject" appraoach. My question is: How to use this kind of approach if the data from the services is not soley used for representative use, but also for business logic. I am stuck where I before had a method to get some async data as an observable and could use the data when the stream provided it in the subscribe, now I return signals which may or may not have the data (yet). This is fine in representative situations, where I can just ignore the fact and get on with the setup, but what if I need to do something with the data from my service? Do I use an effect? That solution leads to many indirections when I try, because the effect needs to be defined in an injection scope, wheras the retrieval of the data may not be in that same place. I.E. it is triggered by a user interaction? I feel like I'm missing something. I want the public API of my services to consist of signals only, now that we can. Maybe you could include an example, where you do more with your data than only displaying it. Maybe use it to create and prefill a reactive form, or fetch some more data to enrich it from another REST-Api Endpoint? Anyways, I love your content and thanks for all the effort you put into it.
Do you have an example repo you could share of what you are trying to do (the original non-signals versions)? I'm happy to take a look and give my opinion
I know the idea is to not use any third party libraries and be beginner-friendly, but do you think it's beneficial to use this instead of just ngrx? I liked the pattern, I'm just wondering if, in a real application for a company, there is anything to gain with this approach against those other options. Great video btw, I'm coming from a React background and learning a lot about Angular with your videos!
This approach does have some differences in concept to NgRx (although it is very close) - StateAdapt is what it is more closely modelled after so I will answer in terms of that. I think generally there is at least some benefit to not using a library, like not having a dependence on that library, but mostly I would use this approach by default because it feels lower friction and leaves the ability to migrate if necessary. If doing a refactor for a larger project or creating a project you knew was going to be significant, the benefits of something like StateAdapt might be more attractive - things like the ability to share the adapter logic and integration with Redux dev tools. I don't think there are any real limitations with this approach, but there could certainly be built in features of larger libraries that are attractive in certain situations.
Hey Good video, thanks! by the way, Doy you use Vscode editor? if so can you tell me which extensions do you use for the icons and the editor? I would really appreciate that.
Great video. How about initial state using signals. Does the initialization of the init state trigger events before data exists, like subscribing to RxJs BehaviorSubjects?
Hey Josh, great video. I have a question, might be a bit silly, but when you are managing statue without a third party lib and we manage it as you showed or before signals with a Behaviour Subject and a service at what point do we actually persist the state to the backend?
It's sort of a separate concern and depends - for example in this app I have a simple storage mechanism, I just have an effect that listens for whenever the local data changes and it will save all the data to local storage. When the app loads, it just pulls in a copy of that data. But in another scenario you might have a set up where when something is added (say a comment is created) it would send that comment to the backend to be saved in the DB, and then your app might receive the updated data because it has a stream of data coming from the backend (that updates on changes). Or maybe it doesn't and you have to have some kind of manual refresh for the data. There's a lot of different ways this could go and largely depends on what kind of tech you are using.
Im trying to simulate a signal base component. I'm using transform function to transform every input in signal. It is working perfectly for the reactivity when I call the signal directly in the template, but when I try to use a computed signal from the input or an effect, it doesn't work. Any idea why ?
I've really been struggling with project structure and state lately... it all seems to end up a mess. ngrx was boilerplate mayhem... so I ripped that out... now trying just services... this helps... but man.. I keep wanting to fall back into just putting a bunch of imperative code right in the component... services seem to spread the logic out over multiple files and seems more confusing to me.
the effect causes a save call to backend on every refresh. How to avoid that ? Is your service localStorage? How would you implement that with database API
Yes this is localStorage, for an example with a remote backend here's another example (the save/add is triggered as part of the RxJS stream: github.com/joshuamorony/angularstart-chat/blob/main/src/app/shared/data-access/message.service.ts)
Something I ve learned for sure there is no wrong or right it s all about preferences. What do matters is the performance which approach is more effective and performant that s the question I rather put than making a religion out of it.
In general I would like to say that you do a great job and I love to see your videos and ways to solve problems. But I also have to say that I‘m a bit disappointed by the solution provided in this video. Not saying that I have a better solution so far. But all the time the recommended approach was to handle observables directly in the template by async pipe and that subscribing mannually is kind of an anti pattern and should be avoided… and now exactly that should be the best solution🤔 thats really surprising to me….
That's basically the cost of having this state management lib style "state object" (a signal in this case) as the service level - everything can be reactive from that point onward (i.e. no manual subscribes etc), but you still need to imperatively set that state in the first place. This is the kind of thing that is generally hidden away in libraries behind the scenes (i.e. NgRx does the same thing). There are other things you can do here (which I sort of cover in the video) but imo this strikes a nice balance between ease of use/understanding and declarative/reactive purity
@@JoshuaMorony thank for your quick response! Maybe you can compare 1-2 other ways of handling this use case, compared to the „none lib style“ from this video. Keep it up! :)
I think this is pretty good. It is hard to look past the subscribes after all the time being told to despise them. I wish there was a way to combine Angular’s takeUntilDestroyed operator with subscribe so you can’t forget to use both. I love rxjs, I wish Angular collaborated more with their team. I take it you thought through converting the observables to signals, inside the service or the component. I suppose that would make all subscribes be Signal Effects. But I’m sure there’s overhead, and having to think of events as synchronous.
It would be cool, and probably quite feasible to have something like ".safeSubscribe()" or something which is basically a wrapper around a normal subscribe + takeUntilDestroyed. The biggest problem I had with a more signal oriented approach was just that observables are just a better fit for events, which is what these sources are dealing with. I'm sure it'd be possible to set it up with signals, but then we have awkward stuff like an effect not running because the value a signal was updated with was the same as the last value, which is something we might actually want to do with an event. So the approach I went with felt like a more natural way for both observables and signals to do what they do best.
Hey Joshua nice video! But I have a question according to your manual subscribe in the angular services - isn´t it bad practice at all, to subscribe within an angular service and shouldn´t it get unsubscribed somehow? Further it would be very interesting, to see, how you would solve, the exact same problems/ same application WITH a state management library like NgRx in combination with signals. Another thing which could be interesting, is your opinion, to the solution provided in this video from Manfred Steyer: ua-cam.com/video/7wfwlAIY4jE/v-deo.html "the best of both worlds" as he says. I think it´s a mixed approach. Would be nice to hear from you! Have a good day! ;-)
Hey - all of these are unsubscribed, I'm using the takeUntilDestroyed operator so if the service is provided to a component it will be destroyed when the component is - if it's provided in root then it is going to go on running (which is expected). I've done this same scenario with StateAdapt in a previous video, but I haven't done this specific example with NgRx since signals have come along. I'd need time to catch up on Manfred's video (I'm sure it's great though)
@@JoshuaMorony oh damn didn´t see this - perfect! Ok cool, i will check out this video too :) Sure, that needs time, but could be an idea for another cool video ;-) Thanks a lot for your quick response! You do a fantastic job, proper respect! 👌
All those subscriptions, pipes, etc... Why not just have a method add(), update(), edit() that does the job? Feel's like doing the same thing but in an overly complicated way.
@@RenanLeandroFerreira I touch on this in the video, and you could do it that way if you want, but the reason I didn't is for those reactive/declarative reasons. If I have an add$ subject, anything can react to that emitting data anywhere in the app - you just fire the data off in one place and everything else reacts automatically. If you instead use an add() method, now nothing can react to that method being called so everything needs to be handled in the add() method itself (or it needs to fire off some other kind of notificiation mechanism)
So, KISS principle. IF you ever need someone to react to that add(), then you just add an emiter to this componente and do an emit in the end of the add method... I still cannot see those so called advantages on the declarative... And, It has a bunch of downsides
@@RenanLeandroFerreira simplicity is what I am chasing, and the reactive/declarative approach provides that imo because you just have the data your app depends on, and everything reacts automatically whenever any of that data, or anything derived from it, changes. Without having to wire up additional imperative calls to trigger things whenever you want to do something. Yes there is a question around whether whatever patterns or abstractions you implement are actually useful enough to justify the effort but, especially with the set up I have in this video, imo there isn't much additional work required (really the only extra boilerplate here is having the extra takeUntil/subscribe for each source, which could otherwise have been just a normal method) and if anything I think it just helps add additional organisation/clarity.
Join my mailing list for more exclusive content and access to the archive of my private tips of the week: mobirony.ck.page/4a331b9076
This approach looks very similar to ngrx/component-store. Thanks for the information. Its nice to see more content about angular signals as they will be the default.
Thanks for sharing. It's always great to see what someone else is thinking.
This is such a good way of utilizing rxjs/signals for state management. Clean and easy to understand. Great job!
thanks....
I was learning angular for a while and i thought i know enough angular until i found your channel..because i use it imperatively.
I was learning these rxjs based approach for a while and signal occurs.
It is hard to keepup with angular.
Only if i was learning angular for long then these changes would feel good. But they are happening in mid of my journey.. it is what it is.
btw thanks josh for sharing these approaches.
This is really cool! More reactive than pretty much anything I've seen without a library, but without the scan boilerplate. Honestly I was bothered that RxJS itself didn't come up with something better than the Subject + map + scan + switch statement + startWith + publishReplay + refCount approach, but I've been annoyed at RxJS' lack of focus on state in general. For a while people who loved RxJS didn't really understand when I complained about it, but signals are really strong where RxJS is weak, so they're seeing it now. Signals mostly replace the need for selectors in addition to RxJS...
The signal in a service approach still isn't quite as good as custom hooks in React though, because the state is eternal. The subscriptions live forever, so HTTP requests aren't canceled or refetched automatically. React Query is very nice. But for not using a library, this is fantastic.
I was hoping you would stop by, was curious to hear what you'd think about it - and yeah the main goal here is to have something more basic to teach people where they have 100% visibility of the mechanics, that isn't too hard to grok, and that meshes philosophically with approaches you might transition to when adding libraries into the mix
@@JoshuaMorony finally a state management video that I want to try out irl, it's so simple but effective, most are so damn overcomplex and most of the time I have no idea on how to integrate it with firebase
Thanks Man, Love that you always support your point with the corresponding source code
I would be really interested in a video, that takes this concept a bit further. I would love to see how you would inplemteing pulling the data from an api and even more important, I would love to see how you would handle a reactive detail page (and service), that would get diffrent data depending on the item selected.
I could do another video - perhaps it might be interesting to do one purely focused on building with it rather than the theory. But there isn't anything too special here. The example in the video already does use an API to pull in data (although it is a simulated one using local storage, but it wouldn't make any differences) and generally anything you want to do would just involve deriving things from the state, or setting up a source to put data into the state.
I'm not a Angular Expert, so not sure if this is the right why, but may it helps you to use the MS Local Storage and an API combined:
// sources
private storedPortfolio$ = this.storageService.loadImageTable("portfolio");
private portfolio$ = this.portfolioDataAccessApiService.portfolioGet();
// data from LOCAL STORAGE if exits else from API
const tableData$ = this.storedPortfolio$.pipe(
switchMap(storeTable => {
if (storeTable != null) {
console.log('Data From Storage');
return of(storeTable);
} else {
console.log('Data From API');
return this.portfolio$;
}
})
);
// reducers
tableData$.pipe(takeUntilDestroyed()).subscribe({
next: (table) =>
this.state.update((state) => ({
...state,
table,
loaded: true,
})),
error: (err) => this.state.update((state) => ({ ...state, error: err }))
});
// effects
effect(() => {
if (this.loaded()) {
this.storageService.saveImageTable("portfolio", this.table());
}
});
After watching your video, I forked your repo, and ran the app. I had the idea to modify the reset feature. So, I made some minor changes and created a pull request. This would be the first time I've contributed to an opensource repo. Your Angular is more concise and you clearly have a strong grasp on the front end, still, maybe you will use the changes.
Glad to hear this was your first open source PR - thanks! I likely won't include your changes as I want to keep it consistent with any content I have on the code, but thanks for sending it through anyway
Hi Joshua thanks for your great content, I ve learned a lot from you over this last year. I was thinking on how signals are going to impact on the angular ecosystem, and I've concluded that the major change will be the transformation of properties into signals in our components. Surely this signals will end up receiving their values from observables, so we arent going to need in most cases the async pipe anymore. I think that the logic in services and store will surely remain the same (observable based) since its far more powerfull than having signals all over the application, by doing this you ve got the best of both worlds, reactivity and the ability to update an specific node of the DOM.
I generally agree, for most apps I work on this is how I imagine I will be approaching observables/signals
Joshua THANKS, for this greate video and idea!!
I'm a backend programmer from origin, but programming frontend for some years now, so probably doing thinks i a way you shouldn't 🙂
This video got me the idee to create a generic version of the storage.service and a generic version of the checklist(item).service which use a generic gatewayservice to call api's or in my case to read JSON-files from the assets location to make a simple website more dynamic and changeable. The api call is done when the data isn't in the storage yet, where the storage data is cleared every ....
Only thing no signal like is that you have to use a | null because you can't init a generic type, but a ngif fixes this problem quick easy.
Yeah backend programmers love their generics 😅
Don't see them much used in frontend, works really well.
Thanks again.
I really like the new possibilities offered by signals and takeuntildestroyed, and I'm looking forwards to signal based components.
Hi Joshua, I really enjoy watching your videos as they are informative and educational. May I ask whether you have any advice on how to structure a large-scale Angular project? Possible you already have a video about it?
In general a lot of my vids are on various concepts that would scale to large apps, but maybe specifically you might be interested in my "structuring your Angular apps like a Googler" video
Thank you for the real nice presentations of all the topics. You can teach in a real good way! May i ask how / with what you create your diagrams / graphics?
What do you think about utilising ngrx’es component/store for these kind of operations?
The api looks much cleaner for me. And the concept should be familiar for most of the devs
I like and use NgRx Component Store, although I've taken more of a liking to State Adapt at the moment, but the point of this exercise was to create an approach that could be used and taught without telling people to just install a 3rd party library which hides some of the concepts behind the scenes.
+1 Joshua's reply, plus using the "write" part of @ngrx/component-store isn't really that declarative. Introducing method like
```
add(movie: string) {
this.moviesStore.addMovie({ name: movie, id: generateId() });
}
```
is inviting imperative code to sneak in.
i found a potential problem with using a state signal. on 2:30 where you show the selectors for the state, you can see, that the computed signals update always when the state updates, even if its value is not changing.
when debugging i found that angular does stop the same value from propagating through the signal only when its a primative datatype. so objects and arrays for example will always trigger the signal and cause rerendering for example or further computations..
This will depend on what version of Angular you are using - I'm not sure this is all 100% finalised yet but the Angular team removed the mutate method from signals and changed the default equality function when comparing signal values, which gets rid of the problem you are talking about. As far as I know this will be the final API, but either way you can supply your own equality function for the computed to fix this (i.e. you can supply Object.is as the equality function if it is not the default)
@@JoshuaMorony alright, sounds legit, will try. (the project im working on currently uses v16.2)
Thank you for your video. It was the video I was looking to change my approach. I am like you, don’t want to use RxJs or NgRx, elf or other store management. Complicates, lots of boiler plates and our project is relatively small.
Lately i use Facade patterns with Observable state. Then using VM$ with combineLatest all the Facade State/Store variables to be more easily used with one general ASYNC pipe. That work OK, but little complicated and lots of code. I think you apprach fit very well in my FacadeService. I can use signal store and share it with my component. No need for Asyn pipe anymore.
hey Joshua, been following your vids for a while and directing people here because they are amazing.
what do you think of the toSignal utilities and why was it not chosen?
I've been trying to move away from NGRX while still replicating the pattern, the reducers having to reduce all of the state when any event affects just one or two props seems overkill and your tests would have to accommodate for that. i.e. my event emitted, check I've only touched the 2 props that i told it to touch
my approach is to put
private state = { prop: signal(), checklist: toSignal(checklistSource$) ... }
selector = { computed(...) }
actions = { someAction: () => state.prop.update() }
a. this groups all of the similar processes, makes it easier to scan the code and see what's available
b. those actions will only touch relevant pieces of data within your state
c. no subscribes
right now, i'm still stuck on ng14 so they're all behaviorSubjects still so perhaps you can drop some insights
The main reason there is no use of toSignal in my example is just to facilitate that reducer step which is basically servicing as a toSignal. Having multiple signals within the state rather than just one signal for the entire state was something I considered (and hinted at in the video) though my motivation for that was more around having more granular changes for the sake of the upcoming change detection changes.
The only problems I have with your actions set up, and why I wanted to use observables instead as the actions/sources, is what I describe for my reasoning of not using just callback methods in the video (nothing else can react to someAction being triggered) and we might fire the same action/source more than once with the same data, and we might want to react to that, but signal effects won't trigger if the data hasn't changed
@@JoshuaMorony interesting note about reacting to same data, i'll try to keep that in mind, keep up the good work :)
such a great video !! Thankss!
A detail i'd like to understand better is, as you are in a service, which usually isn't destroyed (unless provided directly in the component), what's the reference for the takeUntilDestroyed pipe that will stop the subscription if you don't need this service anymore, let's say if you go in another part of the application where the subscription becomes obsolete ?
That's a concern i usually have in Angular projects where an app can have very different interfaces with specific functionalities and you don't want to start subscriptions all over the places that will become potential memory leaks. If you've addressed this issue in other videos, i'd be happy with the name or a link for it. Thanks.
If the service is provided in root then yes it is just going to exist throughout the life of the application so takeUntilDestroyed isn't technically required in that case - however your service might be destroyed if, as you mentioned, it's provided directly to a component. Personally, I just like having a rule of always having an unsubscribe strategy from any manual subscription even if it won't really matter (but you might, for example, refactor the service/change it from providedIn root but forget to now add subscription clean up and now you have a problem)
I am guessing this is just for tutorial purposes, you could cancel by adding some extra code via takeUntil and passing it a subject that will emit a boolean to tell the subscription to end but that will also make you have to initialise the subscription again when you need it, I mean if nothing triggers actions and their effects, I don't see a problem with leaving that subscription on, but if we get stuck with many of these subscriptions, that's where we might have a problem.
So theoretically, when you have a standalone component where the service is provided directly to the component, and in the component you have a subscribe with takeUntilDestroyed pipe, it should be fine?
@@joostjansen1094 well it depends, if you don't want to have the subscription take effect while the component is not generated yet, then yes, but at the same time you need to keep in mind that now every instance of that component will have its own subscription. I would always suggest to find the easiest way at the start to get things up and running correctly then optimize your case depending on your usage.
Thanks for your videos. That's really nice to see. Have 2 questions:
1) Is it ok that domain-related state (checklist-items service) is providedIn: root? Also, shared state depends on this domain-related state. May cause some issues, i guess
2) What are your thoughts about dependencies between domains. For example I need some selector(piece of data) in domain A from domain B? Injecting one state into another may cause circular deps. Interesting to get your point regarding that
THANK YOU!
1) This could probably be refactored out now as well but it's never really been much of a concern to me 2) I don't think specifically in domains, for me if it is only used by the feature it belongs with that feature and if it is accessed outside of that feature it goes in the shared folder - and perhaps I just haven't hit high enough complexity but I've never had any trouble with circular dependencies so haven't given it much thought
Ayyy, you should make sure that people can only remove by using a single method via encapsulation. Then it's very declarative. I think it's probably easier to do the same with signals.
Can you give an example?
Hey Joshua, I like thi approach a lot. I'm implementing it in a new project im working on.
Quick question: How should we deal with services that depend upon other services. For example if I want to inject inside the same component a service C that depends on service A and B (and use some state from them in the http call), I cannot do it because when I inject them all of them get initialized at the same time. The only way of doing this that I could come up with was creating another child component that only renders when service A and B load properly and inject service C in there. Do you know of a better way of doing this or even doing it inside the same component?
Thank you so much for all of your content, looking forward to your full Angular course.
Hey bro, sorry for someone who is new into signals, this is somewhat hard to follow. maybe you could make another video where you go into the details of this implementation and explain why we are doing it, what we are trying to achieve, and why you decided to implement this approach?
This is sort of the end result of a bunch of different concepts I've been talking about on the channel recently (mostly declarative/reactive code, signals, and RxJS) - a single video that goes into sufficient detail without requiring any other context would be too long imo, I will be writing longer form content on this stuff though.
I can only agree with @jeffnikelson5824: When i first learned angular I started with mutating observables to promises to avoid those subscribtions, then i learned rxjs and just finished an enterprise level production app (team of 4 devs + product owner) using BehaviourSubjects and async pipe in template to subscribe to those. I'm okay with this approach but after that 3 new concepts appeared:
First: Signals: I didn't like those too much because it is not a complete substitution for rxjs. As far as i remember You said, that signals can replace 80% or 90% of rxjs, but one still has to learn rxjs for the missing 20%-10% async code.
Second: StateAdapt library: this was way over my head, since i didnt even learn ngrx because angular's services have always been sufficient for the requirements we had to fulfil. Another point I don't like about StateAdapt, which is quite obvious, is that it's a third party library maintained by one (?) developer, so it's probably not a good fit for our company's needs: enterprise level stable code base.
Last: This video I like more since You present a stable/pure/angular only approach maintained by the whole angular team, hence it fits enterprise level. But again, since You've lost me on the signal's video already, this combination of signal's + ngrx-like store architecture is way above me. However i rly like the no callbacks, pure declarations only approach, i hope that You can expand more on this topic, maybe - as You've just replied - with a longer article or a more detailed video for "noobs" to migrate from the "rxjs subjects/template async pipe"-architecture to this new "signal/ngrx-like store without callbacks" approach. Hopefully i'll be able to catch up soon and the next production app my team and me code is using this new approach (in case it's your "final call", maybe in some weeks You'll have another solution...).
Thank You a lot for all Your effort, im watching each new video You post and im always happy when i click on the youtube bell and see that a new video on Your channel is available
@@JoshuaMorony yea i think a full blown signals video should wait till signals are fully introduced anyway... they could change
I haven’t tested this since before the Angular 16 release, but at one time, updating any state property resulted in the selectors firing again for every state property even if that property didn’t change. That’s because in the selectors, I referenced this.state() the same way you did here. Does this still happen? When you update any state property, do all of the selectors emit?
If you have a computed signal (which is how I'm creating the selectors here) it won't trigger anything unless the value has changed - so if the value of a computed derived from the state was 2, then the state updates, and the value of the computed is still 2 anyway then nothing will happen to it
I wonder will Angular expand on signals to have more built in features for managing state.
So many devs try to figure out the best library for state, and angular is a batteries included framework so it would make sense for the framework to include more state features.
I think the Angular team's approach in general is to provide the tools but let the community decide on patterns etc, so I don't think they will provide some opinionated form of state management
I'm curious, if building a big app, that will evolve and be maintained by 6 developers full time on it the next 5-8 years, what library would you use? we especially value to be able to make isolated unit tests, to ensure an action mutates properly the states and everything but we would like to be sure it does integrate with signals and is not too heavy.
I'm in fact using this pattern but in the others way. The state of my smart component is one computed signal contains one big object contains the signal value from the selector (one selector = one signal(...))
I like your videos! Do you script them?
Thanks! Yes they are all scripted, I used to do more ad-hoc videos but found I added too many tangents/fluff and videos ended up being way longer than they needed to be
Thank youso much for sharing, I really learned a lot.
I am currently in the process of adapting my codebase to this style, but I am struggling with migrating my data services.
Currently they follow a similar structure to your "service with a subject" appraoach.
My question is: How to use this kind of approach if the data from the services is not soley used for representative use, but also for business logic.
I am stuck where I before had a method to get some async data as an observable and could use the data when the stream provided it in the subscribe, now I return signals which may or may not have the data (yet).
This is fine in representative situations, where I can just ignore the fact and get on with the setup, but what if I need to do something with the data from my service?
Do I use an effect? That solution leads to many indirections when I try, because the effect needs to be defined in an injection scope, wheras the retrieval of the data may not be in that same place. I.E. it is triggered by a user interaction?
I feel like I'm missing something. I want the public API of my services to consist of signals only, now that we can.
Maybe you could include an example, where you do more with your data than only displaying it. Maybe use it to create and prefill a reactive form, or fetch some more data to enrich it from another REST-Api Endpoint?
Anyways, I love your content and thanks for all the effort you put into it.
Do you have an example repo you could share of what you are trying to do (the original non-signals versions)? I'm happy to take a look and give my opinion
I know the idea is to not use any third party libraries and be beginner-friendly, but do you think it's beneficial to use this instead of just ngrx? I liked the pattern, I'm just wondering if, in a real application for a company, there is anything to gain with this approach against those other options.
Great video btw, I'm coming from a React background and learning a lot about Angular with your videos!
This approach does have some differences in concept to NgRx (although it is very close) - StateAdapt is what it is more closely modelled after so I will answer in terms of that. I think generally there is at least some benefit to not using a library, like not having a dependence on that library, but mostly I would use this approach by default because it feels lower friction and leaves the ability to migrate if necessary. If doing a refactor for a larger project or creating a project you knew was going to be significant, the benefits of something like StateAdapt might be more attractive - things like the ability to share the adapter logic and integration with Redux dev tools.
I don't think there are any real limitations with this approach, but there could certainly be built in features of larger libraries that are attractive in certain situations.
Hey Good video, thanks! by the way, Doy you use Vscode editor? if so can you tell me which extensions do you use for the icons and the editor? I would really appreciate that.
I'm using Neovim with the gruvbox theme and you can find my config here if you're interested: github.com/joshuamorony/nvim
Great video. How about initial state using signals. Does the initialization of the init state trigger events before data exists, like subscribing to RxJs BehaviorSubjects?
Could you give an example of what you mean?
Hey Josh, great video. I have a question, might be a bit silly, but when you are managing statue without a third party lib and we manage it as you showed or before signals with a Behaviour Subject and a service at what point do we actually persist the state to the backend?
It's sort of a separate concern and depends - for example in this app I have a simple storage mechanism, I just have an effect that listens for whenever the local data changes and it will save all the data to local storage. When the app loads, it just pulls in a copy of that data. But in another scenario you might have a set up where when something is added (say a comment is created) it would send that comment to the backend to be saved in the DB, and then your app might receive the updated data because it has a stream of data coming from the backend (that updates on changes). Or maybe it doesn't and you have to have some kind of manual refresh for the data. There's a lot of different ways this could go and largely depends on what kind of tech you are using.
@@JoshuaMorony Makes sense. Thanks for taking the time to explain!
Im trying to simulate a signal base component. I'm using transform function to transform every input in signal. It is working perfectly for the reactivity when I call the signal directly in the template, but when I try to use a computed signal from the input or an effect, it doesn't work. Any idea why ?
I've really been struggling with project structure and state lately... it all seems to end up a mess. ngrx was boilerplate mayhem... so I ripped that out... now trying just services... this helps... but man.. I keep wanting to fall back into just putting a bunch of imperative code right in the component... services seem to spread the logic out over multiple files and seems more confusing to me.
the effect causes a save call to backend on every refresh. How to avoid that ? Is your service localStorage? How would you implement that with database API
Yes this is localStorage, for an example with a remote backend here's another example (the save/add is triggered as part of the RxJS stream: github.com/joshuamorony/angularstart-chat/blob/main/src/app/shared/data-access/message.service.ts)
How do you document your angular application? Do you use compodoc?
Man, u re using vim/neovim ?, Can I take a look at ut setup for angular? especially the treesitter one ?
Yes and sure: github.com/joshuamorony/nvim
@@JoshuaMorony thanks man.
Something I ve learned for sure there is no wrong or right it s all about preferences. What do matters is the performance which approach is more effective and performant that s the question I rather put than making a religion out of it.
In general I would like to say that you do a great job and I love to see your videos and ways to solve problems. But I also have to say that I‘m a bit disappointed by the solution provided in this video. Not saying that I have a better solution so far. But all the time the recommended approach was to handle observables directly in the template by async pipe and that subscribing mannually is kind of an anti pattern and should be avoided… and now exactly that should be the best solution🤔 thats really surprising to me….
That's basically the cost of having this state management lib style "state object" (a signal in this case) as the service level - everything can be reactive from that point onward (i.e. no manual subscribes etc), but you still need to imperatively set that state in the first place. This is the kind of thing that is generally hidden away in libraries behind the scenes (i.e. NgRx does the same thing). There are other things you can do here (which I sort of cover in the video) but imo this strikes a nice balance between ease of use/understanding and declarative/reactive purity
@@JoshuaMorony thank for your quick response! Maybe you can compare 1-2 other ways of handling this use case, compared to the „none lib style“ from this video. Keep it up! :)
when to use observables, signals or normal variables? what type of situation is best suited for each case?
A full video will be appreciated if you code infront of us with both approach.
I think this is pretty good. It is hard to look past the subscribes after all the time being told to despise them. I wish there was a way to combine Angular’s takeUntilDestroyed operator with subscribe so you can’t forget to use both. I love rxjs, I wish Angular collaborated more with their team.
I take it you thought through converting the observables to signals, inside the service or the component. I suppose that would make all subscribes be Signal Effects. But I’m sure there’s overhead, and having to think of events as synchronous.
It would be cool, and probably quite feasible to have something like ".safeSubscribe()" or something which is basically a wrapper around a normal subscribe + takeUntilDestroyed. The biggest problem I had with a more signal oriented approach was just that observables are just a better fit for events, which is what these sources are dealing with. I'm sure it'd be possible to set it up with signals, but then we have awkward stuff like an effect not running because the value a signal was updated with was the same as the last value, which is something we might actually want to do with an event. So the approach I went with felt like a more natural way for both observables and signals to do what they do best.
angular is also a big third party lib
Hey Joshua nice video! But I have a question according to your manual subscribe in the angular services - isn´t it bad practice at all, to subscribe within an angular service and shouldn´t it get unsubscribed somehow? Further it would be very interesting, to see, how you would solve, the exact same problems/ same application WITH a state management library like NgRx in combination with signals. Another thing which could be interesting, is your opinion, to the solution provided in this video from Manfred Steyer: ua-cam.com/video/7wfwlAIY4jE/v-deo.html "the best of both worlds" as he says. I think it´s a mixed approach. Would be nice to hear from you! Have a good day! ;-)
Hey - all of these are unsubscribed, I'm using the takeUntilDestroyed operator so if the service is provided to a component it will be destroyed when the component is - if it's provided in root then it is going to go on running (which is expected). I've done this same scenario with StateAdapt in a previous video, but I haven't done this specific example with NgRx since signals have come along.
I'd need time to catch up on Manfred's video (I'm sure it's great though)
@@JoshuaMorony oh damn didn´t see this - perfect! Ok cool, i will check out this video too :) Sure, that needs time, but could be an idea for another cool video ;-) Thanks a lot for your quick response! You do a fantastic job, proper respect! 👌
lmfao the absolute state of angular
lol so putting changes at the top of the hierarchy is........ jquery.
I tried, but this declarative is terrible IMHO...
All those subscriptions, pipes, etc...
Why not just have a method add(), update(), edit() that does the job?
Feel's like doing the same thing but in an overly complicated way.
@@RenanLeandroFerreira I touch on this in the video, and you could do it that way if you want, but the reason I didn't is for those reactive/declarative reasons. If I have an add$ subject, anything can react to that emitting data anywhere in the app - you just fire the data off in one place and everything else reacts automatically. If you instead use an add() method, now nothing can react to that method being called so everything needs to be handled in the add() method itself (or it needs to fire off some other kind of notificiation mechanism)
So, KISS principle. IF you ever need someone to react to that add(), then you just add an emiter to this componente and do an emit in the end of the add method... I still cannot see those so called advantages on the declarative... And, It has a bunch of downsides
BTW, not criticizing you or your videos. I like your content. Just raising some discussion here
@@RenanLeandroFerreira simplicity is what I am chasing, and the reactive/declarative approach provides that imo because you just have the data your app depends on, and everything reacts automatically whenever any of that data, or anything derived from it, changes. Without having to wire up additional imperative calls to trigger things whenever you want to do something. Yes there is a question around whether whatever patterns or abstractions you implement are actually useful enough to justify the effort but, especially with the set up I have in this video, imo there isn't much additional work required (really the only extra boilerplate here is having the extra takeUntil/subscribe for each source, which could otherwise have been just a normal method) and if anything I think it just helps add additional organisation/clarity.
Everyday Angular is coming with something New...Old things are already Too Much to learn...Now these things are making me Very 😔🥲
I am a big big ngrx/store fanboy and I love the way they have embraced signals.
I Love Angular(Fanboy). But my company won't touch anything but React. 🥲🥲🥲