New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature] Introduce Type-safe Token Providing #55555
Labels
area: core
Issues related to the framework runtime
core: di
cross-cutting: types
feature
Issue that requests a new feature
Milestone
Comments
I see. I think it would still be nice to add |
This has been on my mind too, as a potential way to add incremental type safety to DI. |
alxhub
added
feature
Issue that requests a new feature
area: core
Issues related to the framework runtime
core: di
cross-cutting: types
labels
Apr 26, 2024
Also, 👏 nice issue number! |
lol I didn't notice the number. |
Do you expect me to create a PR? What am I supposed to do next? |
very similar to my proposal. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area: core
Issues related to the framework runtime
core: di
cross-cutting: types
feature
Issue that requests a new feature
Which @angular/* package(s) are relevant/related to the feature request?
core
Description
The current object-literal-based providing syntax cannot ensure:
multi: true
option is not missing or mistakenly addedFor libraries, in order to ensure type-safe providing, it has been a common pattern to create
provideXxx
helpers. However, in daily application development, the providng experience is still non-type-safe.Since all the
ProviderToken
s carry type information, it is possible to create framework-level providing helpers to ensure type safety.I have created such helper functions and fully adopted it in all my projects.
I would like to create a PR to introduce these helpers to
@angular/core
to enable a safer providing experience for all Angular developers.Please see below for details.
Proposed solution
Signatures
Usage
Implementation
Alternatives considered
N/A
The text was updated successfully, but these errors were encountered: