Skip to content
This repository has been archived by the owner on Apr 13, 2022. It is now read-only.

WIP - feat($injector): add support for non-string IDs (and other minor stuff) #14998

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

gkalpak
Copy link
Member

@gkalpak gkalpak commented Aug 6, 2016

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Feature.

What is the current behavior? (You can also link to an open issue here)
Only strings can be used as service identifiers. See #10347.

What is the new behavior (if this is a feature change)?
Any value can be used as a service identifier.

Does this PR introduce a breaking change?
No (afaict).

Please check if the PR fulfills these requirements

Other information:
Among other things, non-string identifiers enable:

  • Private services (without relying on naming conventions).
  • Collision avoidance (without relying on custom prefixes and namespacing).
  • Better toolability (e.g. autocomplete support for service identifiers).
  • Better compression (i.e. strings can't be minified, non-string values could).

Identifiers for directives and filters are still restricted to string values, since they need to be referenced in HTML (text).

For services with string IDs, the corresponding provider ID is constructed by appending Provider
to the service ID. For services with non-string IDs, the corresponding provider has the exact same
ID (it is the context that determines if a service or a provider should be injected).
(Thi might be confusing, but I couldn't come up with a better alternative.)

The main implementation is the 4th commit. The first 3 commits are minor enhancements/fixes/cleaup either necessry or related to the main commit and could be independently backported to v1.5.x (if we wanted to).

Fixes #10347

Fix a test that was never run.
Ensure the assertions for `$injector:cdep`/`$injector:unpr` errors test the whole path.
Previously, only strings could be used as identifiers for Angular services. This commit adds support
for using any value as identifier for an Angular service (e.g. used with `.provider()`,
`.factory()`, `.service()`, `.value()`, `.constant()`, `.decorator()`).

Among other things, non-string identifiers enable:
- Private services (without relying on naming conventions).
- Collision avoidance (without relying on custom prefixes and namespacing).
- Better toolability (e.g. autocomplete support for service identifiers).
- Better compression (i.e. strings can't be minified, non-string values could).

Identifiers for directives and filters are still restricted to string values, since they need to be
referenced in HTML (text).

--
For services with string IDs, the corresponding provider ID is constructed by appending `Provider`
to the service ID. For services with non-string IDs, the corresponding provider has the exact same
ID (it is the context that determines if a service or a provider should be injected).

E.g.:
```js
var bar = {};

angular.
  module('myModule', []).

  provider('foo' /* string ID     */, {$get: function () { return 'FOO'; }}).
  provider( bar  /* non-string ID */, {$get: function () { return 'BAR'; }}).

  config(['fooProvider', function (fooProvider) {
    // `foo` provider injected (because we are in config block)
  }]).
  run(['foo', function (foo) {
    // `foo` service injected (because we are in run block)
  }]).

  config([bar, function (barProvider) {
    // `bar` provider injected (because we are in config block)
    // (even though we used the same identifier (`bar`) that we will use in the run block)
  }]).
  run([bar, function (bar) {
    // `bar` service injected (because we are in run block)
  }]);
```

--
This change is backwards compatible (afaict).

Fixes angular#10347
@gkalpak
Copy link
Member Author

gkalpak commented Aug 6, 2016

Still missing docs (I would like to get some feedback, before spending time on that).

Considerations:

  1. Using non-string values as identifiers for directives or filter is not supported. Nevertheless, passing non-string values silently fails (or worse, registers things it shouldn't), because of the feature that allows to pass an object contains multiple directives/filters.
    Although this was the case before as well, people are more likely to run into this if other registration methods (.provider, .service, .factory etc) do support non-string values.
    We might want to fix this, independently of this PR though.
  2. Both $injector.invoke() and $injector.instantiate (and indirectly $controller) support passing a locals object, where dependencies are retrieved from (if present) instead of getting them through DI. There is currently no way of passing dependencies with non-string identifiers as locals, which is inconvenient and "asymmetric".

@gkalpak gkalpak changed the title WIP - feat($injector): add support for non-string IDs (and other minor stuff) feat($injector): add support for non-string IDs (and other minor stuff) Sep 1, 2016
@gkalpak gkalpak changed the title feat($injector): add support for non-string IDs (and other minor stuff) WIP - feat($injector): add support for non-string IDs (and other minor stuff) Sep 1, 2016
@Narretz Narretz modified the milestones: 1.6.x, 1.7.x Apr 12, 2018
@petebacondarwin petebacondarwin modified the milestones: 1.7.x, 1.7.x - won't fix May 16, 2018
@jbedard
Copy link
Contributor

jbedard commented May 16, 2018

FYI I created a library that does something similar, while also adding Angular style annotations for declaring modules/services/components. I regret making those annotations the same as Angular (and might rename them someday), but the injection-by-type is quite nice. It does require the reflect-metadata typescript library though.

http://github.com/jbedard/ng-facade/

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

di: Allow arbitrary objects as identifiers for services
5 participants