-
-
Notifications
You must be signed in to change notification settings - Fork 130
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
feat(model): Implement user applications #2323
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there were too many
nit: these should be sorted alphabetically
comments so i stopped repeating them on every instance, besides that there are just things to discuss
pub kind: InteractionType, | ||
pub user_id: Id<UserMarker>, | ||
pub authorizing_integration_owners: | ||
ApplicationIntegrationMap<AnonymizableId<GuildMarker>, Id<UserMarker>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we really need the complexity of generics here, we could follow ddocs and create a AuthorizingIntegrationOwners
struct with fields kind: ApplicationIntegrationType
and id: AuthorizingIntegrationOwnerId
where AuthorizingIntegrationOwners
is an enum with Guild(Option<Id<GuildMarker>>)
and User(Id<UserMarker>)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not a enum, instead if we should do it as in the docs we should have a hashmap with 2 possible enum keys and then different Id type depending on if it is one or the other, I think this is the easiest way to make it work nicely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think we're adding complexity to be DRY here, i think it's worth a few added LOC to separate ApplicationIntegrationMap
to different structs such as:
// for InteractionMetadata and Interaction
enum AuthorizingIntegrationOwners {
GuildInstall(AuthorizingIntegrationOwnersGuild),
UserInstall(Id<UserMarker>),
}
enum AuthorizingIntegrationOwnersGuild {
Guild(Id<GuildMarker>),
Dm,
}
and for ApplicationIntegrationTypeConfig
, unless im missing something we only ever use it as ApplicationIntegrationMap<ApplicationIntegrationTypeConfig>
so we can just unnest it
I think this is ready for a wider review. |
This pr implements the newly added user applications, this have had some testing done, but is still missing quite a bit of documentation and maybe a bit of bike-shedding about type names and/or layout.