While sending HTTP requests towards our server, we need to use the Angular HttpClient. Of course, we may handle all the HTTP requests from every component and process the response as well, but it is not a good practice. It is much better to make the repository for your requests and then send the request URL to that repository. The repository should take care of the rest.
How do we achieve this?
That’s the topic of this blog post.
If you want to see all the basic instructions and complete navigation for the .NET Core series, check out the following link: Introduction of the .NET Core series.
For the complete navigation and all the basic instructions of the Angular series, check out: Introduction of the Angular series.
The source code is available at GitHub .NET Core, Angular and MySQL. Part 9 – Source Code
This post is divided into several sections:
- About HttpClientModule and Angular HttpClient
- Working With Environment Files
- Creating Angular Repository File
- Repository Code Explanation
- Subscription on the HTTP calls
- Conclusion
About HttpClientModule and Angular HttpClient
The thing that matters is that we are going to use the new HttpClientModule introduced in Angular 4.3 and not the old HttpModule. The new module gives us some advantages with processing responses and handling errors as well. With the old HttpModule, we would have to map our response and convert it to the JSON. Consequently, we would have to use the RxJS library because this library enables usage of the map function. With the new HttpClientModule and Angular HttpClient, JSON response is set by default. Thus our project requires no result conversion at all.
The one way to check out our angular version is to start the application and to open developer tools. We will see the version in <app-root> tag:
Working With Environment Files
While this project is in development mode the server’s endpoint address is the http://localhost:5000. With the application in the production environment, the endpoint is different, something like www.accountowner.com. What we want is that Angular takes care of that. So in the development mode, it should send requests towards localhost:5000, and in the production environment to some other address.
Let’s implement that.
In the side-bar of the visual studio code, search for the environments folder. Inside that folder, you are going to find two files, the environment.prod.ts, and the environment.ts. We are going to use the first one for configuring the production and the second one for configuring the development environment.
It is time for us to modify these files.
environment.prod.ts:
|
1 2 3 4 |
export const environment = { production: true, urlAddress: 'http://www.accountowner.com' }; |
environment.ts:
|
1 2 3 4 |
export const environment = { production: false, urlAddress: 'http://localhost:5000' }; |
Now we are going to create the service which will provide us with the valid environment urlAddress.
Inside the app folder, create a new folder and name it shared. Then in that folder create a new one and name it services. Finally, create the new file environment-url.service.ts:
We could do this using the AngularCLI command as well:
|
1 |
ng g service shared/services/environment-url |
About the Angular Services
Services are just classes, which provide us with some business logic relevant to our components. These services must be injected into a component using constructor injection. Furthermore, our code becomes more maintainable and readable.
When we want to use a service, we need to inject it into a component’s constructor. Therefore, it is always decorated with the @Injectable decorator. Use services whenever you have some code that you can reuse in other components, or extract part of the code from your components. To make a service work, we must import it into our app.module.ts file.
From Angular version 6, there is a modification regarding a service providing. Now when we use Angular CLI command to create a service, the created service will have a different @Injectable decorator:
|
1 2 3 |
@Injectable({ providedIn: 'root', }) |
What this means is that we don’t need to register it inside the app.module file anymore, it is already provided for the entire application. But if we need it, we may provide it in an old fashion way as well.
Let’s continue our work with the environment files by modifying the environment-url.service.ts file:
|
1 2 3 4 5 6 7 8 9 10 11 |
import { Injectable } from '@angular/core'; import { environment } from './../../../environments/environment'; @Injectable() export class EnvironmentUrlService { public urlAddress: string = environment.urlAddress; constructor() { } } |
The urlAddress property accepts the value of the urlAddress defined in the environment file. Angular knows if it is production or development environment (because of “production” property values inside both environment files) and is going to supply us with a valid value of that urlAddress.
Now we need to import this service into our app.module.ts file:
|
1 |
import { EnvironmentUrlService } from './shared/services/environment-url.service'; |
Place it inside providers array as well:
|
1 2 3 |
providers: [ EnvironmentUrlService ], |
Creating Angular Repository File
Let’s configure the HttpClientModule and create the repository service.
First, we need to import the HttpClientModule inside the app.module.ts file:
|
1 |
import { HttpClientModule } from '@angular/common/http'; |
Then let’s place it inside imports array:
|
1 2 3 4 5 6 7 8 9 10 |
imports: [ BrowserModule, HttpClientModule, RouterModule.forRoot([ { path: 'home', component: HomeComponent }, { path: '404', component : NotFoundComponent}, { path: '', redirectTo: '/home', pathMatch: 'full' }, { path: '**', redirectTo: '/404', pathMatch: 'full'} ]) ] |
Now create the service file and name it repository.service.ts. Place it in the same folder in which environment service resides. In this service, we are going to create get, post, put and delete requests.
Don’t forget to include this service inside the app.module.ts file and to place it inside the providers array.
So let’s modify repository service:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
import { Injectable } from '@angular/core'; import { HttpClient, HttpHeaders } from '@angular/common/http'; import { EnvironmentUrlService } from './environment-url.service'; @Injectable() export class RepositoryService { constructor(private http: HttpClient, private envUrl: EnvironmentUrlService) { } public getData(route: string) { return this.http.get(this.createCompleteRoute(route, this.envUrl.urlAddress)); } public create(route: string, body) { return this.http.post(this.createCompleteRoute(route, this.envUrl.urlAddress), body, this.generateHeaders()); } public update(route: string, body){ return this.http.put(this.createCompleteRoute(route, this.envUrl.urlAddress), body, this.generateHeaders()); } public delete(route: string){ return this.http.delete(this.createCompleteRoute(route, this.envUrl.urlAddress)); } private createCompleteRoute(route: string, envAddress: string) { return `${envAddress}/${route}`; } private generateHeaders() { return { headers: new HttpHeaders({'Content-Type': 'application/json'}) } } } |
Repository Code Explanation
Excellent.
Let’s explain this code.
First, we are injecting the Angular HttpClient and the environment variable into the constructor. Then we are creating functions which are going to wrap our requests. Function getData is a wrapper for all GET requests. It accepts the route parameter of type string (api/owner or api/owner/id …) and then combines it with the environment variable (localhost or www…). After all of that, we are going to have the route like http://localhost:5000/api/owner if it is a development environment, which perfectly fits our requirements on the server side.
The second function, create, is a wrapper for POST requests. It also generates a route, but additionally receives a body (an entity which we are creating) and generate headers. For this example, we are just creating the Content-Type inside the header. But if we need additional values inside the header, we could just add another key-value pair inside the HttpHeaders object.
Function update is pretty much the same as the create function, except it sends PUT request.
Lastly, delete function is a wrapper for the DELETE request which accepts the route like (api/owner/id).
Subscription on the HTTP calls
These wrapper functions need a subscription in order to work. In this post, we are only creating a repository with the HTTP calls. But as soon as we start creating our pages, we are going to use subscription.
For now, I am just going to show you one example of a subscription:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
public result: any; constructor(private repo: RepositoryService) { } public consumeGetFromRepository() { this.repo.getData('api/owner/24fd81f8-d58a-4bcc-9f35-dc6cd5641906') .subscribe(res => { this.result = res; }, (error) => { this.handleErrors(error); }) } |
As you may notice, we are calling function getData from the repository, but that function won’t be executed until we call the subscribe function. By calling the subscribe function, we are going to execute the getData function. The result from the response is going to be stored in the parameter res.
Conclusion
Excellent, now we have our repository prepared and we are ready for creating components, which are going to use this repository functions to show results in a browser.
By reading this post you’ve learned:
- What the HttpClientModule is
- How to work with environment files in Angular
- What the Angular services are
- How to use HTTP requests
- The way to subscribe to HTTP requests
Thank you for reading the post, hopefully, it was helpful to you.
In the next part of the series, I am going to show you how to use lazy content loading in the Angular. Moreover, we are going to show the result data on a page.
If you have enjoyed reading this article and if you would like to receive the notifications about the freshly published Angular content we encourage you to subscribe to our blog.
Thank you so much for all the work you’ve put into this. You’ve explained a lot of little things I was foggy about. Anyway it’s been extremely useful to go through these 9 steps. I’m looking forward to the rest!
Hi Bob. You are very welcome and thank you for reading these parts and for leaving such a great comment for me. It is always a pleasure to read something like that. I hope the rest of the series is going to be beneficial to you and to all the readers. One more time, thank you very much, mate.
I’ve come back to this guide again – it’s awesome!
I’m creating a single website with multiple projects: .net core Web.API and a separate Angular 6 Web project. However, they will be hosted on the same server as a single application. Do you have some suggestions/or would you change anything in this guide to achieve that?
Thanks for all your effort Marinko. Much appreciated.
Hello Matt. If you take a look at our post where we publish our .NET Core + Angular app, you will see that we publish only one application as well. In a development phase, you are using two projects (.NET Core and Angular) because it is better and cleaner approach (at least that is my opinion) but when it comes to the deployment, you will build all your client files as a production ones and then transfer them to the wwwroot folder in your .NET Core app. Only then you can publish your app.
For more detailed information, you can read: https://code-maze.com/net-core-web-development-part16/ or https://code-maze.com/net-core-web-development-part17/
So, I wouldn’t change anything about approach from this tutorial.
I am glad, you find these tutorials useful. Spread the word 😀 😀 And I hope I have helped you with my answer.
All the best.