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
unary request and client stream promise support #981
base: master
Are you sure you want to change the base?
Conversation
Thank you for your pull request. Before we can look at your contribution, we need to ensure all contributors are covered by a Contributor License Agreement. After the following items are addressed, please respond with a new comment here, and the automated system will re-verify.
Regards, |
CLA? |
In general, we require API changes to go through our gRFC proposal process. In addition, the problem I see here is that for existing users and anyone who uses the callback API, this will introduce new |
Even non breaking ones?
I already thought about it(when I ran the tests it was flooded with that), you can try removing that block and running tests. if (typeof callProperties.callback === 'function') {
// avoid UnhandledPromiseRejectionWarning
promise.catch(() => {});
} |
Yes, we do require proposals for non-breaking API changes. That is most of the content in that proposal repository. |
@murgatroid99 See it will take some time to write an proposal(probably more broadly using the "same" approach), so would be really be helpful if you could give me a feedback about making APIs |
One of the primary purposes of making a proposal is to get feedback about the design. It does seem a little weird to me to not have the full |
@murgatroid99 It should work with every API that supports promise, the base of a Promise it's a thenable(object that have a then). https://promisesaplus.com/ The advantage is that we can by default allow it to be a the standard library for basic usages without a lot of wrappers, wrappers are easy to do(not so much to maintain). But one problem is typescript support, with static generated code, that yes promisify works for it, but needs to run it on each APIs and is really easy to make the error code became cryptic, so is better with a native support. Also promises are the standard for asynchronous code nowadays. Using callbacks isn't even a option anymore for a lot of people. I could fork it or make a wrapper, but then I need to fork the entire ecosystem(well I almost did).
After everything I get a 100% typed code with an nice usage, without any major breaking change. ex: api.spec.ts. Also it's easier for myself(and for everyone) if everything became part of the mainstream. Anyway, I will write the proposal today or tomorrow, it will be better written than that, then we can think better about it. |
It's only been three years. Any news? 😸 Promises out of the box would be very helpful. |
Support
then()
when unary request or client stream, essentially both APIs are the ones that already exposes a callback, so I just removed the need for a callback and make the return of both thenable.No breaking change, every test pass(and two new ones), the API only became more open, now allow to avoid a callback.
Usage example: