This repository has been archived by the owner on Apr 12, 2024. It is now read-only.
WIP - feat($injector): add support for non-string IDs (and other minor stuff) #14998
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
|
Still missing docs (I would like to get some feedback, before spending time on that). Considerations:
|
gkalpak
changed the title
gkalpak
changed the title
|
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. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Tests for the changes have been added (for bug fixes / features)Other information:
Among other things, non-string identifiers enable:
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
Providerto 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