Without using a state management lib, I tend to use a template variable to handle my errors. I may have myErrorVariable initialised it to null. Then use the catchError operator to set it to whatever error value you want whenever there's an error. Then I'd use in my template like so... My data My error loading... Only downside it that you have to reset myErrorVariable back to null whenever you want to retry/refetch. Works for most of my use cases. Thoughts??
If external dependencies are on the table, I think ngrxLet directive is a better, simpler solution. Also in the user card html I would use an else statement instead of two opposite ngIfs
Nice pattern. I don’t know ngrx store very well, what you would do in this case: Here you’re calling loadUsers once during ng on init. Imagine data can be loaded multiple times after user UI interaction. What you want do if you want to see the loading template between a get to another? You will add “loading” as a new state/observable on the component store so that you will be subscribed to 3 streams or you would just patch users to undefined each time the component invokes the loadUser upon each user’s interaction?
What if I want to be able to reload the data without reloading the page? The observable completes on error if it isn’t caught in the base observable right?
Not sure specifically what you are referring to, but assuming you are referring to the necessity of an "error" stream - we could use catchError and within that set some flag/value on the component imperatively but then we wouldn't have a stream of our error being set. We could have a side effect in the catchError that nexts some BehaviorSubject for the error or something like that, but then we are achieving the same basic outcome with side effects instead. Feel free to clarify and I can provide more context if needed
Looks good! I have a questions: 1) if I use child routes, then I can not pass data to child component ( I have only router-outlet ), then I have to inject store into child component constructor and subscribing there. Is it good practice ? In this case child components become more smart, couz they have to handle events and so on for now, but parent become more dumb with just one purpose - as a top level store keeper. 2) I also heard that angular automatically unsubscribe from observables, no needs to do it manually, can you prove or decline it ? Thanks for your channel!
Not sure I understand your description in 1) feel free to link to a Stack Blitz or GitHub example if you want. As for 2) the async pipe will unsubscribe from observables automatically, but Angular won't do it generally. Unless the observable completes itself (e.g. HttpClient will complete after 1 value is emitted) then technically you don't *need* to unsubscribe manually, but even then it is safer to unsubscribe explicitly.
Are there any good practices for using streams that depend on each other when we dont know is core stream hot or cold? I mean with many async pipes. e.g. core$ = this.someService.getCoreData(); child$ = this.core$.pipe(somePipes); And then I need use it on template {{core$ | async }}, {{child$ | async}} Is it good idea to add shareReplay to core$?
Join my mailing list for more exclusive content and access to the archive of my private tips of the week: mobirony.ck.page/4a331b9076
Without using a state management lib, I tend to use a template variable to handle my errors. I may have myErrorVariable initialised it to null. Then use the catchError operator to set it to whatever error value you want whenever there's an error. Then I'd use in my template like so...
My data
My error
loading...
Only downside it that you have to reset myErrorVariable back to null whenever you want to retry/refetch. Works for most of my use cases. Thoughts??
Looks pretty neat!
watching all your videos and giving all of them a thumbs up! 👍
I like it. As a fan of comp store, fits right into my workflow. Cheers!
I like this pattern. It is one that I use regularly.
If external dependencies are on the table, I think ngrxLet directive is a better, simpler solution. Also in the user card html I would use an else statement instead of two opposite ngIfs
ngrxLet would definitely be a great option - I'm still yet to try it out myself yet, but I like the idea
Nice pattern. I don’t know ngrx store very well, what you would do in this case:
Here you’re calling loadUsers once during ng on init. Imagine data can be loaded multiple times after user UI interaction. What you want do if you want to see the loading template between a get to another? You will add “loading” as a new state/observable on the component store so that you will be subscribed to 3 streams or you would just patch users to undefined each time the component invokes the loadUser upon each user’s interaction?
Do you maybe have a video on how to test ngrx component store?
What if I want to be able to reload the data without reloading the page? The observable completes on error if it isn’t caught in the base observable right?
Great video as always! Why can't you just pipe the stream to "catchError" before passing it to the async pipe?
Not sure specifically what you are referring to, but assuming you are referring to the necessity of an "error" stream - we could use catchError and within that set some flag/value on the component imperatively but then we wouldn't have a stream of our error being set. We could have a side effect in the catchError that nexts some BehaviorSubject for the error or something like that, but then we are achieving the same basic outcome with side effects instead.
Feel free to clarify and I can provide more context if needed
Looks good! I have a questions:
1) if I use child routes, then I can not pass data to child component ( I have only router-outlet ), then I have to inject store into child component constructor and subscribing there. Is it good practice ? In this case child components become more smart, couz they have to handle events and so on for now, but parent become more dumb with just one purpose - as a top level store keeper.
2) I also heard that angular automatically unsubscribe from observables, no needs to do it manually, can you prove or decline it ?
Thanks for your channel!
Not sure I understand your description in 1) feel free to link to a Stack Blitz or GitHub example if you want. As for 2) the async pipe will unsubscribe from observables automatically, but Angular won't do it generally. Unless the observable completes itself (e.g. HttpClient will complete after 1 value is emitted) then technically you don't *need* to unsubscribe manually, but even then it is safer to unsubscribe explicitly.
Are there any good practices for using streams that depend on each other when we dont know is core stream hot or cold? I mean with many async pipes. e.g.
core$ = this.someService.getCoreData();
child$ = this.core$.pipe(somePipes);
And then I need use it on template
{{core$ | async }}, {{child$ | async}}
Is it good idea to add shareReplay to core$?