feat(context): improve @inject.setter and add @inject.binding

[raymondfeng]

Extracted from #2635

1. Allow @inject.setter to set other forms of value providers than constant

// Set the binding to a constant value, this is the current behavior
injectedSetter('my-value'); 

// or use the returned binding to configure it
const binding = injectedSetter();
binding.toClass(MyClass);

2. Allows bindingCreation option to control how the underlying binding is resolved/created.

Checklist

👉 Read and sign the CLA (Contributor License Agreement) 👈

• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• API Documentation in code was updated
• Documentation in /docs/site was updated
• Affected artifact templates in packages/cli were updated
• Affected example projects in examples/* were updated

[bajtos]

Personally, I prefer UNIX philosophy - many small tools where each tool does one job and does it well. In that light, I would prefer a new decorator for injecting the entire Binding instance. You have mentioned @inject.binding yourself in one of the earlier pull requests, what was the reasoning for your decision to put this new feature into the existing @inject.setter function?

[raymondfeng]

Personally, I prefer UNIX philosophy - many small tools where each tool does one job and does it well. In that light, I would prefer a new decorator for injecting the entire Binding instance. You have mentioned @inject.binding yourself in one of the earlier pull requests, what was the reasoning for your decision to put this new feature into the existing @inject.setter function?

I'm open here but I would like to avoid a new @inject.* flavor before it's necessary. Here is my reasoning:

@inject.setter was introduced to bind a value (getter) to the underlying key. The 1st version only allows constant value (binding.to()) by calling setter(constantValue). This PR extends the capability to have more control by exposing the Binding instance. The initial version was to allow BindingTemplate functions to be accepted by the setter function but we cannot differentiate constant function value from template function.

If we decide to introduce @inject.binding, maybe we should deprecate and finally remove @inject.setter. It's similar as preferring @inject(filterByTag('my-tag') over @inject.tag('my-tag').

[raymondfeng]

@bajtos I went ahead to add @inject.binding and leave @inject.setter to only set constant values.

[bajtos]

I went ahead to add @inject.binding and leave @inject.setter to only set constant values.

Awesome 👍

Here is my point of view:

• I find it confusing to have a decorator called @inject.setter to inject a Binding instance.
• Ideally, IoC related code (like Binding instances) should not leak into the actual implementation (the code receiving the dependencies via injection).

With @inject.setter, the decorated argument/property receives a generic setter function that can be passed to any 3rd-party code (e.g. a package from npm), the consumer does not need to understand anything about our Context and Binding.

In that sense, @inject.binding can be seen as a kind of an anti-pattern. Having said that, I am ok to add that functionality as an advanced tool for situations where @inject.setter is not good enough. Once we learn more about use cases where @inject.binding is needed, we can look into ways how to provide more clean API(s) to support those cases.

[bajtos]

The new version looks good at high level, let's improve implementation details now.

The documentation changes in Decorators_inject.md could use some extra attention to ensure consistency.

[bajtos]

I find it weird to have two tsdoc comments for the same type. Which comment is rendered by our API docs? Can we keep only the comment that's picked up by our docs, and remove the other one please?

[bajtos]

The implementation is using type Setter<T>, please update this part of the docs to do the same.

[bajtos]

I don't see why is this change needed as there don't seem to be any tests depending on this new behavior. What's your intention here? Can we revert changes in this file?

[raymondfeng]

It's a mock-up return a binding object.

[bajtos]

Sure, I understand that, but I don't see any test in this file that would use that binding object. What's the point of creating & returning it then?

[bajtos]

@raymondfeng I don't have bandwidth to review this patch today, but I do want to check your updates before this patch is merged. Please give me few more days.

[bajtos]

Sure, I understand that, but I don't see any test in this file that would use that binding object. What's the point of creating & returning it then?

[raymondfeng]

@bajtos PTAL

[raymondfeng]

@bajtos Ping.

[bajtos]

What about the bindingCreation option?

This option is configured at DI/IoC level in @inject.setter arguments, it makes sense to keep it available. As I see it, it allows the developer that's configuring DI wiring to tweak the behavior of the setter that will be injected.

[bajtos]

👏