You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The runtime object should have the same type as it has in .d.ts file. If you want optimization for node (such as base64, buffer or array), it should be applied to generated sources, not to the runtime objects.
BTW the same is for enums. I was shocked, then i saw enum value as string, which should be number
The text was updated successfully, but these errors were encountered:
workaround for enums (they can be deserialized as string and as number in consequent requests (really WTF???)). I really hate this solution.
const value = fixEnumNumberValue<package.SomeEnumProto>(res.enumField, package.SomeEnumProto);
function fixEnumNumberValue<T>(v: string | number, en: any): T {
const raw = v as any;
if (Number.isInteger(raw)) {
return raw as T;
} else {
return en[raw.toString()] as any as T;
}
}
protobuf.js version: 6.10.1
when i generare js from this proto:
with commands:
i get the following js:
and ts:
as you can see the result type is
Uint8Array
, which can be passed to, e.g. uuid parser.After i execute grpc service method, as described in docs:
Under node the real value of uuid proto after deserialization is Buffer, and it can't be processed by uuid parser:
The runtime object should have the same type as it has in
.d.ts
file. If you want optimization for node (such as base64, buffer or array), it should be applied to generated sources, not to the runtime objects.BTW the same is for enums. I was shocked, then i saw enum value as string, which should be number
The text was updated successfully, but these errors were encountered: