12. Sending HTTP Requests & Handling Responses

The provided starter project combines two separate apps in one folder: an Angular frontend and a backend folder containing a standalone Node/Express Web API (no Angular code).

The backend exposes routes (e.g., GET, PUT, DELETE) and persists dummy data in JSON files instead of a database, to simulate a real backend/data store.

Setup steps:

Run both servers separately:

After starting, visit localhost:4200 to see the app. The next goal is to fetch and display data (e.g., “available places”) from the backend, learning how Angular communicates with the API to access the stored JSON data.

The data for “available places” should be fetched in the AvailablePlacesComponent (a service could be used later, but for now the component is fine).

Angular sends HTTP requests via the HttpClient service (from @angular/common/http), which you can inject using inject() or a constructor.

If you inject HttpClient without configuring it, you’ll get a NullInjectorError because Angular doesn’t provide it automatically.

In a standalone setup, you typically register HttpClient app-wide in main.ts by adding providers to bootstrapApplication(…​), using provideHttpClient() (imported from @angular/common/http).

Once provideHttpClient() is added, Angular can inject HttpClient and the error disappears, making it ready to send requests.

In a module-based app, you’d provide it in the root module instead (covered later).

Use the injected Angular HttpClient to fetch initial component data in ngOnInit, since it runs once when the component is ready and is a good place to start loading backend data (e.g., available places).

Call http.get() (not post()) to send a GET request to an endpoint like http://localhost:3000/places.

HttpClient.get() returns an Observable; the request only happens when you subscribe. In subscribe, handle the emitted response in next (typically only one emission: the response data). Initially, log the response to the console.

Although HttpClient observables usually complete after one value, it’s still good practice to clean up: store the subscription and unsubscribe in an onDestroy callback using Angular’s DestroyRef.

Improve TypeScript support by typing the response via generics, e.g. get<{ places: Place[] }>(…​), based on the backend response shape (an object with a places key containing an array of Place).

The backend may respond with a deliberate delay (for demo), motivating later UI work like showing a loading state. After confirming the data arrives, the next step is to render/output the places in the UI.

observe: 'response' makes the callback receive the full HttpResponse (not just the parsed data). You then access data via response.body, which can be null, so you may need optional chaining (e.g. response.body?.places). The full response also includes headers, status code/status text, success info, etc.

observe: 'events' makes the callback fire multiple times for different request lifecycle events (e.g. an initial “request sent” event, then the final response), letting you react at different stages.

Initialize isFetching to false.

In ngOnInit, set isFetching to true right before starting the HTTP/request subscription.

Set isFetching back to false in the observable’s complete callback (safer than next if the observable could emit multiple values).

In the template, conditionally render a fallback message/spinner when isFetching is true (e.g., via @if), and render the places list only when data exists.

Result: “Fetching available places…” shows during the delay, then disappears once the places arrive.

Simulating an error response (backend): In a Node/Express route, return an HTTP 500 response (e.g., res.status(500).json(…​)) to mimic a server failure. Restart the backend server after code changes so they take effect.

Observing the failure (frontend): When the Angular app reloads, the request doesn’t return data and an HTTP error appears in dev tools.

Managing UI state with signals: Add:

Handling errors in subscribe: Use the third observer callback (error) to set the error signal when the observable errors (e.g., offline, non-2xx response).

Template updates:

Error object vs. message: The error passed to the observer is often an object, so interpolating it yields "[object Object]". Access error.message instead.

User-friendly messaging: Log the detailed error for developers, but display a generic message to users like:
“Something went wrong fetching the available places. Please try again later.”

Optional RxJS approach (catchError): Move error transformation out of subscribe by using catchError in pipe():

Restore normal behavior: Remove/comment out the forced 500 backend response, restart the backend, and the places load successfully again.

The goal is to not only fetch places but also send selected place data to the backend so the backend can store a user’s favorite places in user-places.json.

The backend exposes a PUT route at PUT /user-places which expects a request body containing a placeId.

In Angular, the app-places component emits a selectPlace event when a place is clicked; this event provides the full place object.

In the AvailablePlacesComponent, you should:

The PUT request won’t fire unless you subscribe(), just like GET requests—subscribing triggers the HTTP call.

After subscribing, clicking a place results in:

Next steps mentioned: add loading/error handling for the PUT request, and then display the stored user places in the “favorite places” UI section.