WHY WRITE A SERVICE? This example is so simple that it is tempting to write the Http.get() inside the component itself and skip the service. In practice, however, data access rarely stays this simple. You typically need to post-process the data, add error handling, and maybe some retry logic to cope with intermittent connectivity. The component quickly becomes cluttered with data access minutia. The component becomes harder to understand, harder to test, and the data access logic can't be re-used or standardized. That's why it's a best practice to separate presentation of data from data access by encapsulating data access in a separate service and delegating to that service in the component, even in simple cases like this one.
Lets talk about what you get with HttpClient:
- Easy testing. Because its using the DI system, its very mockable. You can totally set this up with fetch or whatever behind a service but, well why? Its already done.
- Robust type safety. Again you can set this up with fetch, but why? Its already done.
- Integrated with rxjs/observables for data transformation, piping, and filtering. You can set this up with fetch but why? It's already done.
- Discoverable API because of the deep framework integration and type intelligence. You can set this up with fetch buy why? It's already done.
- HttpInterceptor is awesome for checking for things like auth tokens and such. You can set this up with fetch but why? It's already done.
Not specific to HttpClient but:
- AOT compiler means that unneeded code gets pruned keeping your bundles small.
- AOT compiler means that you literally can't compile incorrect code (but it provides an escape hatch if you want to live your life that way)
I can make this same argument for pretty much any module you throw at me. Like I said, Angular is _complete_. Is it the right fit for every situation? No! :) It's overkill for smaller projects but if you are building anything of sufficient complexity, you _will_ need all this stuff. The question is, do you want it to be something you had to roll yourself and didn't have time to document for your teammates or do you want something that did all the hard work for you and is ready for whatever you throw at it?
> Robust type safety. Again you can set this up with fetch, but why? Its already done.
Not sure what you mean here. Fetch has high-quality TypeScript bindings. For the rest it's mostly YAGNI. The boilerplate confuses new developers (try explaining what NgModule does to a junior dev just trying to build a simple page) and experienced developers know how to do this stuff themselves.
I have trained junior devs on Angular and I think it's a fair criticism to say it's a steeper learning curve. They do fine tho and as an added bonus they get introduced to concepts like IoC and the like which sets them up for other languages.
Experienced developers can set this stuff up its true. I have in fact. It's fun the first few times. Then you get annoyed and want to actually work on your problem domain. I'd much rather spend my time and brain power on that stuff.
The apps that I've built that had an established pattern and all the infrastructure needed from go tended to age better and tolerate changes to business requirements. The ones where we rolled it all hodge podge needed more extensive refactoring later.
I mean look: this really boils down to very different philosophies. You either go light and build as you go or go everything and the kitchen sink and deal with (what some would call) bloat. I think both have their pros and cons. No silver bullet and all that. You gotta look at the situation and make a call. The rest is just preference and gut instinct.
Angular uses an RxJS interface to XMLHttpRequest, which has a few advantages. For example, only relatively recently did fetch() (including polyfills) support cancellation.
That said, there's absolutely nothing that requires you to use @angular/common/http. Angular created it because developers have to solve those problems over and over, but it's just a library under the Angular roof; you can use fetch() function instead.
Angular is not overengineered, it's just feature-complete. vue is not "simple made easy", it just delegates lots of functionality to 3rd party, leaving the confused developer to read medium posts on the line of "axios vs. vue-resource".
I prefer the vue way, but it's a subjective personal preference and should basically be ignored by others.
I mean, it does run in a web browser.
The format should probably be broken up. But yeah covers a lot:
* HTTP, JSON, JSONP
* Request entities, response entities, headers
* Error handling, cancelation, and retries
* Authentication, logging, and other kinds of "middleware"
* XSRF
* Progress tracking
* DI and testing
* Type safety
> how many concepts Angular invented
Not a single one of those was invented by Angular.
The "weirdest" thing Angular does is use RxJS. But that would be more a criticism of Rx/FRP in general, not Angular specifically.
Whether good or bad, it seeks to be the solution to many problems (which you would have to solve in some way), hence it being a "framework".
I'd probably call that "opinionated" rather than "over-engineered."
It's almost comical. I can't believe how long that guide is and how many concepts Angular invented just to fetch some JSON from an http service.