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.

Reuse much of the data-fetching logic from the AvailablePlaces component in the UserPlaces component:

Update the request URL to /user-places and adjust the error message (e.g., “Fetching your favorite places failed.”).

Replace the UserPlaces template “todo” placeholder by copying the AvailablePlaces template structure, but:

After reloading, favorites should appear immediately; newly favorited places won’t show in the favorites list until reload (to be fixed later).

Notes that this introduces code duplication; suggests later refactoring via a shared component or (more likely) a service to share logic.

Refactor HTTP logic out of components into a shared PlacesService to centralize data-fetching/configuration and keep components lean.

Create a private fetchPlaces(url: string, errorMessage: string) method in the service by moving the existing httpClient.get(…​).pipe(map, catchError, throwError) code from a component into the service. Inject HttpClient into the service and move required RxJS imports (map, catchError, throwError) there too.

Build two public wrapper methods that reuse fetchPlaces:

Update AvailablePlacesComponent and UserPlacesComponent to:

Also move the PUT request for adding a place to favorites from AvailablePlacesComponent into the service via addPlaceToUserPlaces(placeId: string), keeping a consistent “all HTTP config in the service” approach.

Emphasize cleaning up component subscriptions (store and unsubscribe on component destruction).

End result: same functionality (data loads as before), but HTTP request setup lives in the service while components focus on subscribing, state handling, and UI updates.

Move ownership of userPlaces state into the Places service using an existing writable signal (userPlaces) and expose it as a read-only signal (loadedUserPlaces) for components.

In loadUserPlaces(), update the service’s userPlaces signal whenever places are fetched:

In UserPlacesComponent, stop setting its own local places signal based on the observable’s next.

Instead, bind places to the service’s loadedUserPlaces read-only signal.

Keep loading/error/complete handling in the component.

Places are loaded and stored centrally in the service, and the component displays them from the service-managed signal.

Immediate UI updates when adding a new favorite still aren’t solved yet, but this sets up the structure needed to implement that next.