This video discusses the pros and cons of the centralized store pattern. This course covers the most popular store in Angular, NgRx Store, and soon the course will include also NgRx Signal Store - angular-university.io/course/ngrx-course Enjoy the video everyone 😊
Yes, 💯 with this video! Love how you have been showing simplicity with your angular videos. We have an app that uses the store for reason #3 but only things that absolutely need to be kept in sync go in the store because of the complexity.
I'm happy to hear that, that is a very reasonable approach. Multiples projections of the same data, such a great use case for the store. 😊 We took the exact same approach on our platform, use the store only when and if needed. 👍
Why should I even use redux pattern for stores when doing simple services with Subjects/BehaviorSubjects and public asObservables are much simpler? Redux adds nothing to already available Angular tools.
It's easy to think like that when your data is hierarchical and easy to maintain, but as your application grows maybe you will start needing the apps state globally (maybe for configuration of the user or other stuff) so you stop propagating and mutating the props of the components all around the component tree
@@victorgarcia3526 I think you don’t know what i was saying. Instead doing a “redux store” you have services with subjects inside and public asObservables. Much cleaner store pattern than doing redux
I agree with this, if it's just a little bit of data like a user profile and a couple of global objects, shared services work perfectly and nothing else is needed. For a biit more than that, then, a store comes in handy. To keep things simple, you can opt for makign the application mostly stateless, and store in-memory just the strict necessary. I overall agree with the sentiment of let let's not complicate and try to keep things as simple as possible. 😊
I think for global UI config and a user profile, and a bit more, shared services are probably sufficient.👍 You can encapsulate it in a service and make sure it's not being mutated in an uncontrolled way everywhere. check out here this pattern using signals ua-cam.com/video/W4G8VUaHZKg/v-deo.html I agree mutation needs to be done in a controlled way for shared data, either with a store or otherwise, if not it will be a mess very easily 👍
I like this pattern a lot, it does work well for a relatively small amount of data. I cover this approach and other RxJs design techniques here in this course angular-university.io/course/reactive-angular-course 👍
did i hear "yak shaving" hahaha that's a new one! Good video, like most programming tools/techniques you need to know why you are using them and what benefits and drawbacks they bring. I agree, I have sections of my apps that heavily use a feature store and some features of my apps have no store because it would be overkill.
Hi Jordan, yes Yack Shaving, it's an old term for overengineering 🤣 I'm glad to see more people think like that, and take a reasonable approach. That is exactly what I do in my app too, works great 👍
If one of the reason for you to choose implement a in-memory clientside store is to reduce the amount of http calls to the backend when switching screens, then how would you deal with stale, lost updated UI if another user updated some content and you were not calling the api thus unaware of the changes? Possible ways to solve your problems could be: 1. Requiring user to manually f5 the page - would sounds so dumb 2. Create an websocket hub and actively listening to update from other pages - would also sounds dumb, just ditched the store and call the apis from the beginning. We shouldn't create the problem, then create the solution to fixed that problem.
Absolutely true, it can generate tons of issues, in applications where the data changes very often, which in principle is rare, but it's true that it creates a series of other problems 😊 I agree that for most cases, that architecture would be overengineering and unnecessary.👍
How do you think of this in the mobile context (specifically an Ionic Angular app)? If you properly break your app down into many pages, are you less likely to use a centralized store? You are less likely to come across reason #3 (same data in one screen) in a mobile app.
One more reasons I would add is: how often does the data change/update? In case the data requested from the backend changes a lot, a store does not make as much sense.
Hey Vasco, first of all, magnificent content as always!! Thanks a lot 🙌🏻, and also a small question. - Do you think that if you want to build a more strict architecture (A "yes" or "yes" way of implementing things, like the management of the data in the Front end) is enough justification to implement a state management tool? For example, to implement traditional NGRX or Signals, or any other Store management tool for: 👉🏻 Make sure that new or current devs in the team who already know the "Flux architectural pattern" find themselves more familiar with the app architecture. 👉🏻 No new crazy ideas about how to handle data in every new case. 👉🏻To prevent or minimize inconsistencies about how the data is handled across the UI. thanks a lot in advance! 😉
Thank you it's awesome to hear that, and also thank you for the great question.😊 I hear a lot about this concept. But one size does never fit all, so consistency at all costs is not worth it in my opinion and it's an anti-pattern. The problem with using a store consistently for everything is that that means the store would be systematically overused in many situations where a lot simpler solutions would be sufficient. I think that idea would have to be extended to a series of patterns and guidelines, not just the store. The store solution is not a silver bullet and using it everywhere just for the sake of consistency alone it's not worth it in my view. The same thing goes with using RxJs everywhere for the sake of consistency instead of mixing it with async/await where it makes more sense, etc. I think that it's a thought fallacy, the idea that there is this one solution that can predefined and applied to any problem, that doesn't exist and the store pattern with it's high boilerplate and complexity cost is certainly not that silver bullet in my opinion 👍
@@AngularUniversity I appreciate having the time to answer, and this what said makes a lot of sense to me and also opens my mind about following a pattern religiously for every situation. And, it makes sense to implement what makes things simpler to work with and use what fits the best according to the situation, in combination with good team conventions and documentation.
Very interesting these changes of mindset! Thanks for each video! One question, how do you think that ngrx component store fits here? the same as implementing a service with signals when needed?
LOL 😂 Not yet, if anything Chat GPT has only made me more productive, together with Github Copilot, my whole team uses it and it's been a breath of fresh air. But the time will come where we programming geeks will need to find something else to do. 😉 But not just yet 😉
Hey Vasco, how would you compare using NGRX vs NGXS? I have used NGXS before and it seems to be simpler alternative. However, we still have not received Signal-Store in NGXS
That's a great question, I think the future is NgRx Signal Store in terms of store solutions, I use NgRx store on my platform. NgRx Signal is significantly easier to use, there are way less concepts, no RxJs is needed for example. effects are just signal effects, and selectors are just computed signals. so it's all much easier and more intuitive, with way less boilerplate than NgRx Store. NGXS is a store solution that does't use either RxJs or Signals. It's been created to make the store pattern usable in Angular applications that don't use a lot of RxJs. If I were you I would look into NgRx Signal Store, there is a 1hour tutorial here on the channel 😊ua-cam.com/video/HqxY0JPlh54/v-deo.html
@@AngularUniversity Thank you so much for the detailed reply! I'm actually a subscriber of your Angular University membership plan, so I'm definitely going to check out the course there. I hope in future, you'll be updating that course videos! - Solat
Great question. Yes, unless you save the data in localStorage and you save it back to the store at startup. Again, it can be made to work but very few applications benefit from it in practice, and you would need to handle the case of stale data. 👍
you mean PWAs? With the whole situation with Apple not properly wanting to support them, the hype on PWAs had died off a couple of years ago. I wouldn't look into it much further, it's a nice idea but I think but the actual use cases are limited. PWAs won't most likely ever be a mainstream thing, unless something fundamental changes. 👍
@@deepakbawa1367 Actually my answer with PWAs is to offline first, I don't think you can do offline first properly without a PWA. Without a PWA, the website will not even load if offline, and if the app is already loaded, the refresh button will break it.
Sorry. I disagree with this. Using NGRX's feature creators allows organizing state into single slices that work really nicely in a vertical slice architecture. This scales well even for small apps that have a single feature. Additionally, users of internal enterprise applications also use large social media websites and have the same functionality expectations for these enterprise apps as well.
I understand that you want to play around with this cool tech. This tech comes at a complexity cost, so adding it to applications that don't really benefit from it it's detrimental for the project. I know you want to play around with this tech and are looking for even the smallest pretext that justifies it's use. But try to look at it from a project manager or team lead perspective: why would you tell your team to make an application way more complicated, for no tangible benefit, just so that devs can scratch their complexity itch and make it more challenging to them?
![АЛАУДИНОВ у Скабеевой: эти их ВСУ нас НЕ ДОГОНЯТ 😁 [Пародия]](http://i.ytimg.com/vi/an0anqU4WGQ/mqdefault.jpg)
This video discusses the pros and cons of the centralized store pattern. This course covers the most popular store in Angular, NgRx Store, and soon the course will include also NgRx Signal Store - angular-university.io/course/ngrx-course Enjoy the video everyone 😊
Great explanation! Thank you Vasco!
Hi Vinicius, thank you I'm happy to hear that 😊
Yes, 💯 with this video! Love how you have been showing simplicity with your angular videos. We have an app that uses the store for reason #3 but only things that absolutely need to be kept in sync go in the store because of the complexity.
I'm happy to hear that, that is a very reasonable approach. Multiples projections of the same data, such a great use case for the store. 😊 We took the exact same approach on our platform, use the store only when and if needed. 👍
Why should I even use redux pattern for stores when doing simple services with Subjects/BehaviorSubjects and public asObservables are much simpler? Redux adds nothing to already available Angular tools.
It's easy to think like that when your data is hierarchical and easy to maintain, but as your application grows maybe you will start needing the apps state globally (maybe for configuration of the user or other stuff) so you stop propagating and mutating the props of the components all around the component tree
@@victorgarcia3526 I think you don’t know what i was saying. Instead doing a “redux store” you have services with subjects inside and public asObservables. Much cleaner store pattern than doing redux
I agree with this, if it's just a little bit of data like a user profile and a couple of global objects, shared services work perfectly and nothing else is needed. For a biit more than that, then, a store comes in handy. To keep things simple, you can opt for makign the application mostly stateless, and store in-memory just the strict necessary. I overall agree with the sentiment of let let's not complicate and try to keep things as simple as possible. 😊
I think for global UI config and a user profile, and a bit more, shared services are probably sufficient.👍 You can encapsulate it in a service and make sure it's not being mutated in an uncontrolled way everywhere. check out here this pattern using signals ua-cam.com/video/W4G8VUaHZKg/v-deo.html I agree mutation needs to be done in a controlled way for shared data, either with a store or otherwise, if not it will be a mess very easily 👍
I like this pattern a lot, it does work well for a relatively small amount of data. I cover this approach and other RxJs design techniques here in this course angular-university.io/course/reactive-angular-course 👍
Very interesting, thank you for the warning. 👍
You're welcome, I'm glad to hear it helped 😊
did i hear "yak shaving" hahaha that's a new one! Good video, like most programming tools/techniques you need to know why you are using them and what benefits and drawbacks they bring. I agree, I have sections of my apps that heavily use a feature store and some features of my apps have no store because it would be overkill.
Hi Jordan, yes Yack Shaving, it's an old term for overengineering 🤣 I'm glad to see more people think like that, and take a reasonable approach. That is exactly what I do in my app too, works great 👍
@@AngularUniversity 👍👍I'm going to try and use that at work!
@@jordanking3715 Awesome,, give it a shot and let me know how it went. 👍
If one of the reason for you to choose implement a in-memory clientside store is to reduce the amount of http calls to the backend when switching screens, then how would you deal with stale, lost updated UI if another user updated some content and you were not calling the api thus unaware of the changes? Possible ways to solve your problems could be:
1. Requiring user to manually f5 the page - would sounds so dumb
2. Create an websocket hub and actively listening to update from other pages - would also sounds dumb, just ditched the store and call the apis from the beginning. We shouldn't create the problem, then create the solution to fixed that problem.
Absolutely true, it can generate tons of issues, in applications where the data changes very often, which in principle is rare, but it's true that it creates a series of other problems 😊 I agree that for most cases, that architecture would be overengineering and unnecessary.👍
Thank you!
You're welcome! 😊
very sensible
How do you think of this in the mobile context (specifically an Ionic Angular app)? If you properly break your app down into many pages, are you less likely to use a centralized store? You are less likely to come across reason #3 (same data in one screen) in a mobile app.
I think that is true, in a mobile app due to the small size of the screen, you are much less likely to have multiple projections of the same data. 👍
One more reasons I would add is: how often does the data change/update? In case the data requested from the backend changes a lot, a store does not make as much sense.
Hi Danilo, I think that is correct too, a store makes the most sense in the scenario when the amount of reads is a lot bigger than the writes.
Hey Vasco, first of all, magnificent content as always!! Thanks a lot 🙌🏻, and also a small question.
- Do you think that if you want to build a more strict architecture (A "yes" or "yes" way of implementing things, like the management of the data in the Front end) is enough justification to implement a state management tool?
For example, to implement traditional NGRX or Signals, or any other Store management tool for:
👉🏻 Make sure that new or current devs in the team who already know the "Flux architectural pattern" find themselves more familiar with the app architecture.
👉🏻 No new crazy ideas about how to handle data in every new case.
👉🏻To prevent or minimize inconsistencies about how the data is handled across the UI.
thanks a lot in advance! 😉
Thank you it's awesome to hear that, and also thank you for the great question.😊 I hear a lot about this concept. But one size does never fit all, so consistency at all costs is not worth it in my opinion and it's an anti-pattern. The problem with using a store consistently for everything is that that means the store would be systematically overused in many situations where a lot simpler solutions would be sufficient. I think that idea would have to be extended to a series of patterns and guidelines, not just the store. The store solution is not a silver bullet and using it everywhere just for the sake of consistency alone it's not worth it in my view. The same thing goes with using RxJs everywhere for the sake of consistency instead of mixing it with async/await where it makes more sense, etc. I think that it's a thought fallacy, the idea that there is this one solution that can predefined and applied to any problem, that doesn't exist and the store pattern with it's high boilerplate and complexity cost is certainly not that silver bullet in my opinion 👍
@@AngularUniversity I appreciate having the time to answer, and this what said makes a lot of sense to me and also opens my mind about following a pattern religiously for every situation.
And, it makes sense to implement what makes things simpler to work with and use what fits the best according to the situation, in combination with good team conventions and documentation.
@@saturnustear I fully agree 😊👍 That is indeed the message of the video, that the pattern has it's uses but it's easy to overuse. 👍
Very interesting these changes of mindset! Thanks for each video! One question, how do you think that ngrx component store fits here? the same as implementing a service with signals when needed?
Hi Vasco, will miss your videos by now so much Devin AI has made us obsolete it is useless to learn new things or optimizations
LOL 😂 Not yet, if anything Chat GPT has only made me more productive, together with Github Copilot, my whole team uses it and it's been a breath of fresh air. But the time will come where we programming geeks will need to find something else to do. 😉 But not just yet 😉
thank you, good video
Thank you Eugene, I'm glad you liked it 😊
Hey Vasco, how would you compare using NGRX vs NGXS? I have used NGXS before and it seems to be simpler alternative. However, we still have not received Signal-Store in NGXS
That's a great question, I think the future is NgRx Signal Store in terms of store solutions, I use NgRx store on my platform. NgRx Signal is significantly easier to use, there are way less concepts, no RxJs is needed for example. effects are just signal effects, and selectors are just computed signals. so it's all much easier and more intuitive, with way less boilerplate than NgRx Store. NGXS is a store solution that does't use either RxJs or Signals. It's been created to make the store pattern usable in Angular applications that don't use a lot of RxJs. If I were you I would look into NgRx Signal Store, there is a 1hour tutorial here on the channel 😊ua-cam.com/video/HqxY0JPlh54/v-deo.html
@@AngularUniversity Thank you so much for the detailed reply! I'm actually a subscriber of your Angular University membership plan, so I'm definitely going to check out the course there. I hope in future, you'll be updating that course videos! - Solat
how does it work when you refresh the page? does the store need to be refetched?
Great question. Yes, unless you save the data in localStorage and you save it back to the store at startup. Again, it can be made to work but very few applications benefit from it in practice, and you would need to handle the case of stale data. 👍
Hi Vasco what is your opinion on the angular offline app first approach
Patiently waiting for your reply on offline first approach
you mean PWAs? With the whole situation with Apple not properly wanting to support them, the hype on PWAs had died off a couple of years ago. I wouldn't look into it much further, it's a nice idea but I think but the actual use cases are limited. PWAs won't most likely ever be a mainstream thing, unless something fundamental changes. 👍
@@deepakbawa1367 Actually my answer with PWAs is to offline first, I don't think you can do offline first properly without a PWA. Without a PWA, the website will not even load if offline, and if the app is already loaded, the refresh button will break it.
@@AngularUniversity ok now I got it. So we need to use an iconic framework with a capacitor to properly implement that
Sorry. I disagree with this. Using NGRX's feature creators allows organizing state into single slices that work really nicely in a vertical slice architecture. This scales well even for small apps that have a single feature. Additionally, users of internal enterprise applications also use large social media websites and have the same functionality expectations for these enterprise apps as well.
I understand that you want to play around with this cool tech. This tech comes at a complexity cost, so adding it to applications that don't really benefit from it it's detrimental for the project. I know you want to play around with this tech and are looking for even the smallest pretext that justifies it's use. But try to look at it from a project manager or team lead perspective: why would you tell your team to make an application way more complicated, for no tangible benefit, just so that devs can scratch their complexity itch and make it more challenging to them?
@@AngularUniversity Sorry. You're way off again.