I would argue that all of these are abstractions which provide very little extra value, along with a whole load of extra confusion, since they create new names for common concepts that already exist in javascript, like ‘service’ instead of ‘new instance’. They’re all just ways to register things to angular’s fundamentally global DI namespace, and as such you might as well just stick to using ‘factory’ every time and save time figuring out what the difference is between a factory and a service and a value and a provider

For example, here’s how much of a thin abstraction value/constant/service/provider are around ‘factory’:

angular.value = (name, value) => angular.factory(name, () => value);angular.constant = (name, value) => angular.factory(name, () => value);angular.service = (name, constructor) => angular.factory(name, () => new value);angular.provider = (name, provider) => angular.factory(name, (new value).$get);

I don’t think having 5 different ways to do fundamentally the same thing, is very useful.

I also think the divide between ‘dependencies available at config time’ and ‘dependencies available at runtime’ is pretty arbitrary and doesn’t provide a whole lot of value. Why can’t I just run configuration code at runtime?

works for PayPal, as a lead engineer in Checkout. Opinions expressed herein belong to him and not his employer. daniel@bluesuncorp.co.uk

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store