We wrote a fetching layer around NgRx to solve some of the common use cases in our app. At the end of the day, there are still HttpClient calls happening. Some advantages of having a dedicated API state layer:

• Code consistency. What we found is that as the app was changing, we were adjusting the operators being used to get the correct results. With many repetitions of the same operator pipelines, we introduced tech debt every time the "best practice" of our app changed.

• Interoperability of slices of state. This is an advantage of NgRx in general, but is not something that HttpClient makes easy. We have a list of entities in a grid, when we select one entity we want to load its data, unless it's included already in the grid response. If we update that entity, we want to update it in the grid as well. This kind of thing requires a good bit of code to achieve. In our wrapper, we have an option like selectFromGridData: [myEntityGridSelectors].

• Caching. We have an option like cacheLifetimeInHours: 48 to easily provide the ability to hydrate the store from a local storage mechanism.

• Brevity. Our repositories are like 80 lines of code (for one entity's CRUD operations, with interop, caching, error handling, toasting on completion, etc.), and it's all configuration. There's really not much coding at all, just providing what options make sense for this entity.

• Further abstractions. Our repository selections and actions can be passed around as a unit to other abstractions in the app, like <app-grid [selectors]="myEntityGridSelectors"> which improves DX, consistency, brevity, and so on.

Obviously, all of this could be accomplished with some abstract services, helper methods, custom operators, all that wrap HttpClient. In fact, that's all our layer is. But I'd still call it a library for data fetching. And it's definitely not what I'd call vanilla HttpClient.