A Redux-like Pattern for Managing State with Angular signals

[@DiogoFaFab]

Your channel is a hidden gem! I love how you explain Angular. Thanks a lot for sharing such valuable content!

[@deborah_kurata]

That is so kind of you to say. Thank you! 😊

[@AlexLikeGolf]

This video is what I was looking for. I am currently using the Basic Store approach for State Management, and this video is perfect for my migration to Signals.

[@deborah_kurata]

Excellent! I'm happy it was helpful. 😊

[@advance5189]

Marvelous! You know I’m so thrilled that I came across your channel. I’m sure you help many devs to refresh previous knowledge and polish up our skills. Keep it up!

[@deborah_kurata]

Thank you! 😊

[@patrickcameron2950]

I'm so happy I stumbled across this channel. You are a fantastic programmer and teacher. Thank you for making these videos!

[@patrickcameron2950]

So happy I found this channel. You are a fantastic programmer and teacher and you've greatly helped me improve my Angular skills.

[@deborah_kurata]

That is wonderful to hear. Thank you so much! 😊

[@turboheadcrab666]

I love seeing new Angular Signals content. Looking forward to more pattern videos from you and completely zoneless approaches from the Angular dev team after they are done with Signal based forms. Thank you for what you do!

[@deborah_kurata]

Thank you! Have you seen my zoneless video here: kzbin.info/www/bejne/g4uZpGh7gZybgc0 And yes! Anxiously awaiting to see what comes of signal-based forms!

[@AnthonyDev]

I like to use state pattern, specially with Flutter, but now I can use it with Angular! I'm waiting for the next videos! Thanks, Deborah!

[@deborah_kurata]

Thanks for watching! I'm curious, why can't you use a state pattern with Angular?

[@wildflo1492]

Why not use tanstack query and remove a lot of the boiler plate code of redux pattern

[@fmontes83]

Love this approach! Redux-like for the win!

[@deborah_kurata]

😊

[@pavelernestonavarroguerrer7871]

I loved it!! So clean and simple! Thanks!!

[@deborah_kurata]

Great to hear. Thank you!

[@Matrium0]

Great explanation, even when I am not a fan of the Redux pattern. Though if you are absolutely set to implement the pattern, this is a very clean way and readable way to do it, with not that much boilerplate. So at least it helps (at least a little bit) with my two biggest concerns with NgRx: readability/maintainability and high-code-cost.

[@deborah_kurata]

Thank you! Have you looked a signalStore?

[@HealmaTech]

I like it raw, and this is one of the best!

[@deborah_kurata]

Thank you!

[@juliojimenez450]

Another great video that is no longer a surprise! What a wonderful series on angular signals! My dream would be a medium-high level course on developing a real project in Angular 18! 😄 If one day you do it don't doubt that I will be the first to buy it! Keep it up!😉

[@deborah_kurata]

Thank you for the kind words! I've been considering whether to do a course and if so what it would look like. Thanks for your suggestion.

[@sebafra9768]

Great Deborah! Thanks a lot

[@deborah_kurata]

Glad it was helpful! 😊

[@KushanShanuka]

great tute, im really interesting about this, and now im waiting for the state update feature, by the way thanks a lot for sharing deborah

[@deborah_kurata]

Thank you! And thanks for the reminder!

[@ythalorossy]

It is amazing.... I was doing something similar without thinking about patterns. I need to review all my code and adjust to this pattern.

[@deborah_kurata]

Excellent!

[@flywheel56]

I like your approach of illustrating cognates to the familiar NGRX pattern. I hope you'll soon do the same in relation to the new SignalStore.

[@deborah_kurata]

Thank you! And great idea!

[@xEnergyGamingHD]

Learned so much, Thank you!

[@deborah_kurata]

So glad! Thank you for watching!

[@codeSurvivor]

I really like this pattern, thanks for the video. Kudos to Josh Morony for creating it for Angular, as far as I know.. It would have been nice to mention that somewhere. The way you apply it, is nice but in a way you kind of break the pattern when using the filteredTodos computed signal instead of defining an action explicitly, IMO Also I prefer not using tap, and define derived streams and subscribe to them, to be more compliant with the flux pattern in which you change the state at the end of an action

[@deborah_kurata]

Thank you! Yes, I have seen Josh's videos on this topic. They are great. And I could have mentioned them as another reference. (I think I will add at least one of them to the links area of this video. Thanks for the suggestion. And do you have a suggestion for one in particular that I should reference?) But just FYI ... it seems that NgRx used this pattern way before Josh did. The graphic I used in my video was from my Pluralsight NgRx course back in 2018 (updated in 2020). You can find it here: www.pluralsight.com/library/courses/angular-ngrx-getting-started Also yes that we could take this pattern further and use explicit actions. That is how NgRx implements it.

[@Matrium0]

I used to like Josh's content too, but nowadays I feel like he is too much of a functional programming extremist. For the the golden path is somewhere in the middle. If the functional solution has 10 times higher code cost for worse readability (and therefor maintainability) I would rather stick with an imperative approach or a mixture. Though his video about error handling with the async pipe are great and a real eye-opener. For me it made me actually use async pipe far less, because he made me realize how ugly good functional-style error handling really get's when usync that pipe. This is something that most content creators here often forget, only showing people the "happy path". So I guess what I am saying is that I have mixed feeling about his content.

[@codeSurvivor]

@@deborah_kurata Hey! thanks for your answer! I answered a couple of days ago but it was never published, maybe KZbin doesn't allow comments with links. Yep, I suggest Morony's "A New Reactive And Declarative Approach to Angular State Management" blog post. I won't share the link to make sure this comment is published. I didn't mean that the flux patter was applied to Angular by Josh Morony, I meant the signals/rxjs bridge pattern that is explained in the blog post I suggested. Thanks for your job, Deborah, I'm really a fan, specially of your slower pace and clarity!

[@deborah_kurata]

@@codeSurvivor It does appear that YT allows me to publish links but not anyone else. 🤷🏼‍♀ Thanks for the suggested link. I'll add it to the links for this video. And thank you so much for the kind words! ☺

[@DraaElMizan]

Thanks for Sharing Deborah. Another great tut.

[@deborah_kurata]

Thanks for watching! 😊

[@f1amesoff]

And what if a component needs to change the state, but the component itself depends on this state?

[@deborah_kurata]

Can you give me an example so I can better picture your scenario?

[@raknjarasoa]

At 02:55 for initialState, why currentMember is initialized with undefined whereas error is set to null ? I personally tend to use only null for data that I have the control. WDYT ?

[@deborah_kurata]

Regarding currentMember, I like to use undefined because when the application starts the value is literally undefined. It doesn't become defined until the user picks one. Regarding error, I was trying to show a number of different data types. There was no reason beyond that. Error could be set to undefined, null, or just empty string depending on your team's preferences.

[@raknjarasoa]

@@deborah_kurataThanks. You’re awesome 😎

[@Hunter-3bs7]

Fantastic work, Deborah Kurata! Thank you for these videos that help us take our skills to the next level. I was hoping you could make a video discussing when, where, and why to use access modifiers like private, readonly, and protected in an Angular web app. If you have any references on this topic, that would be greatly appreciated. Thanks!

[@deborah_kurata]

Thanks! Great suggestion! I'll add it to my list. 😊

[@Khatter_Saab]

Hey Hi I Started Learning Angular from your videos on Plural Sight. I wish I will meet you one day :) Thanks

[@deborah_kurata]

Thank you so much! I am often at conferences. If you attend one, please introduce yourself! 😊

[@richarddefortune1329]

Great video (as usually). I love the patterns you added to mimic "selectors". I didn't like the way it's presented in the NGRX documentation, where the store is accessible on the HTML template. If you haven't recorded the next video yet, is there a way to talk a little more about the store itself and concepts, such as initialValue, withMethods, withComputed, rxjMethod(), and so forth. I'm glad you recorded this video as I was trying to understand NGRX store by reading the documentation. After watching your video, I will write a small project. Thank you so much.

[@deborah_kurata]

Thank you for watching! I'm considering doing a video on signalStore in the future.

[@richarddefortune1329]

@@deborah_kurata I think I was confused. I thought this was signal store. After watching the video a second time, I realized that you're using signals to mimic the NGRX store. I'm so glad you made this video. This means I don't need to wait until the "signal store" is no longer experimental for the project we're working on. We'll use as much as signals we can. You're the best angular teacher. Thank you so much 🙏

[@deborah_kurata]

Great! Glad it was helpful.

[@EmilioDegiovanni]

Great video Deborah! Thanks

[@deborah_kurata]

Thanks for watching! 😊

[@tiberseptim7183]

Thanks for the video. I noticed several problems: 1. Subscription in Root service is unti-pattern, cause it will live forever. 2. You need to complete subjects always in onDestroy. Anyway, looking at all this boilerplate, one thinks hard before implementing ngrx-like store. Usually you don't need it at all )

[@dsfgato]

legend

[@dsfgato]

what's your GitHub account? wanna learn from you

[@deborah_kurata]

Hope it was at least interesting if not entirely useful for you. 😊 1. In this particular case, we want the subscription to last forever (or at least for the life of the application) because it's what makes the application work. If this was instead a small part of a larger application, we could move the service registration to the component itself. Then it would be destroyed when the component was destroyed. (This topic may be worth a separate video?) 2. You don't need to complete a subject in onDestroy if you use the TakeUntilDestroyed. It will complete the subject when the service is destroyed.

[@tiberseptim7183]

​@@deborah_kurata yes, I think separate video about subjects completion in case of error, difference between complete() and unsubscribe() may be quite useful. I agree, with takeUntilDestroyed you don't need to complete subject. But anyway, in this particular case it's useless, cause service is provided in root. UPD. still there are some doubts. When you use takeUntilDestroyed, it ends only subscriptions. But there can still be references to Subject in Subscription object returned by 'subscribe()'. The question is - can the Subject be garbage collected if you do not manually complete it?

[@CK_SUN]

Why not effect?

[@GuillermoArellano]

I like this pattern. It incorporates many of the known redux patterns used in NgRx into self-contained services. Unfortunately, I am having a hard time time understanding how we would merge upwards into a single service. Let's say we have orders and products features that each have services with state; how do we bubble up the state in each upwards to a singleton service?

[@deborah_kurata]

Thank you! As soon as you have more complex state, I'd recommend using a library (such as SignalStore) for state management. This pattern is great for simple apps (and as a mental exercise to understand how many of the state management libraries work). But it doesn't truly scale. If you did want to/need to do it, however, my first thought is that you would define the state in individual interfaces that extend the basic app state (like you do for NgRx). export interface State extends AppState.State { products: ProductState; } Individual services would then set the initial state and define their own slices of that state.

[@iuliusciorica282]

Thank you, love your content!

[@deborah_kurata]

That's great to hear. Thanks!

[@YesDiscovery]

The pattern is excellent. Is there a way to use NgRx and Signal together effectively?

[@deborah_kurata]

Yep! The latest versions of NgRx are signal-based: dev.to/ngrx/announcing-ngrx-signals-v18-state-encapsulation-private-store-members-enhanced-entity-management-and-more-2lo6

[@YesDiscovery]

@@deborah_kurata Thank you!

[@brtk7]

Do tou recommended using this technique as you described or rxjs signal store?

[@deborah_kurata]

As with everything in programming ... it depends. 😊 If the application is small or if there is some reason you can't use signal store (like a government project), then this technique works great. Otherwise, the signal store (or other state library) are often a better choice. In any case, these are useful concepts to know (and the pattern closely matches with NgRx).

[@Brendan2Alexander]

Excellent Deborah! Do u need to unsubscribe when a subscription exists in a service scoped as a singleton?

[@deborah_kurata]

Thanks! It's normally good practice to always unsubscribe if you subscribe. That way if someone later changes the scope of the service, it's unsubscribed. Or if someone adds some teardown code (saving current preferences/state on exit for example) that code will be executed. But the "because you'll get memory leaks" does not apply in that case. 😊

[@dsfgato]

Great content! Cheers.

[@deborah_kurata]

Thank you so much!

[@ДенисВишневский-т6и]

Don't you think that signalStore will be better for this case, do you?

[@deborah_kurata]

Yes! I had intended to mention that in the video and then accidentally omitted it. signalStore is a better option. The only advantage that I see this has over signalStore is that it doesn't require a third party state library. (Which may matter to some enterprises.)

[@CodingAbroad]

Could this completely replaxe ngrx in your opinion?

[@deborah_kurata]

For simple applications, yes. For more complex applications and for large teams, probably no. And ngRx, and of course signalStore, are becoming more signal based.

[@spewberg]

There's any difference between hard code like you did and using a ngrx signal store?

[@deborah_kurata]

signalStore is a better option. The only advantage that I see this has over signalStore is that it doesn't require a third party state library. (Which may matter to some enterprises or governments.) I had intended to mention that in the video and then accidentally omitted it.

[@EvertonCanez]

Deborah, I love your videos, but I can't help thinking that simply using the same old usual Rxjs + async pipe approach would save much more boilerplate code in this case. What do you think about this?

[@deborah_kurata]

Thank you so much! 😊 The answer depends on the complexity of the application. For more straightforward applications, a more straightforward approach makes sense. But if you get very complex applications, sometimes more organization is required. And a suggestion ... as the Angular team is moving toward basing change detection on signals, it will be more important to communicate between the component code and template with signals (not the async pipe).

[@angelocolacicco997]

Could we say that... with the power of signlas and rxjs together, we don't need ngex anymore? hope it could be so. I hate ngrx

[@deborah_kurata]

It depends on the application. Anything complex and these manual techniques become a little unwieldy. That's when NgRx really shines. The makers of NgRx also have SignalStore, which is a much more scaled down library that may be worth looking at.

[@alexpappas610]

If I understand correctly, this is more of the bare flux pattern. I believe in redux, actions should have unique keys which will be used on dispatchers and reducers will use with switch case statements. I'm not entirely sure though but I am assuming that it's this way so that there can a be a tooling built around the pattern for debugging/time-traveling. Redux is also typically done with a single store to hold all application states whereas Flux can have multiple stores, in the case above - services.

[@deborah_kurata]

Yeah, that's why I called it "Redux-like". 😊 I assumed many Angular developers would have heard of Redux, but not necessarily the details and differences with Flux. If you're interested in more details on Redux, I found this resource useful: redux.js.org/tutorials/fundamentals/part-1-overview

[@alexpappas610]

@@deborah_kurata Thank you!

[@aledellajanna]

Hi Deborah! I hope you're well. Yeasterday, I attended the workshop where you discussed this exact topic, and I wanted to ask for your advice on handling navigation to a different route using this pattern based on an HTTP response. For example consider this scenario, if a service response is successful, we should redirect to a certain route depending on the component that called the service, and if it's unsuccessful, to another route. Considering that this service is consumed by more than one component, the redirection should be handled by either the component that called the service or the service itself (by receiving some URL in some way)?. Thinking about how to solve this always gives me a headache, haha. Would it be possible to add something like "redirectToUrl" in the service state and put the logic there, or could the service somehow return an observable that the component can subscribe to and redirect based on the result? 😅 Thanks for sharing your knowledge

[@DejanFilipov-gv8qz]

Teacher 💙

[@deborah_kurata]

😊

[@arthurfedotiew3609]

Hi Deborah! Thanks for the great educational content as always 😍 I've got a few questions: 1. If we have a consumer (e.g. Component) which requires some part of the `currentMember` (in a real world, ther could be more complicated nested objects structure) rather than the whole member, would you recommend to reate more granular slices which would effectively men computed from computed (example of pseudocode: user = computed(() => state().user); userNameUsedByUi = computed(() => user.name())? 2. Usually, state is not that tiny and maintainable, which would make us create a significant amount of signal based selectors (which would increase even more using the granular selectors (related to above question)). Since each signal is an additional node in the reactive graph, I wonder if there was any performance profiling work done to detect the point where the size of the reactive graph leaves the memory foot print which starts to matter (e.g. on the lower end/mobile) devices?

[@deborah_kurata]

Thank you! In the real world, if you have complex data to manage I'd highly recommend signal store or some other state management library. This pattern is best for simpler, smaller-scale projects when a state management library would be overkill. Regarding your second question, according to the Angular team; "Signal read does no create a new node in a reactive graph - in this sense we don't need to limit ourselves to the number of signal reads in a template." (From here: github.com/angular/angular/issues/52103#issuecomment-1758168656)

[@rkrao8582]

Another amazing video. What do you think about Tansact Query ? Do you think it will simplify the approach that you established here to access the server state?

[@deborah_kurata]

Thanks! I haven't looked into TanStack Query, so I don't know how it compares. In a quick glance of the docs, I don't see signals anywhere. But it also says that the Angular version is still "experimental", so maybe signal support is coming?

[@rkrao8582]

​​@@deborah_kurata Yeah, in V5 of TanStack Query Angular, They have all the support with Signals and other stuff latest Angular version. The library is gonna be stable in a few weeks from what I heard. Apparently the Architecture team at my workplace believes that it's gonna be a game changer in managing server state in web applications. And they are encouraging us to get a head start on it. With Signals being new and hardly caught up on it and there new thing I have to learn !! Anyways , You have great teaching skills. Your videos are a great help for me in understanding declarative patterns, rxjs, Signals. Thanks again and keep posting new stuff, Cheers.

[@deborah_kurata]

Thank you! And all the best on your project. Maybe a TanStack Query video is in my future at some point... 😊

[@marianojunior6885]

Hi Deborah, first, congratulations on the great video. If I have several subcomponents with many properties to manage state, do I use one service and just one interface to represent the state of the component and subcomponents?

[@deborah_kurata]

Thanks! I think that it would depend on the complexity of the state and the reusability of the subcomponent(s). If a subcomponent (that provides filtering for example) is reusable, it may be useful for it to manage it's own state. If a subcomponent is complex (like a paging component with forward, back, jump to page, number of pages, etc), it may be useful for it to manage it's own state. If a subcomponent is just "supportive" (like showing additional detail that the main component already manages), it may be useful to have a shared set of state. Sorry for the "it depends" answer! 😊

[@marianojunior6885]

@@deborah_kurata Thanks!!

[@Erril_Ferndal]

Great like always :)

[@deborah_kurata]

Thank you so much!

[@LMFinney]

Thanks for showing this pattern, but I'm curious if you think this has advantages over using signalStore. signalStore is intentionally not a Redux implementation (even though it's in NgRx), so they aren't directly comparable. But so far, I've been happy with signalStore. How do you compare them?

[@deborah_kurata]

Thank you! signalStore is a much better option. (I had intended on mentioning that in the video and then neglected to!) The *only* advantage that I see this has over signalStore is that it doesn't require a third party state library. (Which may matter to some enterprises.)

[@LMFinney]

Thanks for responding. I agree with your assessment, but I think it's interesting that Redux _can_ be implemented with signals. It's good to see people trying out different ideas, even if we don't universally adopt them.

[@deborah_kurata]

I appreciate that. Thanks!

[@alessandrobruni568]

spettacolare! Just one question, can the return of the setError be an EMPTY? in any case i will try on my own.

[@deborah_kurata]

Thank you! Yes, you can return EMPTY. You'd then want to change the code a bit because if there isn't a set of todos returned (even an empty set of todos), the current code implementation won't turn off the loading flag.

[@waelmoh]

always helpful, thank you very much for your continuous efforts, but if i can ask for using the state service only in the component level , and its subcomponent and how can the parent and sub interact with this service (wich is not a root service). a small video ? >.< !!

[@haroldpepete]

you never let me down, greeat video, what do you think is the most suitable option, make it from scratch or use a library?

[@deborah_kurata]

Thank you! Yeah, I'd meant to mention that in the video and then neglected to add it. It is much better to use something like signalStore than to do things manually. But I think it helps to understand how this process works.

[@chathuwadev]

More valuable

[@deborah_kurata]

Thanks!

[@chagamajaykumarreddy1897]

great video, very helpful

[@deborah_kurata]

Glad it was helpful! Thanks!

[@chagamajaykumarreddy1897]

I have a doubt that what if we move all that logic inside component because keeping whole that data inside service will never clean untill application browser closed. Component data and Listers will be destroyed once we move to another route right , can you please explain me on this , thanks 🙏

[@deborah_kurata]

It really depends how you have the service registered. If you use providedIn: 'root', then you are correct. That type of service is meant for data to be retained for the entire application (such as user information.) If you register the service in the component itself, then it will be destroyed when the component is destroyed. You don't need to more the logic to a component.

[@chagamajaykumarreddy1897]

@@deborah_kurata thanks a lot for sharing. You are super talented

[@MrgnUTube]

Oh no... it looks like this old damn ngrx ^^

[@deborah_kurata]

That picture came directly from my NgRx materials. But does this approach still look like NgRx after watching the video?