adding the relevant types for the grpc client. I had to use any/mixed a few times to avoid pulling in more dependencies like the events library and http2.
Details
Details
- Reviewers
atul ginsu ashoat - Commits
- rCOMM8c9c9a2e187c: [keyserver] add flow types for grpc client
ran flow in keyserver
also, after the subsequent diff, I added the following code to keyserver.js and re-ran flow:
+ const user = { userID: '12345', deviceID: 'ahhhhh' };
+ const publicKey = identityClient.getUserPublicKey(user, (e, o) => {
+ if (e) {
+ console.log(e);
+ } else {
+ console.log(o);
+ }
+ });
+ console.log(publicKey);also ran yarn dev and got back the expected public key
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
Comment Actions
- Should this be defined as a libdef (eg. in a declare module "package_name" { declaration) inside the flow-typed folder?
- I'd like to replace the export interface declarations with more idiomatic ones, but it's hard for me to test this outside of your stack. Maybe we try together in the office sometime?
| lib/types/grpc-types.js | ||
|---|---|---|
| 46 | Based on the name, kinda weird that this doesn't return like a string, but I am not familiar with this API | |
| 71 | export interfaces is weird and best to avoid... export type is preferable, but there's a separate construction for functions | |
| 126 | Is this perhaps the wrong link? | |
Comment Actions
- I don't think this should be defined as a libdef since some of the types are code-generated and specific to our identity.proto file. That said, I could probably separate the code-generated types from the grpc-js package types... are there any other considerations for deciding where to define things?
- Thanks for the help with this
| lib/types/grpc-types.js | ||
|---|---|---|
| 46 | it should return a map, I was confused by the typescript function signature, which didn't specify a return value https://github.com/grpc/grpc-node/blob/master/packages/grpc-js/src/metadata.ts#L241 | |
| 71 | thanks for the help with this | |
| 126 | it was correct, i shouldn't have any-typed the EventEmitter | |
Comment Actions
I don't think this should be defined as a libdef since some of the types are code-generated and specific to our identity.proto file. That said, I could probably separate the code-generated types from the grpc-js package types... are there any other considerations for deciding where to define things?
Let's get this landed and then maybe you can create a Backlog task for properly typing the libdef and separating out the parts here that are generated and specific to our implementation?
Also before landing, can you add a diff comment showing which parts are from the libdef vs. from our implementation / codegen?