Discussion: Rename DI Bindings into Providers

[vsavkin]

Using the same word "binding" for two core ideas of the framework causes some confusion.

Proposal: Rename Binding into Provider, and bindings into providers.

@Component({
  providers: [
    // the constructor version  
    new Provider(Http, {toClass: CustomHttp}),

    // using builder
    provide(Http).viaFactory(customFactory),

    // using a different type of builder
    provide(Http, {value: customFactory})
  ]
})

Pros:

• Similar to Angular 1
• Binding means only data-bindings

Cons:

• Different from other DI systems, which mostly use the word binding

@IgorMinar @mhevery

[hess-g]

+1. I was just writing up my observations on my first 2+ week deep-dive into Angular 2, and one of them was:
Overloaded terminology may cause confusion when learning the framework.
“A component has property and event bindings” (ref)...but also has a property ‘bindings’ which is its private dependency injector.

Related to this issue, this discussion about annotating for emitting metadata: this change might lean that in favor of something like:

@ProviderConsumer
class DataService {
  constructor(http: Http) {
  }
}

[vicb]

I'm with @vsavkin on this.

I think it would help with @HostBinding (we can then keep this name). I was thinking about this renaming when submitting the issue about HostBinding but didn't end up proposing because bind seems like a common terminology for DI (see Guice) - I personally don't mind dropping bind.

We should rename toXXX as well: new Provider(Http, {toClass: CustomHttp}) does not sound right.

[0x-r4bbit]

Think it would be viaValue() and viaClass() then. I understand why
renaming that concept (yet) again might be good. But we should keep in mind
that people got used to the term "binding" now. Also, using the term
"provider" might make people think that we have the concept of providers
like in A1 again...

Although otoh that's what a provider is somehow all about, even in A1.

On Wed, Sep 30, 2015, 12:08 AM Victor Berchet notifications@github.com
wrote:

I'm with @vsavkin https://github.com/vsavkin on this.

I think it would help with @HostBinding (we can then keep this name). I
was thinking about this renaming when submitting the issue about
HostBinding but didn't end up proposing because bind seems like a common
terminology for DI (see Guice) - I personally don't mind dropping bind.

We should rename toXXX as well: new Provider(Http, {toClass: CustomHttp})
does not sound right.

—
Reply to this email directly or view it on GitHub
#4416 (comment).

[0x-r4bbit]

@hess-google I think you're confusing two different things here. Providing
a binding for DI and injecting something are not the same thing. I don't
think that this renaming will help with the enforcing of emitting metadata
in typescript.

However, I do agree that "binding" is a heavily overloaded term in A2

On Wed, Sep 30, 2015, 12:15 AM Pascal Precht pascal.precht@gmail.com
wrote:

Think it would be viaValue() and viaClass() then. I understand why
renaming that concept (yet) again might be good. But we should keep in mind
that people got used to the term "binding" now. Also, using the term
"provider" might make people think that we have the concept of providers
like in A1 again...

Although otoh that's what a provider is somehow all about, even in A1.

On Wed, Sep 30, 2015, 12:08 AM Victor Berchet notifications@github.com
wrote:

I'm with @vsavkin https://github.com/vsavkin on this.

I think it would help with @HostBinding (we can then keep this name). I
was thinking about this renaming when submitting the issue about
HostBinding but didn't end up proposing because bind seems like a common
terminology for DI (see Guice) - I personally don't mind dropping bind.

We should rename toXXX as well: new Provider(Http, {toClass: CustomHttp})
does not sound right.

—
Reply to this email directly or view it on GitHub
#4416 (comment).

[robwormald]

I've long thought this was sort of confusing too. That said, I feel like "providers" as key sort of isn't much better.

I've just been referring to things as "services" and "components", personally. So:

@Component({
  services: [ 
    bind(Thing).toValue({foo: 'bar' })
  ]

})

Most ng1 users are quite happy with the term service, I think.

[mhevery]

@wardbell and @matanlurey do you have comments? I am leaning towards changing this to providers

[IgorMinar]

+1 for naming change, but we should take a look at the big picture view and see how this impacts all the public apis (e.g. hostBindings, bindings, is there more?)

[wardbell]

I want to change it from bindings as well. Way overloaded.

The problem with providers is that it introduces _yet another new concept_ ... something we don't need right now.

I'm inclined toward @robwormald suggestion of services ... although that introduces a new concept as well albeit a familiar concept.

We already teach "dependencies" as part of Dependency Injection.

Why not call the property dependencies.

The picayune might notice that we sometimes have to supply an explicit binding in the array rather than the name of a dependent thing. I don't mind. But if someone did, then all of the suggestions fail because none of them mention bindings of any kind.

In which case, I would vote for the lengthy but accurate dependencyBindings.

[0x-r4bbit]

@wardbell I think dependencies would be too generic, since we also have a directives property in the @View() decorator, which are also some sort of dependencies. Ppl might wonder why those are not treated as "dependencies".

[mgechev]

I agree that dependencies is too generic. services seems too specific. Especially if we bind to a value or a factory it doesn't make a lot of sense to me.

I'm for providers although I realize it may create some confusion to the users who are familiar with AngularJS 1.x.

[ericmdantas]

So, we wouldn't have viewBindings and bindings anymore, it'd be just providers?

Also, even though it might cause some confusion at first:
provide(Something).viaFactory(() => new SomethingElse('yay')) sounds cool.

[0x-r4bbit]

It really does.

I think we'd have providers and viewProviders then.

[wardbell]

As a matter of pure English and within the world of s/w, provider and dependency are equally generic.

The biggest problem with provider is that it is yet another word in the Angular lexicon. We don't need more of those.

What does a provider provide? How is it used? If you were to answer in this context, you would say it provides something that is injected into another thing.

We have that word already. It is called a dependency. We teach that early to every would be Ng dev.

When I read dependency my knee jerk reaction is "something that will be injected into the constructor, either tho component's constructor or the constructor of one of its dependencies."

And that is precisely the reaction we want the dev to have here.

Nothing new to learn. W seen this before. You're telling Ng what should be passes to a constructor. I get it. Done.

For these reasons... familiar term, correct instinct (instinct, nor reason) about what to do and what will happen... I favor the unambiguous dependency