$provide.value() to support functions

[langdonx]

I came across this in the ngDoc comments:

 *   $provide.value('halfOf', function(value) {
 *     return value / 2;
 *   });

But it doesn't seem to be implemented? I'm not entirely sure how it would accept the value argument anyway, but I wanted it specifically to provide my controllers with a non-singleton value to aid (what I think is tremendously) in unit testing by providing a new value to each component that requests the dependency.

Edit: I've made the necessary changes by keeping track of the provider type in providerCache and modifying createInternalInjector::invoke to get the result of the function if the provider type is 'value'. It seemed almost too easily and makes me think there's a reason this wasn't implemented already. Is there something I'm not aware of?

[langdonx]

To follow up with more information, this change will allow me the benefit of the following:

http://jsfiddle.net/langdonx/tm5azpLa/

I often find myself using locally scoped (read private) arrays as data stores for a services/factories with exposed methods to access them. It's always troublesome to unit test them, because it requires I call the add and get methods to test the remove method. This seems like a pretty generic non-ugly approach for day-to-day use, and will allow me the benefit of injecting these private arrays for testing. I'll probably modify the fiddle tomorrow to demonstrate unit testing (and to prove that I've not missed something).

[gkalpak]

I don't quite understand how what you describe will help in testing. A few thoughts:

1. If you have private arrays, then they probably shouldn't be made injectable (in order to ease testing), as it would poentially introduce a lot of other bugs/inconsistencies.
2. If you need something like a generator function, you can inject a value function or a factory to create the objects for you.
3. I might have not understood the usecase correctly, but in some cases you could get away with a spy.

BTW, the example you mentioned from the docs is supposed to do the following (and that is indeed what it does):

$provide.value('halfOf', function halfOf(value) { return value / 2; });
...
.service('Something', function SomethingService(halfOf) {
  var halfOfTwo = halfOf(2);
  ...
});

Basically, it provides the specified function whenever you inject halfOf.

[pkozlowski-opensource]

As @gkalpak I'm not entirelly sure what is the real issue here...

[langdonx]

There's no real issue given that as @gkalpak mentioned I could use a generator service (http://jsfiddle.net/langdonx/tm5azpLa/7/).

Having spent a lot of time with D3js where this is a common pattern, and I guess I just expected it to work in Angular out of the gate. My suggested change would break the halfOf use case because it would execute the function prior to injecting it and result in NaN.

I would argue though that halfOf's use case is more appropriate for $provide.factory and that $provide.value would ultimately be more useful were it to return the value given or the value of the given function.

My suggestion, for the most part, is syntax sugar (sorry) and cuts down on boiler plate code (compare the above fiddle against http://jsfiddle.net/langdonx/tm5azpLa/). It's a breaking change, but one I think might be worth it for a larger milestone release. It's something I could further flesh out with tests and a pull request were it considered worthy. Thanks!

[pkozlowski-opensource]

Hm, I don't think I "buy" the idea of a function registered via value() to behave as a generator by default. Functions are first-class objects in JS so it should be possible to pass a value that happens to be a function.

[langdonx]

That's fair. To me, a standalone halfOf function is something you would use in a programming tutorial, but not something you would ever advise in a real application. I would imagine most developers would prefer to put a function like that in an appropriately named utility factory e.g.: MathEx.halfOf(2);

[sonicblis]

I love the idea of value() returning a concrete value whether hard coded or arrived at from the execution of the function specified to derive the value. If the function itself is returned, I have to know to execute it whereas just referencing it could give me a usable value either way with the same line of code in the body into which it's injected. It would be what I would expect.

[pkozlowski-opensource]

@sonicblis and what should happen if you return a function from a .factory? There needs to be some consistency in the system...

[sonicblis]

Agreed, but the word "value" is an indication of intent in this case I'd say. It almost implies the idea of a constant. I might get that constant by executing a function, but it's still a constant. .factory is implicitly a more robust feature that can provide more complex functionality. I wouldn't have any dissonance with the two behaving differently, but I might be an outlier. I would expect a value from something called .value(), but I'm not arguing it's "right". Just defendable (and convenient) maybe.

[gkalpak]

.value() does return a value, any value, including primitives, objects, arrays and functions (because, as @pkozlowski-opensource mentioned, functions are first-class citizens in JS).

Don't forget that the concept of a service in Angular is one. It shouldn't (and doesn't) matter if you use .provider(), .factory(), .service() or .value(). Each one should result in a service, but there is a difference in the flexibility and boilerplate code for each. So one should use the simplest alternative that still provides enough flexibility per usecase.
(After all, the last three are sugar over .provider() (more or less).)

That said, I would definitely be opposed to changing the implementation of .value().
We could instead introduce a new .generator() or something, that does what you described.
_{(TBH, I see little value in it - pun intended 😃)}

[sonicblis]

That's fair and I'd say it makes sense to value consistency over common sense. =] Totally kidding, I get your point and can get behind it. I like the idea of .generator() a lot. It would smooth out some unit testing syntax greatly. If it's something the powers that be can get behind, awesome. I nominate @langdonx to issue a PR with an implementation.

Thanks for taking the time to talk it through. You guys are part of what makes the angular world awesome.

[lgalfaso]

It looks like there is nothing actionable here. There are more than enough mechanisms to define providers, factories, services and values. Each worn in different ways and all of them should cover all possible variations needed.