Click here to Skip to main content
14,574,529 members

Do we really need Angular Route Resolvers ?

Rate this:
4.80 (5 votes)
Please Sign up or sign in to vote.
4.80 (5 votes)
29 Jun 2020CPOL
Best Practices for using Angular Route Resolvers.
This post intends to capture the best practices and anti-patterns when it comes to using Angular Route Resolvers.

Resolvers have been around in angular for a while now and they have become quite popular if you look at the forums.

In my opinion, resolvers solve a very specific problem, i.e. it helps you load data for a “component to function” before the component is activated. That’s my definition btw, but the way angular markets the feature is, by suggesting that we should use resolvers for pre-fetching data.

What I thought/hoped they were?

You know when I hear the term pre-fetch it sounds promising. When I think about it in my head, I imagine data being pre-fetched for things I anticipate the user to do in the immediate future. It’s like this machine learnt navigation behavior where one could calculate the probability of a user clicking on a certain link and pre-fetch data for that page before the user even clicks it. But I know that’s just wishful thinking. 😁

What they really are?

In simple terms, Resolvers are just plain-old middlewares in the angular routing pipeline which facilitate loading the data required for a component before the component is loaded. That’s it. No magic. It plugs into the routing pipeline and makes the API calls to get the data and when the data is ready, it activates the component. This way the component just appears with no “loading…”

Image 1

The Angular Resolver Workflow

Now, there are use cases when I would want to have some data available before component initialization, but in the recent months I’ve seen Resolvers being abused to make API calls which sometimes take 3-5 seconds. Imagine being an end user, and you click a link to display a component only to be waiting for 5 seconds before you even know that the click registered (if you’re anything like me, you would have clicked 2-3 times in that period). This does seem like bad UX.

Let’s look at our options (with and without resolvers) with the code samples below.

Code with Resolvers

// Snippet from the RecordsResolverService 
@Injectable({
  providedIn: 'root'
})
export class RecordsResolverService implements Resolve<Record[]>{

  constructor(private _recordsService: RecordsService) { }
  resolve(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): Record[] | Observable<Record[]> | Promise<Record[]> {
    return this._recordsService.Get();
  }
}
// Snippet from app-routing.module.ts
  {
    path: 'records-resolver', component: ResultsWithResolverComponent, resolve: {
      records: RecordsResolverService
    }
  }
// Snippet from the component consuming route data from Resolver
export class ResultsWithResolverComponent implements OnInit {
  records: Record[] = [];
  constructor(private route: ActivatedRoute) { }

  ngOnInit(): void {
    this.route.data.subscribe((data: { records: Record[] }) => {
      this.records = data.records;
    });
  }
}
<!-- HTML with Resolvers-->
<table>
    <thead>
        <tr>
            <td>ID</td>
            <td>Price</td>
            <td>Product</td>
            <td>Order Date</td>
        </tr>
    </thead>
    <tbody>
        <tr *ngFor="let rec of records">
            <td>{{rec.guid}}</td>
            <td>{{rec.price}}</td>
            <td>{{rec.product}}</td>
            <td>{{rec.orderDate}}</td>
        </tr>
    </tbody>
</table>

Code without Resolvers (RxJS and Async Pipe)

// Snippet from app-routing.module.ts
 {
    path: 'records-async', component: ResultsAsyncRxComponent
  }
// Snippet from the component consuming route data directly from API
export class ResultsAsyncRxComponent implements OnInit {
  records$: Observable<Record[]>;
  constructor(private _recordsService: RecordsService) { }

  ngOnInit(): void {
    this.records$ = this._recordsService.Get();
  }
}
<!-- HTML with Async Pipe-->
<table *ngIf="records$ | async as records; else loading">
    <thead>
        <tr>
            <td>ID</td>
            <td>Price</td>
            <td>Product</td>
            <td>Order Date</td>
        </tr>
    </thead>
    <tbody>
        <tr *ngFor="let rec of records">
            <td>{{rec.guid}}</td>
            <td>{{rec.price}}</td>
            <td>{{rec.product}}</td>
            <td>{{rec.orderDate}}</td>
        </tr>
    </tbody>
</table>

Now Let’s see a side-by-side comparison of output (with and without resolvers). For demo purposes I’ve introduced a delay of 2 seconds in API calls.

With Resolvers Without Resolvers (Async+Rx)
Image 2 Image 3

As we can see, even with a 2 second delay in API call, fetching data on the component instead of the resolver, gives some indication to the user that his/her click on the link registered.

So why do Resolvers exist and what are they good for?

Well, I’d argue in most of the cases, you don’t need resolvers since the popular adoption of reactive programming (rxJs) in Angular.

But, Resolvers (may be) could have a use-case when

  • You want to send session information or get unique identifiers for the component to “function” once activated.
  • You want to add extra query/route params to the URL and navigate again based on the response from the API.

For instance, consider a hypothetical scenario (source code),

  • You have a list of customers (with ID) displayed on a page. Clicking on a customer ID should show the associated orders
  • Each customer has multiple orders associated, but (here’s the twist) the ordering database doesn’t use the same customerIDs; instead they have a surrogate ID
  • This customer ID to surrogateID mapping comes from another WebAPI
  • As you might have figured by now, for the orders page to be functional, you need the surrogateID before loading the component

This makes for a good candidate for using Resolvers, wherein before navigating to the orders component, you make a call to the surrogate API to get the surrogate ID and pass it to orders component on activation (using route.data or queryParams).

The rest of the business of getting the order history for the customer is (and should be) taken care by the order component in an async fashion (using RxJs Observables and AsyncPipe)

If you guys want to see the code for hypothetical example, it’s available at this GitHub repo.

What Resolvers should NOT be used for?

For fetching actual content (records, tabular data) for a component, you shouldn’t use resolvers (since their synchronous nature doesn’t make for good UX).

In these scenarios, it’s best to use RxJS and Observables (and Async Pipes) to fetch the data in the component itself. This would make your app navigation appear more “responsive” from an end-user perspective.

Resolvers sound cool, especially the concept of pre-fetching data, but in a reactive (RxJs) world, you’d rarely find a scenario where you can use Angular Resolvers to have a positive (if any) effect on application performance. More often than not, RxJs would solve all your data fetching requirements in a performant and asynchronous fashion.

I’d like to end by acknowledging that my opinion on Resolvers might appear strong, but I’m a flexible person 🙂 . Feel free to shout out in the comments and I’d be happy to get enlightened.

Happy Coding!!

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Chinmoy Mohanty
Software Developer
United States United States
I am a Developer working across multiple Technologies like .NET, Scala, Angular and NodeJS.
Passionate about WEB technologies more than anything.
Fascinated about the idea of how the WEB world and the WinForm world are slowly merging into each other, with a very thin line to differentiate them.

I am an active blogger and I blog mostly about Technology. Also, I have presented at certain points in the past on technical topics.

My Blog


Life & Tech

Programming Community Profiles


Stack Overflow
GitHub

Presentations


Slideshare

Social Profiles


Facebook | Twitter | LinkedIn | Google+

Comments and Discussions

 
QuestionInteresting take on the subject Pin
Member 1487667929-Jun-20 18:27
MemberMember 1487667929-Jun-20 18:27 
GeneralMy vote of 5 Pin
Member 1487667829-Jun-20 18:22
MemberMember 1487667829-Jun-20 18:22 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Technical Blog
Posted 28 Jun 2020

Stats

2.2K views