Angular v20 Resources API Changes: Better Error Handling and a Cleaner API

This article summarizes how Angular Resources will change in the next release, based on GitHub discussion threads and related commits.

Resources remain experimental and are expected to stay experimental through v20—more changes may follow.

1. Improved error handling

Change in Resource.value() behavior

Previously, when a resource was in an error state, resource.value() returned undefined. In the new implementation, reading resource.value() while in an error state throws an exception.
You must handle errors explicitly.

Previous behavior: errors were hidden by default

const res = resource({
  loader: () => fetch(...);
});

// Before (errors are hidden)
const inner = computed(() => res.value()?.inner);

New behavior: explicit error handling required

const res = resource({
  loader: () => fetch(...);

  // Option 1: Return defaultValue (initially undefined) instead of Errors
  throwErrorsFromValue: false,
});

// Option 2: Handle the error
const inner = computed(() => {
  if (res.error()) return undefined;
  return res.value()?.inner;
});

Error handling in templates

The same applies in HTML templates. If you used resource.value() as optional, check errors—not just isLoading.

@if (res.isLoading()) {
  <!-- Content while loading -->
} @else if (res.error()) {
  <!-- Content on error -->
} @else {
  <!-- Content on success -->
}

Details:

Reloading while in an error state sets hasValue() to true and value() returns defaultValue
When a new value loads successfully, error() becomes undefined

Clearer Resource.error typing

Resource.error changes from unknown to Error | undefined, enabling type-safe error handling.

const error = resource.error();
if (error instanceof Error) {
  // Type-safe access to error.message and other properties
}

Type guards make error handling easier. Also, values thrown that are not Error instances are wrapped in ResourceWrappedError for consistent handling.

if (resource.error() instanceof ResourceWrappedError) {
  const original = resource.error().cause;
  // original can be an API error object, for example
}

https://github.com/angular/angular/blob/d3e9ca1162a0d72e78708fcce5644b9b25e4d487/packages/core/src/resource/resource.ts#L469-L478

2. reload() moved

reload() is available only on WritableResource, separating "reloadable resources" from read-only resources.

const res = resource<Data>({
  loader: () => fetch(...), 
});

// It is a WritableResource, so the `reload` method is available
res.reload();

// It is not Writable, so the `reload` method is unavailable
res.asReadonly();
res.reload(); // NG

3. Parameter rename

request becomes params for clearer intent.

// Before
const res = resource<User>({
  request: () => ({id: userId()}),
  loader: ({request}) => {
    return this.http.get<User>(`/api/users/${request.id}`);
  }
});

// After
const res = resource<User>({
  params: () => ({id: userId()}),
  loader: ({params}) => {
    return this.http.get<User>(`/api/users/${params.id}`);
  }
});

httpResource also takes a function instead of a static URL.

const userId = signal(1);
const res = httpResource<User>(() => `/api/users/${userId()}`);

Summary

There is more—for example, map in httpResource was renamed to parse—but I hope this helps you anticipate changes before release.

The Resource story in Angular is just starting and will be evolving. To reflect this, the resource APIs will remain experimental in Angular v20. We will persuade the stabilization process and embark on designing additional APIs and functionality in the subsequent releases. Your continued feedback is crucial: play with Angular v20, build on top of it and open GitHub issues for any problems or enhancements that should be considered.from discussioncomment-12654043

I look forward to Resources becoming safer and easier to use.

See you next time.