2

Both this answer and this article suggest creating a separate import called a "resolver" that imports the service that retrieves my data. I feel like it would make more sense and be less code to just modify my services to implement Resolve.

Angular's docs even go so far as to name their resolvers services, eg. crisis-detail-resolver.service.

Why do resolvers need to be separate from the services they use? Or is it OK in some instances to make your services implement resolve?

Community
  • 1
  • 1
adamdport
  • 11,687
  • 14
  • 69
  • 91
  • Classes can only have 1 resolve method, so if your service is used for several different resolves, you need separate resolve classes. – adharris Apr 24 '17 at 21:04
  • @adharris Ah. But if it's a simple service that will only ever resolve one thing, is it OK to just make my service a resolver? Or is it still considered "bad practice" because the service may grow someday? – adamdport Apr 25 '17 at 14:03
  • They are also easier to test if they are they are own thing; but I don't think its that big of a deal if you combine them. – adharris Apr 25 '17 at 19:57

1 Answers1

2

Resolvers ARE services. It's not that they need to be separated. Rather, resolvers only have one purpose, and that is to resolve. Thus, they are typically separated since they aren't performing the same role as other services. If you were to include all your other logic in a resolver service, then the logic from that service will load every single time you visit a route that has that resolver attached to it, which wouldn't make sense. There are some other subtle reasons to separate resolvers, but mainly, it's just for the purpose of separation of concerns and other conflicts.

David Anthony Acosta
  • 4,766
  • 1
  • 19
  • 19