Fix implicit any type for Scheduler.next()/remove() #145
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.
Addressed Issues
Scheduler<T>
takes a type, but its internal representation of the object tracker (_current
) was set toany
instead ofT
. This resulted innext()
returningany
, which lost typing and required unnecessary casting when it is called.This also creates an error that could be caught at compile time, as
next()
can also return null, which is not enforced by the type checker.Lastly,
remove(thing: any)
lost the compiler-time checking when calling it.Fixes
This fixes
next()
andremove()
to use the expectedT
so that the type checker catches all of these issues with all of the schedulers.I didn't run the make process with the PR because I'm unclear if you do that yourself, but I'm happy to push another commit with doc/lib built.
Example
From the documentation, here's an example of where this was going wrong:
These issues are fixed by the PR.