Spike: Dependency injection or its alternative in JSLB4

[hacksparrow]

Follow up task for #1978.

Acceptance criteria

a. Should be demonstrated in a class
b. Should be used with JSLB4 Application class
c. Should be able to read properties from the LB4 context
d. Should be able to bind new properties the LB4 context
e. Should be able to unbind properties from the LB4 context

[bajtos]

I think the topic of Dependency Injection is more complex than what the issue description says.

IMO, we should look into specific use cases and make sure we have a good solution for each of them, instead of accepting one generic approach that may work better in some cases and not so well elsewhere.

To keep the size of this story small, I think we should start with picking a small subset of use cases we want to support, and use the MVP example described in #1978 (comment) to decide what is needed.

There are multiple ways how to characterize DI use cases:

• Flavor
  • Constructor argument injection
  • Property injection
  • Method-argument injection
• Type of the target
  • DataSource
  • Repository
  • Controller
  • Sequence
  • Provider
  • (?) route handler function? - we don't support this in TS, but it could be useful in JS
• What is being injected
  • A single value @inject(key)
  • A list of values matching a filter (@inject(filter))
  • A getter function to obtain a single value (@inject.getter(key))
  • A getter function to obtain a list of values (@inject.getter(filter))
  • A setter function to bind a single value (@inject.setter(key))
  • A live view (@inject.view(filter))
  • Possibly more in the future

Considering the limitations of JavaScript (most notably missing support for decorators), I think we should also consider Service Locator pattern, maybe it would work better than Dependency Injection? See #1978 (comment).

[hacksparrow]

Closing as per the decision taken in #2567.