Fetching data like a PRO in Angular

[@codegeek8256]

I just discovered this channel and subscribed immediately. Are you planning to continue making this awesome content? Please don't stop, this is some elite content you are creating. Clear, Concise, and most importantly very helpful. Thanks.

[@DevBySeb]

Thanks for the awesome feedback mate 🙏🏼🙏🏼

[@danielpersson4814]

This was a perfect example of how to reuse the code you write insted of adding same code everywhere that does the same thing! Awesome work Sebastian!

[@DevBySeb]

Thanks a lot mate!

[@GuillaumeAngular]

Thanks you Seb. Please feed us every week with this kind of Angular content 🙏

[@DevBySeb]

Thanks mate much appreciated! 🙏

[@jeevanpreetkaur7071]

These kind of videos are great for improving our everyday development skills. Please do share more ideas, tips n tricks to improve in Angular space. Subscribed. Thanks.

[@DevBySeb]

Thanks mate much appreciated! 🙏

[@mugatu2017]

very clean approach, i will add this code to my snippets, thanks

[@DevBySeb]

Thanks for watching and for the awesome feedback mate 🙏🏼🙏🏼

[@metallidraw]

thx for your tutorial very appreciate from france !

[@DevBySeb]

Happy to help mate! 🙏🙏

[@johnmicheldelibua9917]

Thank you so much Sebastian for sharing this approach. 🤝

[@DevBySeb]

Thank you mate 🙏🙏

[@rajpatel-nu9xr]

This was awesome. Thanks man. please create such videos

[@DevBySeb]

Thanks for the feedback mate. I will do that for sure! 🙏

[@ngmiinq2028]

Thanksss this is exactly what I want!! Thank you so muchhhh

[@DevBySeb]

I'm happy I could help with this mate! :) I'll make sure I post more tips'n'tricks in the future - stay tuned! :)

[@guicercal]

Hi Sebastian! nice video, i just have few observations: - avoid calling the "subscribe" method by your self, if its possible to use the async pipe, use it, if it's not, so don't forget to unsubscribe (usually in the ngOnDestroy method of your component). - name your variables in a way you can easily identify them! because you named you variable as "data", your html template file end up having somthing: {{ data.data | json}}, which can be considered as "code smells". - it's ok to have a "Perform" class but why not use it as a parent class for the DataService instead of instantiate an object in the component?

[@DevBySeb]

Thanks for sharing the feedback mate 🙏🏼

[@jopiadrianto]

nice brother give us more angular best practices, we need it

[@DevBySeb]

Thank you brother 🙏🏼

[@ahmedmk534]

this is gold. thanks

[@DevBySeb]

Thanks for the awesome feedback mate and thank you for watching 🙏🏼🙏🏼

[@vasylzdendyak3564]

Thanks! Good solution. I'm just wondering whether you can make this Perform class injectable, provide it to the component, and inject it from the constructor. So you will get a new instance of the Perform per each instance of the component where you need it.

[@DevBySeb]

Thanks for the response mate! That's possible to do with services, so you could essentially remove the singleton behavior from the services by removing the "providedIn: 'root'", from the service. :) All you need to do then is to inject it into the component by adding it as a provider for the component, e.g. adding providers: [PerformService] inside the @Component({ ... }) decorator :)

[@MaddesMat]

👍👍

[@DevBySeb]

Thanks 🙏❤

[@ralphman3481]

Why not use the finalize operator to loading = false, return the data as observable and then avoid using the subscribe? You could preserve the funcionality of the class and use the async pipe in components.

[@DevBySeb]

Good input mate. I usually do both. I tend to use the aync pipe more often though.

[@pedrofernandes2005]

In principle a good idea but a subscribe inside a class? - You should avoid using the subscribe and use the async pipe. - Even if you want to subscribe() use it on the component.

[@DevBySeb]

I find it difficult to create something reusable without using this approach. If you add it to a service, either it will be limited to one call or you would have to handle arrays of calls etc - which might be tricky to debug. I find it "easier" and "cleaner" this way, and it could be used multiple times. When it comes to using the async pipe, I can agree to some extent - the code could easily be tweaked to return an observable and at the same time keeping the loading and error states - which could be utilized. Thanks for sharing mate! :)

[@EvertonCanez]

Nice approach! However, I was wondering. And what if instead a class you used a service? Wouldn't it be better?

[@DevBySeb]

Thanks for the feedback mate 🙏 Good question mate. It would also work fine with a service for smaller projects. Limitations with the service: You need to remember have to remove the singleton pattern. This means that you need to remember to set it as a provider for all components where its used. It would also be limited to one API call per component with the current implementation. Using the class makes it possible to utilize it for multiple calls within the same component. End of the day, its difficult to say which would be better - it may vary from project to project 😀 its possible to extend the class logic to make it possible to use it for multiple calls in the same component. Hope it explained it a bit further.

[@robth655]

Now you are just a little step away from using a resolver. Why not?

[@00mcalihe00]

its nice but i think a PRO would use an http interceptor to handle this behaviour

[@DevBySeb]

That's also one cool approach - thank you for sharing mate :)

[@soild-media]

Oh shit. There's no even OnPush strategy. All your loading and error variables should be observables.

[@DevBySeb]

Thanks for sharing mate 🙏🏼 I would not want to use observables as it would cause more logic to handle in the components. Now, with signals it would be magic 🔥

[@g-luu]

Never ever instantiate classes yourself in Angular let DI do that for you. I wouldnt recommend this approach. Appreciate your efforts though.

[@DevBySeb]

Hey Bryan. Thanks for your feedback! What's the issue with instantiating the classes yourself? :)

[@g-luu]

@@DevBySeb Nothing is really wrong its just one of those patterns angular does not recommend cause DI is there for a reason. Take example using promises instead of observables. You can but its not recommended cause thats not what angular was built for

[@g-luu]

By instantiating a class manually, you introduce the responsibility of managing its dependencies. This violates the single responsibility principle and can lead to tightly coupled code that is difficult to maintain and test.