Skip to content
tezvyn:

Angular Route Resolvers: Fetch Data Before Navigation

Source: angular.devMediumHow cards are made

Angular Route Resolvers: Fetch Data Before Navigation

An Angular Route Resolver pre-fetches data, ensuring it's ready *before* your component renders. Use it to load critical data for a route, like a user profile, to avoid showing a loading spinner. The footgun: a slow resolver blocks navigation entirely.

Why it exists

Route resolvers solve the problem of components rendering before their necessary data has arrived from an API. This avoids showing an empty component or a loading spinner, which can be a jarring user experience, especially for data that is essential for the page to make sense.

The mental model

Think of a resolver as a bouncer for your route. Before letting the user (navigation) into the club (the component), the bouncer checks if they have their ticket (the data). If the data is fetched successfully, navigation proceeds and the component gets the data. If not, navigation is blocked. This ensures the component never has to handle a "data is missing" state.

How it works

You create a function that implements the ResolveFn type. This function can inject services to fetch data, like from an HTTP client. You then associate this resolver function with a route in your routing configuration using the resolve property. The Angular router executes this function before activating the route. Once the data is resolved (e.g., the API call completes), it's made available to the component through the ActivatedRoute service, typically on its data property.

When to use it

Use resolvers for fetching critical, "blocking" data that a component absolutely needs to render its primary content. This is perfect for loading an article's content for an article page, or fetching a user's profile for a profile editor. It centralizes data-fetching logic for a specific route and simplifies the component itself.

When not to use it

Avoid resolvers for non-essential data or for very slow API calls that would unacceptably block navigation. If a user clicks a link and nothing happens for several seconds, they'll think the app is broken. In these cases, it's better to navigate immediately and show a skeleton loader or loading indicator inside the component while the data fetches in the background.

One canonical example

To show a user's details, you can define a userResolver that injects a UserStore and calls userStore.getUser(userId), getting the userId from the route parameters. In the route config for path: 'user/:id', you add resolve: { user: userResolver }. The UserDetail component can then inject ActivatedRoute and access the fetched user object from route.data.

Interview question

What is the most significant negative consequence that leads to avoiding an Angular Route Resolver?

  • a.It makes the component's data fetching logic more complex.
  • b.It can lead to redundant data fetches if multiple components need the same data.
  • c.It prevents the component from displaying any loading indicators during data retrieval.
  • d.It can unacceptably block navigation, causing a poor user experience if the data fetch is slow.Correct
Why?

The card explicitly states that a 'slow resolver blocks navigation entirely' and advises avoiding resolvers for 'very slow API calls that would unacceptably block navigation.' While resolvers prevent showing loading spinners (option C), this is often their intended purpose for critical data; the primary reason to avoid them is the blocking nature of slow fetches.

Just read this? Test yourself on what you have been reading.

Read the original → angular.dev

You just looked this up. Could you explain it out loud?

That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on angular — each one lists the topics its interview covers.

See open roles