I've spent the last two weeks migrating one project from Angular's deprecated Http module to the new (more elegant) HttpClient. Two weeks -- in my opinion that's way too much maintenance time on a single layer of the app. I encountered something similar in the fall with Angular Material.
Which brings me to the question: should we wrap critical built-in modules to avoid this kind of massive overhaul?
While Uncle Bob suggests that we should avoid concrete dependencies where possible, you'd think that concrete dependencies on the framework itself would be okay. But this HttpClient debacle is proving otherwise.
Additional follow-up question: If / when we should put our own interface around critical modules, how do we define "critical?" What sort of modules warrant this kind of architecture?
I have heard a lot of troubling things about Angular: that the API is not very stable and developers change it quite often...
I usually use
request(backend) orfetchAPI (client) for handling HTTP requests which I know are quite stable (the first one is quite old and the second one is a standard). Nevertheless, I also have a wrapper :-)One approach to deciding if you should write a wrapper is to see if you can improve or simplify the API of the original module. Many modules have way too many options, and you might not need all of that. So it's good to write a simple wrapper with much smaller API surface and use it in the application code. I think if you just wrap every function of a complex module you won't gain much because it will be still a lot of work if you decide to migrate to an alternative.