#Magical world of enums: 🧵
1 messages · Page 1 of 1 (latest)
@delicate vault When registering enums, I'll need to avoid re-registering them. (presumably that would either break it, or at the least, reduce performance)
For custom ones, that seems fairly simple. I could keep an array of class names I've registered already to avoid duplicates.
Built-in ones are a bit more awkward. They're already there... can you think of a good way to get around this?
do you mean, how to avoid registering something like ReturnType again?
so in the go sdk, we just track which package these come from - if it's the autogenerated package, we just skip it
for other sdks, i think some of them use decorators?
etc.
cc @cyan plank
Right of course, I'd probably want to use #[DaggerObject] again
Then whenever enums are encountered, if it isn't registered and it has that decorator, register it
otherwise skip
maybe a new custom annotation? #[DaggerEnum] maybe?
Sometimes I wonder whether it would be better to simply have some sort of #[Expose] or #[Register] attribute instead. Since #[DaggerObject], #[DaggerFunction] and #[DaggerEnum] are all doing the same thing... but that's a topic for another thread
On TypeScript I just follow references and can verify if it's already registed or not by checking the generated client
I think that's the simplest go to
Yeah the alternative sounds rather complex 😅
Is that using currentTypeDefs?
Or any other set of API calls through the client