-
Notifications
You must be signed in to change notification settings - Fork 37
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
Impossible to type #41
Comments
Couldn't you create a new type that extends the Observable type and has the |
@daffl I've tried a few variations of that but it's complicated greatly by the fact that the type has to be modified by an entirely different declaration file. Extending the static types of modules with another imported module is tricky and likely not possible in this case without an API change. |
What if you just type it as an Observable (you can always do It's also weird to me that you can't extend an existing interface. Every static language I know of can do that. |
I'm still slowly (but surely) working my way through and typing some core Feathers libraries. Unfortunately, I'm at an impasse with feathers-reactive. There's just no good way to statically type a function that can return both a
Promise
and anObservable
. At best, you treat the return type as generic, but that gets messy very quickly.While I was thinking of possible solutions, it occurred to me that the fact that this can't easily be described with a type system maybe means that it shouldn't be that way. Magically returning both a Promise and Observable with
promisify
is arguably not ideal from an API design standpoint.I think one possible solution would be to use the existing method registered on the service output and have that be the exclusive thing that transform the return type, like:
Alternatively, the service method calls themselves could change, like
though this is maybe a bit confusing to developers.
Any thoughts on this?
The text was updated successfully, but these errors were encountered: