Service Dependency Type-Checking #38
Closed
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
This utility type allows us to easily type classes with both an expected instance type, and a set list of arguments.
While this implementation is very... verbose, it does work and I see no practical way around it in the current version of TypeScript. I've tried to condense the documentation by way of TSDoc inheritDoc tags, but they don't actually display in solutions such as VSCode. This makes the documentation worse, as the docs for each static overload wouldn't be visible without scrolling to the generic fall-through overload. Currently, the "everything is an option object" overload isn't type-checked. This makes the code a bit less verbose, but it may be desirable.
Add support for using built-ins as dependencies in the type-checking algorithm.
Ensure built-ins are converted to the correct type when type-checking dependencies. For instance, String should convert to string.
The code was never meant to make it into a commit, but oh well.
The new name is more descriptive of what the type does.
Furthermore, simplify the type-resolution algorithm and remove its dependency on arrays with a fixed number of items. The new implementation is compatible with arrays of any size. A major advantage of this implementation is that it **dramatically** simplifies the implementation of dependency type-checking, while also removing the need for multiple Service / JSService overloads. Overall, this means much less code duplication.
This brings the JSService in-line with that of Service.
This makes it more clear what the file does.
This is temporary. I'd like to find a better way. However, currently TypeScript thinks the type is excessively deep if we cast it.
freshgum-bubbles
force-pushed
the
feature/service-type-checking
branch
from
df3dfd3
to
c20a986
Compare
|
Done a bit of research after seeing compile-time errors in the current implementation. |
|
Superseded by #85. |
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
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.
BREAKING CHANGE
Introduce type-checking into the Service object, to force
consumers of the Service decorator to correctly utilise the
expected type. This reduces runtime errors, and provides
static type-checking for dependencies passed into Service.
With this fix, the code in #32
no longer compiles. Therefore, this fixes #32.
Please excuse the verbosity in the implementation.
The reasoning for this is described in the TSDoc comments.
This is considered a draft until some form of type-testing is performed
on the overloads. As the implementation is verbose, there are chances
that future changes may break the overloads without the current suite
being able to detect it.
Todo