Daniel Brain
Kitty Quinn

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?

Like what you read? Give Daniel Brain a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.