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
Expose message class's canonical name #739
Comments
Hey @FND, the import {codegenInfo} from "@bufbuild/protobuf";
codegenInfo.localName(...); Note that it requires one of the The We don't have a function for what you want specifically, but with the functions above, it should be implement a function that reliably converts message names any way you want. |
Thanks for the response! That sounds promising, but I have to admit it's not clear to me how I can get from a message class ( |
Descriptors are not available at runtime. They are available in plugins (see docs), but it looks like that's not what you're doing. Messages have a type name. In your example, the type name is I'm not sure that this is what you want. You mentioned the names in |
You're right, I got myself confused there: Turns out I mostly just need the fields, not the message class itself. The puzzle pieces you've provided were helpful nonetheless; thank you! Also, I was previously hesitant to derive identifiers from |
In order to do reliable message correlation (think request/response matching or dispatching via
oneof
), it would be helpful if message classes exposed a canonical name.Given a message like this:
... I'd like to convert
MyResponse
to"myResponse"
- i.e. the same value used withinoneof
messages'case
property. (I'm aware that such local names do not necessarily constitute unique identifiers, so one might argue that both full and local name was necessary.)A bit of reverse engineering suggests I could use
localName({ kind: "rpc", name: MyResponse.name })
from a private module, but that seems ill-advised.FWIW, I don't have strong feelings about instance/static property vs. a
(m: Message) => string
utility function.PS: Thanks for your efforts on this project; it helped keep me comparatively sane.
The text was updated successfully, but these errors were encountered: